--- On Wed, 2/9/11, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote:
> Is this an embedded USB 3.0 hub? Because we don't
> currently support
> USB 3.0 hubs.
Yes.
> 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.
> The xHCI hardware picks the new device address, not the USB
> core.
Yet, the address printed in the log is not what the device gets, as can be
seen in this line:
Feb 9 15:14:50 localhost kernel: usb 9-1: reset SuperSpeed USB device using xhci_hcd and address 3
The device got address 1. There seems to be a rampant discrepancy in this regard. Probably something Intel should fix in the xhci code before hubs starts popping out in the real world.
> Most
> hardware seems to issue the addresses sequentially,
> starting from 1. So
> if the only device on the system was reset, address 1 is
> free, and will
> probably be given to the device on the next Set Address
> xHCI command.
>
> The hardware-selected addresses could also be an issue with
> usbfs, since
> that requires special calls into the xHCI driver as well.
> 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.
It's been vexing me for a few days. The device just drops that request on the floor as it's in the addressed state with address 1 _and_ SET ADDRESS is sent to addr 0.
See my next email.
Luben
--
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
