Hi,
Jun Li <jun...@nxp.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
signature.asc
Description: PGP signature
