From: Maarten Lankhorst <m.b.lankhorst@gmail.com>
To: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: "Xu, Andiry" <Andiry.Xu@amd.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [RFC] usb: Do not attempt to reset the device while it is disabled
Date: Wed, 01 Jun 2011 01:57:00 +0200 [thread overview]
Message-ID: <4DE5804C.2050609@gmail.com> (raw)
In-Reply-To: <20110531223502.GA8550@xanatos>
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
next prev parent reply other threads:[~2011-05-31 23:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-30 9:56 [PATCH] [RFC] usb: Broaden range of vendor codes for xhci Maarten Lankhorst
2011-05-31 0:34 ` Xu, Andiry
2011-05-31 13:47 ` [PATCH] [RFC] usb: Do not attempt to reset the device while it is disabled Maarten Lankhorst
2011-05-31 17:14 ` Sarah Sharp
2011-05-31 17:41 ` Maarten Lankhorst
2011-05-31 18:18 ` Sarah Sharp
2011-05-31 19:07 ` Maarten Lankhorst
2011-05-31 22:35 ` Sarah Sharp
2011-05-31 22:55 ` Maarten Lankhorst
2011-05-31 23:57 ` Maarten Lankhorst [this message]
2011-06-01 19:39 ` Sarah Sharp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DE5804C.2050609@gmail.com \
--to=m.b.lankhorst@gmail.com \
--cc=Andiry.Xu@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sarah.a.sharp@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.