lkml.org 
[lkml]   [2012]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: loading firmware while usermodehelper disabled.
On Tue, 3 Jan 2012, Alexander E. Patrakov wrote:

> Matthew Garrett <mjg@redhat.com> 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.
>
>


\
 
 \ /
  Last update: 2012-01-03 10:27    [W:0.098 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site