On Thu, 13 Dec 2001 [EMAIL PROTECTED] wrote:
> Firstly, let me clarify that the problem is with _reloading_ firmware
> due to resumption from power management.
Absolutely. But note, that is not the only problem: If the driver has to
manage dynamic loading of different overlaid firmware images at runtime
for example you will pretty likely end up in the same situation. At least,
the download operations needs to be serialized with all other driver
activity on urb-level _and_ during download there is probably some window
where the device is not useable.
> Therefore no user space task can be running during resumption, unless it
> is totally mlocked.
> Managing firmwarereload in user space when you can neither open() nor
> fork() nor read() doesn't look so attractive, does it ?
Right. That's why I do like your suggestion, to have some centralized
in-kernel firmware loader. Note that an initrd is not sufficient to solve
the problem - we are not only dealing with boot time issues.
However, I do believe it is still a good idea to provide firmware images
from userland instead of having them compiled into the kernel. Not because
of some not-even-hypothetical GPL issue but simply to ease maintenance.
What about some kernel-entity (call it firmware-manager - details left to
implementation - think of "module" or "part of usbcore" or even
"firmware-fs", if you like the grand unified approach) which holds all the
firmware images for the system in kmalloc-ed areas (we are talking about a
few kB here, so the memory footprint shouldn't be an issue).
Firmware gets pushed to the firmware manager from an userland firmware
provider application - something like as simple as
cat device_fw_v1.0 > /firmware-fs/usb/vid/did/fw_id
to give you an idea. This can be done from initrd, if the firmware is
required while booting. Also note, this is pretty similar to what we
already have for /dev/microcode download to some CPU's.
On the other side a driver with firmware download requirements simply
registers to this firmware manager with its class (usb, pci, other...),
vid/did and list of required firmware id's. In the firmware-fs example
this would create the usb/vid/did/fw_id nodes so the firmware-provider
could start image donation from userland. Whenever the driver wants to
download some image, it issues a (nonblocking) request to the firmware
manager to retrieve it for downloading. If this fails (requested image to
found), the driver has all the knowledge to decide, whether it is possible
to try some usermode helper fallback or simply give up. On unload finally,
the driver unregisters from the manager and all its firmware images get
freed.
Depending on CONFIG-selection, the manager may provide some additional
download helpers like ezusb_write() for USB to be used by all appropriate
drivers. No need for duplication here.
> To summarise, we can either have firmware handling in user space or power
> management, but not both.
> More philosophically speaking, IMHO we have a classical layering violation
> caused by wishful thinking.
> To quote Dave: "There are many good reasons to have device handling in
> kernel space." I might add: They are sometimes less than obvious.
I think I see your point for the download vs. pm issue.
Additionally, if one thinks of other download requirement like demand
loading of overlays, I tend to believe handling firmware download in
kernel space is a good thing anyway. Unless one wants to restrict this to
simple load-once-at-init-or-resume - and IMHO, as you've pointed out, the
resume-case by itself provides enough good reason for in-kernel handling.
Regards,
Martin
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
