Re: Resetting SS device; SET ADDRESS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 09, 2011 at 03:41:46PM -0500, Alan Stern wrote:
> On Wed, 9 Feb 2011, Sarah Sharp wrote:
> 
> > On Tue, Feb 08, 2011 at 07:14:31PM -0800, Luben Tuikov wrote:
> > > The hw setup: NEC based controller, device directly attached to the embedded hub.
> > 
> > Is this an embedded USB 3.0 hub?  Because we don't currently support
> > USB 3.0 hubs.
> > 
> > > The device is reset via libusb_reset_device().
> > 
> > The xHCI driver has to go through a special process to let the hardware
> > know the device has been reset.  I've modified the usbcore reset methods
> > to use that, but if usbfs is falling on a slightly different code path
> > than the usb core code, then it's probably missing that call into the
> > xHCI driver.  Please file a bug on bugzilla, as I'm completely swamped
> > right now, and I don't want to lose this bug report.
> 
> > > Anyone seen this (observed only in SS, HS is fine)? Is there a fix for
> > > this in the trunk since f878133b?
> > 
> > I have never tried to reset a USB device under xHCI via usbfs, so that's
> > probably why it never showed up.  Thanks for catching this.
> 
> usbfs doesn't do anything special.  It simply calls usb_reset_device().
> 
> Probably the reason you never saw this error scenario before is that
> you never tried updating the firmware in a device.  In particular, when
> the descriptors get changed the entire device structure is destroyed,
> then the device has to be reset a second time and re-enumerated.  
> Apparently this fools xhci-hcd into thinking the device was never
> assigned an address when in fact it was.  Maybe the second reset got
> skipped.

Oh, I see.  Lubin, was this a USB 3.0 device?  If so, the re-enumeration
process would have skipped the second reset because it thought this was
an initial device connect.

Is there anyway to tell that the device is undergoing re-enumeration
because the descriptor changed?  I vaguely recall some field in the
usb_device structure for that...  If not, I'll just have to make the hub
code always reset USB 3.0 devices, which will slow down initial
connections and booting over USB 3.0.

Sarah Sharp
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux