> You mensioned earlier about not being able to tell the difference > between a device that needs firmware and one that needs flash (e.g. they > use exactly the same ids). It doesn't really matter - we just assume > that it might need firmware and load it anyway. It uses more memory but > is robust. We only need to do that for the devices where order and not blocking matters. There are a few (and some are video) where the firmware sizes is megabytes, which on an embedded controlling device is not acceptable. I don't believe any of them are things where simply delaying the restoration will cause problems however - its video, and DVB and the like not wireless or serial. Thankfully most of the firmwares for controllers like wireless are in the Kb range although this is going to change dramatically as people start putting things with more brains than an 8051 or AVR into their devices. And there an awful lot of devices with tiny 8K or so firmware where if we have get/put firmware nobody is going to *care* if we just cache it on module load. 40K driver, 16K of buffers, 2K firmware.... > Also, as Linus mensioned, for some devices we just don't care. For > example, if we drop a video call over suspend it's not ideal but it > doesn't prevent the system from resuming. Doesn't work generically though. Some ARM platforms (and Moorestown in the x86 world) can suspend/resume as a power state. So while it's probably true for USB it's not generically a property of suspend/resume that you can assume in any kind of firmware and ordering model. The world is heading this way more and more. It's moving from the old PC model of 'user closes lid, clunk for 15 seconds, enter suspend, user opens lid, churn churn, video, churn clunk. resume' to suspend/resume being so fast it happens between keystrokes. (There is a whole other can of pending worms there where 'suspend' isn't a single state as Linux and ACPI like to pretend. There are devices that can show the display while the machine is "suspended", devices that can play back mp3 files while the machine is "suspended" and so on. Imagine a world where you are listening to music on your phone without interruption, typing on the display which is showing all the time, and with the CPU and at the Linux level your device is suspended between keystrokes) > Lets concentrate on fixing all the cases that could prevent resume (the "99%") > and fix the other devices later. The rules on regressions as stated by Linus are clear - no regressions. So we need to make it work again, then fix it nicely. Quite honestly the ugly cases with massive firmware files and the like really want deferring, and some do that anyway with a userspace loader for obvious reasons. Request_firmware really isn't very good for 'request bits of firmware one by one' either. Thankfully there are not many of them. Alan -- 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
