On Thu, Jun 11, 2015 at 05:55:57PM +0300, Roger Quadros wrote:
> > > drivers/usb/core/hub.c
> > > 
> > > static int usb_enumerate_device_otg(struct usb_device *udev)
> > > {
> > >   int err = 0;
> > > 
> > > #ifdef    CONFIG_USB_OTG
> > >   /*
> > >    * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
> > >    * to wake us after we've powered off VBUS; and HNP, switching roles
> > >    * "host" to "peripheral".  The OTG descriptor helps figure this out.
> > >    */
> > >   if (!udev->bus->is_b_host
> > >                   && udev->config
> > >                   && udev->parent == udev->bus->root_hub) {
> > >           struct usb_otg_descriptor       *desc = NULL;
> > >           struct usb_bus                  *bus = udev->bus;
> > > 
> > >           /* descriptor may appear anywhere in config */
> > >           if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
> > >                                   
> > > le16_to_cpu(udev->config[0].desc.wTotalLength),
> > >                                   USB_DT_OTG, (void **) &desc) == 0) {
> > >                   if (desc->bmAttributes & USB_OTG_HNP) {
> > >                           unsigned                port1 = udev->portnum;
> > > 
> > >                           dev_info(&udev->dev,
> > >                                   "Dual-Role OTG device on %sHNP port\n",
> > >                                   (port1 == bus->otg_port)
> > >                                           ? "" : "non-");
> > > 
> > >                           /* enable HNP before suspend, it's simpler */
> > >                           if (port1 == bus->otg_port)
> > >                                   bus->b_hnp_enable = 1;
> > >                           err = usb_control_msg(udev,
> > >                                   usb_sndctrlpipe(udev, 0),
> > >                                   USB_REQ_SET_FEATURE, 0,
> > >                                   bus->b_hnp_enable
> > >                                           ? USB_DEVICE_B_HNP_ENABLE
> > >                                           : USB_DEVICE_A_ALT_HNP_SUPPORT,
> > >                                   0, NULL, 0, USB_CTRL_SET_TIMEOUT);
> > > 
> > > We're sending out this control request even if this host port is not OTG.
> > > Isn't that wrong?
> > 
> > So send USB_DEVICE_A_ALT_HNP_SUPPORT request.
> > This is correct in OTG 1.x, its intention is to remind the user who is
> > connecting the HNP capable OTG device to a non-OTG port, He can change
> > to another port of this machine which is a OTG port(with HNP).
> 
> I didn't understand.
> If CONFIG_USB_OTG is enabled doesn't mean that this USB host port is OTG host.
Yes, only CONFIG_USB_OTG enabled doesn't mean that this USB host port
is a OTG port, there are might multiple usb host ports, but only one
is a OTG port.
> So it should not send any OTG specific request to device. Right?
Non-otg port(in OTG 1.x protocol) + OTG 1.x device, should send,
otherwise, should not send.

So the code you pasted here was right only for OTG 1.x, I assume
OTG 2.0 has not been released when it was designed. But now it's
out of date, it's wrong if you connect a OTG 2.0 device. 

> 
> > 
> > > 
> > >                           if (err < 0) {
> > >                                   /* OTG MESSAGE: report errors here,
> > >                                    * customize to match your product.
> > >                                    */
> > >                                   dev_info(&udev->dev,
> > >                                           "can't set HNP mode: %d\n",
> > >                                           err);
> > >                                   bus->b_hnp_enable = 0;
> > >                           }
> > > 
> > > Instead it should be moved inside the if (port1 == bus->otg_port) 
> > > condition.
> > 
> > Nope, as I explained above, this is really too detailed OTG protocol:)
> > > 
> > >                   }
> > >           }
> > >   }
> > > #endif
> > >   return err;
> > > }
> > > 
> 
> cheers,
> -roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to