On Tue, 3 Jan 2012, Alexander E. Patrakov wrote:
Matthew Garrett <mjg@xxxxxxxxxx> wrote:
On Mon, Jan 02, 2012 at 01:27:03PM -0800, Linus Torvalds wrote:
If we didn't load the firmware before the suspend, then the resume
function of a device sure as hell had better not load it at resume
time either.
If the hardware has lost its state then refusing to load the firmware
at resume time isn't going to leave you with a working device.
And for chrissake, don't bother making it more complicated than it
is, just for some theoretical hardware or situation that nobody
cares about.
It's not theoretical hardware. This appears to be the current
behaviour of the isight devices. If you reboot they retain their
firmware. If you suspend, they don't. So if we have a flow like this:
1) user boots from cold. Device comes up with generic USB ID.
2) isight_firmware loads and binds. Firmware is loaded. Device
disconnects and reconnects with an ID that's bound by the UVC driver.
3) user reboots. Device comes up with UVC ID. isight_firmware doesn't
bind.
4) user suspends.
5) user resumes. isight_firmware binds and attempts to load firmware.
then just caching the firmware is inadequate - we had never
previously seen the device on this boot, so we've never loaded it in
order to cache it. isight_firmware could unconditionally load the
firmware on module load just in case a device is plugged in, but that
seems even less elegant than caching it.
What a heated discussion due to, essentially, a non-technical, legal
issue! Remember that the whole "userspace firmware loader" saga
together with the asynchronous firmware interface started when Debian
started complaining over the non-freeness of the firmware being bundled
as a part of the kernel module as an array of bytes. That design,
however, never had such dependency issues. So maybe revert to it, with
the following changes, and solve the legal issue seen by Debian by
hiring a lawyer?
at the very least, there should be a simple compile option that says
'compile any firmware that may be needed into the kernel/module image' so
that those of us who are not worried about the distribution of firmware
blobs (or who don't believe that just splitting the firmware blobs into
a separate tree gains anything) can just opt out of this entire mess. As I
see it, today we have the option of manually specifying firmware blobs to
compile in, but no easy way to just include them all.
1. Make firmware a special case of a data-only non-GPL kernel module.
Change the tainter so that it doesn't taint the kernel for data-only
modules.
2. Make the actual driver depend on the relevant firmware modules for
all devices supported by it, even if the devices don't always need the
said firmware.
3. Disallow building drivers that need firmware as non-modules.
Please do not do this one.
David Lang
4. Do something (e.g. split the driver into a core and a shim, or make
a fake firmware module) to allow the user to install without firmware
if he knows that it works with his hardware.
5. Profit!
This way, as long as the driver is loaded, the necessary firmware is
also there, as a dependency.
--
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
