on the system with companion host controller, error -71 returns

[Kiyoshi Sasaki <ksasaki@miraclelinux.com>]

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>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/