On Sun, 1 Jan 2012, Linus Torvalds wrote: > On Sun, Jan 1, 2012 at 8:17 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > As Linus pointed out, the real problem here is the firmware loader. > > The way it is now, a driver can't always depend on the data being > > available, even during a normal boot. �It ought to use an asynchronous > > approach; then none of these problems would arise. > > WRONG. > > Alan, you're not getting it. Loading firmware as part of > suspend/resume is WRONG. Having read through the remainder of your message, I now see your point and agree with it. However, you misunderstood what I was trying to say. (For example, consider the issue of firmware loading during bootup. Wouldn't that work out better if an async approach was always used? And doesn't this argue that drivers should never do synchronous firmware loads?) The issue with firmware, USB, and suspend/resume involves several considerations. The basic fact is this: USB devices sometimes lose their firmware during suspend. Before the device can be used again, the firmware has to be reloaded. The question is how and when to reload the firmware. As a general rule, current drivers do this synchronously as part of their probe routine (though there are exceptions). For all I know, some drivers may try to do this even if the firmware is already loaded. The problem we face is that the USB core may call the probe routine during the resume procedure. And as we know, during resume is not a good time to load firmware. What Oliver and I have been discussing is delaying the probe call until after resume is finished, when userspace is back up and everything is operating normally again. It would be more awkward than the current code, but it definitely can be done. > It would not be made any better by an asynchronous approach, and that > isn't the problem with request_firmware(). Leaving aside questions about request_firmware()'s merits, consider what would happen if drivers loaded firmware asynchronously during probe. The USB core could call the probe routine while the system was resuming, the probe routine would return immediately, and the actual firmware load would not take place until later when userspace was operating. Then everything would look the same as if probe had been called after the system resume was finished. If, as mentioned parenthetically above, drivers should always load firmware asynchronously, then the USB core wouldn't need to be changed at all. > Suspend/resume is *special*, and it's special for a very simple > reason: unlike bootup or attaching a new device, suspend/resume > happens WHILE THE USER IS ACTIVE. > > Loading firmware at that time is wrong. It's impossible. You have to > have the firmware available *before* any processes might need it, but > at the same time actually loading the firmware may need help from user > space and/or other devices. It's a chicken-and-egg problem. Not in the case we have been discussing. There is no chicken-and-egg dependancy; no processes can need to use the device before the firmware is loaded because the old device instance has already been unregistered (and the new one won't be registered until after the firmware is loaded). > So let me repeat one more time: Loading firmware at resume time is a > device driver bug. Seriously. How many times do I have to say it? It sounds like you were thinking of a situation in which the driver would try to reload the firmware while keeping the device instance intact and available the entire time. That isn't what Oliver and I have been talking about. On the other hand, something very much like it may crop up in connection with reset-resume. Usually it doesn't, because a USB device without firmware generally presents a different set of descriptors from the ones it presents when the firmware is running. As a result, when the firmware is lost the device will change identities, and the USB core will not attempt a reset-resume. But it is possible that some devices might present the same descriptors with and without firmware. In such cases it would then be up to the driver to detect that the firmware was gone and arrange for it to be reloaded somehow -- before userspace wakes up. In this case your point is perfectly valid; the driver simply cannot rely on the firmware loader for this, whether synchronously or not. The only option is for the driver to cache the firmware. (Or give up entirely and unbind itself from the device -- but then how would it eventually rebind?) A similar problem can occur with USB drivers that don't support suspend/resume at all. Such drivers get unbound during suspend and then rebound during resume. When the probe routine runs for rebinding, it may try to reload the firmware -- even though the firmware is most likely still present. It's fair to say this really is a driver bug. 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
