On Mon, Mar 16, 2015 at 05:03:17PM +0800, Peter Chen wrote: > 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. > It can, just because in current code, some controllers support HNP but do not use OTG FSM driver, in this case I say they do not support HNP polling but b_hnp_enable is set. Li Jun > > 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. Actually this is another topic see OTG&EH 2.0 chapter 6.2.2.1: ... ... The A-device is required to set this feature and suspend the bus within THOST_REQ_SUSP when it determines that the B-device wishes to become host (host_req_flag = TRUE). ... ... and the recommended sequence, can see in A.2.1 Figure A-8: Attachment of OTG devices That's why I add set feature of B_HNP_ENABLE in my HNP polling patch in usb-otg-fsm.c Li Jun > > > > > 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
