Re: [PATCH] [RFC] usb: Do not attempt to reset the device while itis disabled

[Maarten Lankhorst]

Op 01-06-11 00:35, Sarah Sharp schreef:
> On Tue, May 31, 2011 at 09:07:32PM +0200, Maarten Lankhorst wrote:
>> Op 31-05-11 20:18, Sarah Sharp schreef:
>>> On Tue, May 31, 2011 at 07:41:14PM +0200, Maarten Lankhorst wrote:
>> My xhci controller is this one:
>> 04:00.0 USB Controller: Device 1b6f:7023 (rev 01) (prog-if 30 [XHCI])
>> Subsystem: ASRock Incorporation Device 7023
> Ok, the PCI SIGG says that vendor ID is assigned to Etron.  Congrats,
> that's the first xHCI host controller I've seen from that company. :)
Hooray.
> Ok, so the xHCI driver does successfully get a slot from the host
> controller.
>
>> [  545.664041] xhci_hcd 0000:04:00.0: Allocating ring at ffff8801c7d7ccc0
>> [  545.664044] xhci_hcd 0000:04:00.0: Allocating priv segment structure at ffff8801e2e26c40
>> [  545.664047] xhci_hcd 0000:04:00.0: // Allocating segment at ffff8800bac3f800 (virtual) 0xbac3f800 (DMA)
>> [  545.664053] xhci_hcd 0000:04:00.0: Linking segment 0xbac3f800 to segment 0xbac3f800 (DMA)
>> [  545.664056] xhci_hcd 0000:04:00.0: Wrote link toggle flag to segment ffff8801e2e26c40 (virtual), 0xbac3f800 (DMA)
>> [  545.664059] xhci_hcd 0000:04:00.0: Set slot id 1 dcbaa entry ffff8800bac3e008 to 0xbac21000
>> [  545.664070] xhci_hcd 0000:04:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90001ce0420, 32'h2f1, 4'hf);
> But I don't see an Address Device command complete here.  The command
> submission probably caused that memory write, but there really should be
> more debugging here.  I'll have to look through the hub initialization
> and see if there is any error path that would make it skip setting the
> device address.
>
> Have you tried on Linux 3.0-rc1?
Same problem with 3.0rc1 it seems. Just look at hub_port_init, that appears to be where it's going wrong:

First it calls:
        retval = hub_port_reset(hub, port1, udev, delay);

Which does the device reset..

Then lower in that function:
                if (udev->wusb == 0) {
                        for (j = 0; j < SET_ADDRESS_TRIES; ++j) {
                                retval = hub_set_address(udev, devnum);
                                if (retval >= 0)
                                        break;
                                msleep(200);
                        }

It seems to me that is why I get the reset call failing BEFORE the address is set. However I'm unsure what
would be a proper fix for it would be.

~Maarten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/