hi Alan:
2014-04-03 20:52 GMT+08:00 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Thu, 3 Apr 2014, vichy wrote:
>
>> hi all:
>> I list my environment as below:
>> 1. Arm platform with ehci support
>> 2. plug in NTFS USB HD and play movie
>> 3. plug out device suddenly.
>>
>> I found there will be possibly that driver will reset port even there
>> is no device connected.
>> I purposely add below code in ehci-hub.c when we try to do port reset
>> @@ -1173,7 +1173,12 @@ static int ehci_hub_control (
>> ehci_writel(ehci, temp, status_reg);
>> + dbg_port (ehci, "in port reset sequence,
>> GetStatus", wIndex + 1, temp);
>> +
>> break;
>>
>> and I found driver will reset even device is disconnected like below log:
>> (I also attach full log in the mail)
>> tntfs info: NTFS volume version 3.1 (cluster_size 4096, PAGE_CACHE_SIZE 4096).
>> Platform-ehci Platform-ehci.0: detected XactErr len 19456/20480 retry 1
>> hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0002
>> hub 4-0:1.0: port 1, status 0000, change 0001, 12 Mb/s
>> Platform-ehci Platform-ehci.0: port 1 reset
>> Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus
>> port:1 status 000100 0 ACK sig=se0 RESET
>> usb 4-1: USB disconnect, device number 20
>> Platform-ehci Platform-ehci.0: port 1 reset error -110
>> Platform-ehci Platform-ehci.0: port 1 reset error -110
>> Platform-ehci Platform-ehci.0: port 1 reset error -110
>> Platform-ehci Platform-ehci.0: port 1 reset error -110
>> Platform-ehci Platform-ehci.0: port 1 reset error -110
>> hub 4-0:1.0: hub_port_status failed (err = -32)
>> hub 4-0:1.0: port_wait_reset: err = -32
>> hub 4-0:1.0: port 1 not enabled, trying reset again...
>> ....................
>>
>>
>> My questions are:
>> 1. from the log the reason why port reset shows is
>> test_bit(US_FLIDX_DISCONNECTING, &us->dflags) failed in usb_stor_port_reset
>> (in the log, I purposely dump_stack in usb_reset_and_verify_device)
>> Why even "USB disconnect" show, the "US_FLIDX_DISCONNECTING" is not
>> set up in time?
>
> Your log contains the explanation:
>
>> Platform-ehci Platform-ehci.0: port 1 reset
>
> This is where the reset starts.
>
>> Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus
>> port:1 status 000100 0 ACK sig=se0 RESET
>> usb 4-1: USB disconnect, device number 20
>
> And this is where US_FLIDX_DISCONNECTING gets set -- after the reset
> has already begun.
>
>> 2. shall we add below determination before port reset?
>> --- a/linux-3.8.2/drivers/usb/host/ehci-hub.c
>> ++ b/linux-3.8.2/drivers/usb/host/ehci-hub.c
>> @@ -1139,6 +1139,9 @@ static int ehci_hub_control (
>> case USB_PORT_FEAT_RESET:
>> if (temp & PORT_RESUME)
>> goto error;
>> +
>> + if (!(temp & PORT_CONNECT))
>> + goto disconnect;
>> /* line status bits may report this as low speed,
>> * which can be fine if this root hub has a
>> * transaction translator built in.
>
> We could add this, but it's not a big deal. The real question is why
> did this happen:
>
>> hub 4-0:1.0: hub_port_status failed (err = -32)
>
> hub_port_status should not return an error. It should have returned
> valid data, and the port status should have shown that the device was
> disconnected. Can you figure out why hub_port_status didn't work?
1. Platform-ehci Platform-ehci.0: port 1 reset error -110
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;
}
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;
thanks for your kind reply ^^
--
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
