From: Kiyoshi Sasaki <ksasaki@miraclelinux.com>
To: linux-kernel@vger.kernel.org, linux-usb-devel@lists.sourceforge.net
Subject: on the system with companion host controller, error -71 returns
Date: Tue, 21 Aug 2007 15:59:25 +0900 [thread overview]
Message-ID: <46CA8D4D.70201@miraclelinux.com> (raw)
Hello,
I see below errors in dmesg on ICH6/ICH7 machine:
usb 1-1: device not accepting address 2, error -71
or
usb 1-1: device descriptor read/all, error -71
I'm trying to debug it, but by now I can't make it.
Can you give me your help ?
----
On ICH6/ICH7, in case load sequence is uhci first and ehci second,
each controller is initialized/registered in usb_add_hcd() like below.
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.3: UHCI Host Controller
ehci_hcd 0000:00:1d.7: EHCI Host Controller
And on ehci_hcd turn, usb_add_hcd() calls ehci_run() to start ehci.
In ehci_run(), it sets Configure Flag (CF) to 1 for enabling full
USB 2.0 functionality.
static int ehci_run (struct usb_hcd *hcd)
{
...
/*
* Start, enabling full USB 2.0 functionality ... usb 1.1 devices
* are explicitly handed to companion controller(s), so no TT is
* involved with the root hub. (Except where one is integrated,
* and there's no companion controller unless maybe for USB OTG.)
*/
hcd->state = HC_STATE_RUNNING;
writel (FLAG_CF, &ehci->regs->configured_flag);
...
}
On the other hand, uhci tries to get device information using
hub_set_address() and usb_get_device_descriptor().
These functions send URB, and URB is processed like below.
This is done asynchronously.
- uhci_irq()
- uhci_scan_schedule()
- uhci_scan_qh()
- uhci_result_common()
- uhci_map_status()
uhci_map_status() checks td_status. And the flag is TD_CTRL_STALLED
|TD_CTRL_CRCTIMEO, and return with error.
So, hub_set_address() and usb_get_device_descriptor() return -71.
After some debugging, I found if hub_set_address() and
usb_get_device_descriptor() is called before CF becomes 1,
no error returns. Conversely, if these are called even just after
CF becomes 1, error -71 returns.
CF becomes 1 means "writel (FLAG_CF, &ehci->regs->configured_flag)".
To avoid this error, my silly idea is
1) before set CF to 1, wait some asynchronous uhci processing
2) load ehci first and uhci second
But for 1), simple msleep() will not work well, and need to
control khubd and so on, so this seems not smart.
Do you have any idea to fix this issue ?
--
Kiyoshi Sasaki <ksasaki@miraclelinux.com>
next reply other threads:[~2007-08-21 7:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-21 6:59 Kiyoshi Sasaki [this message]
2007-08-21 8:03 ` [linux-usb-devel] on the system with companion host controller, error -71 returns Kiyoshi Sasaki
2007-08-21 14:38 ` Alan Stern
2007-08-22 1:45 ` Kiyoshi Sasaki
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=46CA8D4D.70201@miraclelinux.com \
--to=ksasaki@miraclelinux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox