hi Alan:
2014-04-07 10:06 GMT+08:00 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Sun, 6 Apr 2014, vichy wrote:
>
>> hi alan:
>> >> Why you think it is a bug in hardware?
>> >
>> > The timeout error means that the kernel told the controller to turn off
>> > the PORT_RESET bit, and 1000 us later the bit was still on. That's a
>> > hardware bug.
>> after checking my hardware I found if device is no connected and do
>> the port reset,
>> the reset bit always will be 1 (I purposely add port status check in
>> set port reset case like below)
>>
>> 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
>
> Yep. That's a hardware bug.
>
>> from ehci spec, there did not mention what will HW to do if port reset
>> happens on no connection.
>> it only explain what controller needs to do when device is connected.
>
> Nonsense. The EHCI spec says this (in Table 2-16, the description
> for bit 8):
>
> ... Software writes a zero to this bit to terminate
> the bus reset sequence...
>
> ... Note that when software writes a zero to this bit there
> may be a delay before the bit status changes to a zero. The bit
> status will not read as a zero until after the reset has
> completed... A host controller must terminate the reset and
> stabilize the state of the port within 2 milliseconds of
> software transitioning this bit from a one to a zero.
>
> Thus, the bit is supposed to change to 0 after no more than 2 ms,
> whether a device is connected or not.
I got it.
At first glance of this part of spec, I only focus this behaviour when
device is connected.
^^
>
>> if related reset bit will automatically cleared for a while when
>> device is not connected.
>> Why we still need to clear them in hub_port_finish_reset like below flow
>> in hub_port_reset,
>> /* Check for disconnect or reset */
>> if (status == 0 || status == -ENOTCONN || status == -ENODEV) {
>> hub_port_finish_reset(hub, port1, udev, &status);
>> then in hub_port_finish_reset
>> case -ENOTCONN:
>> case -ENODEV:
>> clear_port_feature(hub->hdev,
>> port1, USB_PORT_FEAT_C_RESET);
>
> That's a different bit. USB_PORT_FEAT_C_RESET isn't the same as
> USB_PORT_FEAT_RESET.
what I am curious is,
if port reset bit will clear to 0 within 2ms, why we still need to
clear_port_feature with USB_PORT_FEAT_C_RESET
(clear Port reset )
>
>> if (hub_is_superspeed(hub->hdev)) {
>> clear_port_feature(hub->hdev, port1,
>> USB_PORT_FEAT_C_BH_PORT_RESET);
>> clear_port_feature(hub->hdev, port1,
>> USB_PORT_FEAT_C_PORT_LINK_STATE);
>> clear_port_feature(hub->hdev, port1,
>> USB_PORT_FEAT_C_CONNECTION);
>> }
Sincerely 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
