On Thu, 15 May 2014, Todd E Brandt wrote: > > Hmmm. Why did the kernel end up re-initializing those devices in the > > first place? Under normal circumstances that wouldn't happen when > > resuming from system suspend. > > > > If you were resuming from hibernation, then sure. But hibernation is > > pretty slow anyway. > > Good question, I see reset behavior in S3 often enough for it to seem normal > to me (even on different machines). In this case the USB WLAN was hotplugged > a few minutes prior to the suspend, so I'm not sure it was wholely configured. > If I take the system through another suspend/resume the WLAN doesn't get reset. > The KVM switch just does that every time, I'm not sure why (it's a TRENDnet > TK-409). It could be a bug with the hardware (maybe it should have been designed > with an external power supply but lacks one?) or just a quirk of this particular > device. > > Let me see if I can dig up some more cases of devices that get reset on S3 > resume to get a better understanding of how common it is. It should almost always be true that reset in S3 resume means the device also needs reset in runtime resume. The only exceptions would be cases where the firmware messes up the host controller setting during the transitions to/from S3. (This almost always happens with UHCI, but your test system doesn't have a UHCI controller.) > > bandwidth_mutex is a bad model, because when two buses share a single > > host controller, their bandwidth calculations have to be mutually > > exclusive (since they are carried out by the single controller). > > Whereas when two devices use address 0 on different buses, it doesn't > > matter if the two buses belong to the same controller. > > Maybe the hcd struct is a bad spot for the mutex to live on. I could add it > to the usb_hub struct but it would need to be on the root instance. I guess the best place would be the usb_bus structure. In fact, a bunch of things in the usb_hcd structure ought to go in usb_bus, but at this point it would be a huge job to move them. The reason for this is historical. Before USB-3, one bus = one HC. There was no clear criterion for distinguishing the fields that went with the bus from those that went with the HC. Now with USB-3 that's not true any more, and we can see that a number of fields ended up in the wrong place. 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
