> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Thursday, March 24, 2011 2:51 AM > To: Xu, Andiry > Cc: Alan Stern; linux-usb@xxxxxxxxxxxxxxx > Subject: Re: Possible issue in hub.c > > On Wed, Mar 23, 2011 at 02:54:01PM +0800, Xu, Andiry wrote: > > > -----Original Message----- > > > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > > > Sent: Tuesday, March 22, 2011 10:34 PM > > > To: Xu, Andiry > > > Cc: Alan Stern; linux-usb@xxxxxxxxxxxxxxx > > > Subject: Re: Possible issue in hub.c > > > > > > On Tue, Mar 22, 2011 at 06:26:42PM +0800, Xu, Andiry wrote: > > > > Hi, > > > > > > > > I'm checking the latest usb-next with USB3.0 hub changes. Following > code > > > from hub_port_status() in hub.c: > > > > > > > > if (*status & USB_SS_PORT_STAT_POWER) > > > > tmp |= USB_PORT_STAT_POWER; > > > > > > > > Here the driver checks if portstatus reports USB_SS_PORT_STAT_POWER. > > > > > > > > However, in GetPortStatus in xhci-hub.c, the driver does not report > > > USB_SS_PORT_STAT_POWER, it reports USB_PORT_STAT_POWER instead. Note > their > > > definitions are different. So the judgment will never be true. > > > > > > > > I think there is a legacy issue: USB3.0 spec has different > wPortStatus > > > and wPortChange definition from USB2.0 spec, but the xHCI driver uses > the > > > definitions in USB2.0 spec for a long time. Shouldn't we comply with > > > USB3.0 specification? > > > > > > Yes, the xHCI driver's hub emulation should comply with the USB 3.0 > > > specification, but only for the USB 3.0 roothub portion. The USB 2.0 > > > roothub portion should still report port status like a USB 2.0 hub. > > > Please patch any behavior that doesn't comply with that. > > > > > > > I agree. But the PLS field in PORTSC register also apply to USB2 > protocol ports, do we need to report them too? > > We should probably look at how the EHCI driver reports the USB 2.0 link > power state (L1 and L2), and emulate that in the xHCI USB 2.0 roothub. > > > > > (By doing that xHCI driver can report port link state of USB3 > protocol > > > ports to the usbcore too... Currently I'm debugging an issue in which > I > > > need usbcore to know the port link state of the ports, but xHCI driver > > > does not report it.) > > > > > > Yes, the xHCI driver doesn't report link port states yet. Patches > > > welcome. :) Are you working on Link PM patches then? > > > > > > > Link PM patches definitely need PLS report, but now I'm looking into a > Kingston USB3.0 flash drive issue. When hot plug the device to the USB3 > port, it cannot be detected. The port link goes into Recovery state, then > into Inactive state. Current Linux driver does not know how to handle that > state, and the emulation ends. According to USB3.0 spec, the driver should > issue a warm reset if this happens. I've verified that warm reset the port > can transition it to U0 state and emulation will succeed. When I'm making > the patches, I find that we need to get the USB3.0 roothub portion report > the port status comply to the USB3.0 specification. > > Yes, the USB core needs to be changed to issue a warm reset if hot reset > fails. Does this have anything to do with the new port state bit that > was added for 1.0 hosts (CAS, I think it was called?) that tells the > host controller when a device is attached, but the connect status change > bit can't be asserted because a warm reset is necessary? I was recently > looking at the 1.0 updates that need to be done, and I saw this change > in the specification. > CAS is only asserted when the Core Power Well is off, i.e. the xHC is in D3 state. This issue occurs when the xHC is D0 state, so it's different. And this issue only occurs with the Kingston USB3.0 flash drive, so I think it's not related to CAS. Thanks, Andiry -- 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
