hi Alan:
2014-04-04 8:48 GMT+08:00 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Thu, 3 Apr 2014, vichy wrote:
>
>> I add more description.
>> in Below #1, since connect status is zero, handshake will fail with
>> return -ETIMEDOUT.
>> Then go to #2 error label.
>> and finally hub_port_status get -32, -EPIPE.
>>
>> 1. Platform-ehci Platform-ehci.0: port 1 reset error -110
>> the -110 is due to below handshake timeout.
>> retval = handshake(ehci, status_reg,
>> PORT_RESET, 0, 1000);
>> if (retval != 0) {
>> ehci_err (ehci, "port %d reset error %d\n",
>> wIndex + 1, retval);
>> goto error;
>> }
>
> Right -- although the handshake shouldn't time out. That's a bug in
> the hardware.
if there is no connection, it is reasonable have return value as timeout.
Why you think it is a bug in hardware?
>
>> 2. hub 4-0:1.0: hub_port_status failed (err = -32)
>> the -32 is due to below error label we set retval = -EPIPE
>> error:
>> /* "stall" on error */
>> retval = -EPIPE;
>
> But... This will happen only the first time we get the port status.
> After that, ehci->reset_done[wIndex] will be 0 and so handshake() won't
> get called.
>
> hub_port_status() calls get_port_status(), which performs the operation
> up to 3 times. The first time it will fail with -EPIPE, but what about
> the second time?
>
in hub_port_reset, there PORT_RESET_TRIES, 5 in right now definition
to reset port.
and ehci->reset_done[wIndex] will refilled the (jiffies + 50ms) when
set port reset.
if in all PORT_RESET_TRIES loops, there is no device connected.
We will get -EPIPE all the time, right?
for (i = 0; i < PORT_RESET_TRIES; i++) {
status = set_port_feature(hub->hdev, port1, (warm ?
USB_PORT_FEAT_BH_PORT_RESET :
USB_PORT_FEAT_RESET));
if (status) {
dev_err(hub->intfdev,
"cannot %sreset port %d (err = %d)\n",
warm ? "warm " : "", port1, status);
} else {
status = hub_port_wait_reset(hub, port1, udev, delay,
warm);
if (status && status != -ENOTCONN)
dev_dbg(hub->intfdev,
"port_wait_reset: err = %d\n",
status);
}
........................
........................
}
appreciate your kind explanation,
--
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
