On Mon, Mar 16, 2015 at 09:44:30AM +0800, Peter Chen wrote: > On Fri, Mar 13, 2015 at 10:34:59AM -0500, Felipe Balbi wrote: > > On Fri, Mar 13, 2015 at 11:13:11AM +0800, Peter Chen wrote: > > > On Thu, Mar 12, 2015 at 11:04:09AM -0500, Felipe Balbi wrote: > > > > > > > > this could still be done generically in composite.c > > > > > > > > > > I suggested it at v1, but after thinking more, we have handled > > > DEVICE request type at individual udc driver, like remote wakeup, > > > self-power support, so it is reasonable we handle get_status that > > > if we support hnp polling at udc driver, since it is controller > > > driver's capabilities. > > > > right, right.. it is controller's capabilities, but all controller needs > > to do is a set a flag in struct usb_gadget, which it already does. Then, > > every single udc will get free implementation after setting that flag, > > right ? > > > > Great, then the udc driver which set b_hnp_enable can get the hnp > polling capabilities automatically, in fact, hnp polling support > is a software implement, I don't think it will affect old v1.3 otg > driver. > Existing flags in usb_gadget cannot exactly be used for judge if HNP polling is supported or not, support HNP does not necessarily means HNP polling is supported, in current code you can see b_hnp_enable is set for some controllers but they don't support HNP polling yet; what's more, b_hnp_enable may not be set at that time, host may not set b_hnp_enable when enumeration, but wait until the host request flag is set in HNP polling, this is different with our host driver but meet the recommended sequence in OTG and EH spec 2.0. So, either we add a new flag for it, or we just do this without flag check(allow an OTG device response to HNP polling with 0 even it actually does not support HNP polling, which is harmless from what I can see). Li Jun > -- > > Best Regards, > Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
