On Tue, 29 Mar 2011, Sarah Sharp wrote: > 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? In theory, no. The SCSI disk device will get suspended before the USB interface, which should cause the drive to be spun down. > 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 didn't have a clear proposal in mind. Turn off the port power feature, change the port's link state, maybe even do nothing at all. Just avoid returning an error code. The idea was that it won't require much of a change to allow systems to suspend, especially if you don't try to make sure that the devices-behind-hubs are still working properly after the system resumes. A small patch to do that would count as a bug fix and would be acceptable for 2.6.39. And it wouldn't make things any worse than they are now, considering that people can't suspend at all. > 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. During resume you don't have to do anything, since for 2.6.39 we don't care whether the device continues to work, degrades to USB-2 operation, or stops working entirely. > 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. And regardless of whether you consider it to be a bug fix or not, it's definitely not a regression fix because the device never did work. 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
