> 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. > > It would not be made any better by an asynchronous approach, and that > isn't the problem with request_firmware(). > > 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. > > 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? > > And making it asynchronous doesn't make it *any* less of a bug. It > doesn't change anything but timing, but the problem was never about > timing in the first place! The problem was about dependencies. User > space may well depend on the device, and *other* devices may well > depend on the device working. > > So stop with the inanity. I've already told people what the fix is: > make sure that the firmware image is in memory before the suspend ever > happens, and just reload it from memory. NOT with > "request_firmware()". Because requesting the firmware at resume time > is buggy and wrong, and has nothing to do with "asynchronous" or > "synchronous". It has everything to do with "it's buggy". > > Really really really. > > So the problem with request_firmware() has absolutely nothing to do > with "asynchronous". The problem is that the firmware interfaces do > not cache the data in memory, and currently *cannot* sanely cache the > firmware data simply because the interface doesn't have any kind of > lifetime rules. > > In other words: we could make "request_firmware()" cache *all* > firmware images forever, but there is currently no way to say "ok, the > device was unplugged - and not fakily so by a resume event, but for > real, and physically - so now you can drop the cache". Which means > that effectively request_firmware() can do no caching at all, because > it might eventually just run out of memory. > > It is *possible* that we might tie the firmware lifetime rules to the > driver module lifetime. But it would probably be much better if we > made for an explicit model of "ok, the device is now really gone" so > that it would work properly with compiled-in drivers etc too. > > And yes, the firmware would have to stay around even around a > resume/suspend that causes unplug events over USB. The "use USB and > lose power" actually happens also for built-in devices that may well > be disks and network cards that are *needed* by user space, so even if > the device has been electrically unplugged, it is still attached and > needs to be brought back *before* user space comes back. > > That's the whole point of suspend/resume: we're not starting from a > clean slate. We are supposed to continue as if nothing happened! > > Linus FYI this is not only problem with USB, but with PCMCIA too for example. M -- 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
