On Mon, Mar 16, 2015 at 04:15:22PM +0800, Li Jun wrote: > 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; Why HNP polling can't apply for all hnp enabled gadget? It is just a software feature, once the gadget is at device mode, it should be ready for hnp, meanwhile, you have already added host_request_flag at usb_gadget which the user can choose when to enable hnp polling. > 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. That's the problem, please list the spec, we may change when/where to set b_hnp_enable first if needed. > > 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). > Just like I said above, we may have a solution to cover both otg v1.3 and v2.0 first. -- 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
