Re: about possible port reset when disconnect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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.

>         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);
>         }

Same goes for these bits.

Alan Stern

--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux