In that case they can contain the firmware and mark it __init.
They need no RAM. They can even mark the code needed to put
firmware into the device as __init.
> And adding some kind of persistence in the mixture so firmware can be
> included in the kernel image and later discarded/reconsidered even
> in-kernel drivers (meaning non modules) can benefit. Coordinating with
> initramfs as Pavel suggested should bring best results in this case.
>
> Also, the hotplug event happens every time you call request_firmware(),
> not just on device load or upon initial connection. It is not the
> regular "device plug event" it is an special 'firmware' event. For
> example, on usb devices you would get two invocations of hotplug, one
> 'hotplug usb' and one 'hotplug firmware'.
>
> In the case of suspending to disk, you would have to make sure that the
> firmware for the device that holds the rest of the firmware is already
> in fwfs or whatever persistence method gets finally implemented.
How and what is the benefit? If you go low on battery you have to suspend,
there's no choice. This means that you have to have it in RAM always.
> > And do I understand you correctly, you propose that request_firmware()
> > wait for the hotplug script to write the firmware to sysfs?
>
> Yes.
>
> > That means that request_firmware() is unusuable from the usual
> > probe() methods.
>
> At least usb's probe() can sleep, but that is a good point. How about:
>
> int request_firmware_nowait (
> const char *name, const char *device, void *context,
> void (*cont)(const struct firmware *fw, void context)
> );
>
> Then you can call request_firmware_nowait providing an appropriate
> 'cont' callback and 'context' pointer. Then when your callback gets
> called with the firmware you finish device setup.
In this form unworkable. Removing a module could kill the machine.
That scheme requires that drivers formally register and unregister
with fwfs and provide module pointers.
An awful lot of overhead.
> > You cannot kill a part of the kernel if a script fails to perform
> > correctly for some reason.
>
> Good point. Since it is easily solvable by hand:
>
> echo 1 > /sysfs/class/firmware/dev_name/loading
> echo 0 > /sysfs/class/firmware/dev_name/loading
>
> I thought that it was OK. (I'll do the timeout)
No, it isn't. These writes must require CAP_HARDWARE, thus
is no good.
> > Even worse, you cannot detect the script terminating abnormally in
> > that design.
>
> Well, the device model doesn't provide that information :(
>
> It would be great if it did.
>
> Would a patch to wait for hotplug termination and provide termination
> status be accepted?
No, you must not wait for user space.
> Adding an 'struct completion' and 'int status' to the right place
> should be just about it.
>
> > You'd have to introduce some arbitrary timeout.
>
> OK, I'll do that for now.
>
> > It seems to me that you introduce three new problems to get rid of
> > one old problem.
>
> This is the kind of feedback I wanted, thanks a lot.
Sorry.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/