linux-kernel - RE: [PATCH v9 2/4] gadget: Support for the usb charger framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 06 Apr 2016 15:55:55 +0300
From:	Felipe Balbi <balbi@...nel.org>
To:	Jun Li <jun.li@....com>, Baolin Wang <baolin.wang@...aro.org>,
	Peter Chen <hzpeterchen@...il.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Sebastian Reichel <sre@...nel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Peter Chen <peter.chen@...escale.com>,
	Alan Stern <stern@...land.harvard.edu>,
	"r.baldyga\@samsung.com" <r.baldyga@...sung.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	Lee Jones <lee.jones@...aro.org>,
	Mark Brown <broonie@...nel.org>,
	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>,
	"patches\@opensource.wolfsonmicro.com" 
	<patches@...nsource.wolfsonmicro.com>,
	Linux PM list <linux-pm@...r.kernel.org>,
	USB <linux-usb@...r.kernel.org>,
	"device-mainlining\@lists.linuxfoundation.org" 
	<device-mainlining@...ts.linuxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v9 2/4] gadget: Support for the usb charger framework


Hi,

Jun Li <jun.li@....com> writes:
>> >> On 6 April 2016 at 15:19, Peter Chen <hzpeterchen@...il.com> wrote:
>> >> > On Fri, Apr 01, 2016 at 03:21:50PM +0800, Baolin Wang wrote:
>> >> >>
>> >> >> @@ -563,6 +564,8 @@ struct usb_gadget_ops {
>> >> >>       struct usb_ep *(*match_ep)(struct usb_gadget *,
>> >> >>                       struct usb_endpoint_descriptor *,
>> >> >>                       struct usb_ss_ep_comp_descriptor *);
>> >> >> +     /* get the charger type */
>> >> >> +     enum usb_charger_type (*get_charger_type)(struct usb_gadget
>> >> >> + *);
>> >> >>  };
>> >> >
>> >> > Since we already have get_charger_type callback at usb_charger
>> >> > structure, why we still need this API at usb_gadget_ops?
>> >>
>> >> In case some users want to get charger type at gadget level.
>> >>
>> > Why gadget needs to know charger type? I also don't catch the intent
>> > of
>> 
>> because some gadgets need to call usb_gadget_vbus_draw(), although for
>> that they need power in mA rather.
>
> In below change of usb_gadget_vbus_draw(), already can get charger type
> via usb_charger_get_type().
>
> static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
>  {
> +       enum usb_charger_type type;
> +
> +       if (gadget->charger) {
> +               type = usb_charger_get_type(gadget->charger);
> +               usb_charger_set_cur_limit_by_type(gadget->charger, type, mA);
> +       }
> +
>         if (!gadget->ops->vbus_draw)
>                 return -EOPNOTSUPP;
>         return gadget->ops->vbus_draw(gadget, mA);
>
> Could you detail in what situation gadget->ops-> get_charger_type() is used?

isn't it right there in the code ? Isn't usb_gadget_vbus_draw() calling
it ? What did I miss here ?

>> > This api, as my understanding, gadget only need report gadget state
>> changes.
>> > All information required for usb charger is charger type and gadget
>> state.
>> 
>> you're making an assumption about how the HW is laid out which might not
>> be true.
>> 
>
> What other information you refer to here? Or what I am not aware of?

what I'm trying to say is that you're assuming gadgets don't need to
know anything other than charger type and gadget state (suspended,
resume, enumerated, default state, addressed, etc), but that might not
be true for all UDCs. You can't make that assumption that charger type
and gadget state is enough. The real question is what do we need *now*,
but still keep in mind that what we need *now* might be valid 2 years
from now, so API needs to be a little flexible.

cheers

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)