> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Wednesday, March 30, 2011 4:20 AM > To: Alan Stern > Cc: Xu, Andiry; gregkh@xxxxxxx; linux-usb@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 0/5] USB3 hub support refine > > On Tue, Mar 29, 2011 at 10:17:30AM -0400, Alan Stern wrote: > > On Mon, 28 Mar 2011, Sarah Sharp wrote: > > > > > If you (and Greg) doesn't mind, I'd like to queue these patches for > > > 2.6.39, rather than 2.6.40. There are several OSV that are > complaining > > > that the USB 3.0 hub patches break suspend when a USB 3.0 device is > > > plugged in behind a USB 3.0 hub. As Alan Stern pointed out, Linus > > > really doesn't want new functionality to break suspend. So although > > > these patches are larger, I think they need to get into 2.6.39. > > > > Would it be feasible instead to include a simple band-aid change to > > 2.6.39, something that would permit the system to suspend even if USB-3 > > hubs aren't handled properly? Maybe power off all ports on external > > SuperSpeed hubs during suspend and then power them back on during > > resume? > > That might work. Andiry, is this something you could look into? > > However, wouldn't we be powering off hard drives while their disks are > spinning? Or were you thinking that instead of issuing a port suspend > command to the USB 3.0 hub when the device is supposed to be suspended, > to just power off the port instead with a clear port feature (port > power) command? > > I'm not entirely sure how USB 3.0 hard drives are going to react to > having their port power turned off. I suppose at that point they'll > migrate over to the USB 2.0 wires, since they all have external power > supplies anyway. Then during resume, we would have to re-enable port > power for those ports when the USB 3.0 roothub is resumed. Since the > USB 3.0 roothub should be resumed before any devices are reset on the > USB 2.0 roothub, I think this will work, but I'm skeptical that it's > going to be a smaller patchset that the current one Andiry created. > I've done some basic tests. Clear PORT_POWER during suspend and the system can suspend/resume normally, but after system resume, the USB3.0 device disappears. Simply set PORT_POWER does not help. The port link state is Inactive and I think a warm reset is needed. If you just want the system suspend/resume succeed, it's enough, but to make the device resume normally, more investigation is needed. Or do I miss something? If you want a simple single patch to fix the issue for 2.6.39, I think we can have a patch like this: use Set PORT_LINK_STATE request for SS devices behind a SS external hub. It works and I think it's more appropriate than clear/set port power. I've tested it and sent it out. If you think it's OK, you can queue the patch for 2.6.39 and I'll re-create the hub refine patchset, which can wait for 2.6.40. > > Then the full fix could be merged in 2.6.40. > > Hmm, I'm trying to figure out if there's anything in this patchset that > really qualifies as a bug fix, if we can solve the issue with devices > behind a USB 3.0 hub during system resume with a band-aid patch. > > Andiry said that the warm reset patches were needed to make a USB 3.0 > Kingston flash drive work: > > On Wed, Mar 23, 2011 at 02:54:01PM +0800, Xu, Andiry wrote: > > 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. > > So Andiry, I think you're saying to fix the enumeration of this device, > we need patches 1 and 4 out of your patchset? > > If we didn't take those patches, then this device won't work on 2.6.39. > But I suppose it's not a big deal if that fix gets delayed. > For the Kingston USB3.0 flash drive issue, I'm still figuring out the right place to set a BH_RESET request for it. It's not an urgent issue comparing to the USB3.0 device suspend/resume issue and I think it can wait for 2.6.40. Don't worry about that. 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
