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
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.
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);
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 help,
--
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
