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 16:58:03 +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>,
	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:
>> >> >> > 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 ?
>
> Well, that's true, so my real meaning is why gadget need get charger type
> via another new api gadget->ops->get_charger_type().

because of semantics. usb_gadget_vbus_draw() is *only* supposed to
connect a load across vbus and gnd so some battery can be charged. Also,
we need to abstract away this ->get_charger_type() operation because it
might be different for each UDC.

$subject has a fragility, however: It's assuming that we should always
call ->get_charger_type() before ->vbus_draw(), but that's a good
default, I'd say.

>> >> > 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.
>
> Get your point, flexible, I just thought create an api without any user
> for existing case/spec, wouldn't it be better to let the real user add it
> later when it's needed.

that sure is a fair point.

-- 
balbi

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