lkml.org 
[lkml]   [2016]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v9 2/4] gadget: Support for the usb charger framework
Date

Hi,

Peter Chen <hzpeterchen@gmail.com> writes:
>> >> > 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.
>
> In this patch set, there are two ->get_charger_type in below two
> structures, as my understanding, get_charger_type at struct usb_charger
> can be implemented at UDC drivers; But I don't see necessary we
> need to implement get_charger_type for usb_gadget_ops at UDC drivers
> again. What do you think?

I had missed that completely, nice catch. I agree with you, there should
be one place where this is implemented and struct usb_charger sounds
like it is that place.

--
balbi
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2016-04-07 07:21    [W:0.175 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site