On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:

On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:

quoted

For the new API a solution for "fallback mechanisms" should be
clean though and I am looking to stay as far as possible from the
existing mess. A solution to help both the old API and new API is
possible for the "fallback mechanism" though -- but for that I can
only refer you at this point to some of Daniel Wagner and Tom
Gunderson's firmwared deamon prospect. It should help pave the way
for a clean solution and help address other stupid issues.

The firmwared project is hosted here

https://github.com/teg/firmwared

As Luis pointed out, firmwared relies on
FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.

I know. But it does not mean that I cannot enable this option at kernel 
compile time.

Bigger problem is that currently request_firmware() first try to load 
firmware directly from VFS and after that (if fails) fallback to user 
helper.

So I would need to extend kernel firmware code with new function (or 
flag) to not use VFS and try only user mode helper.

I
don't see any reason why firmwared should not also support loading
calibration data. If we find a sound way to do this.

It can, but why should I use another daemon for firmware loading as 
non-systemd version of udev (and eudev fork) support firmware loading? 
I think I stay with udev/eudev.

As you can see from the commit history it is a pretty young project
and more ore less reanimation of the old udev firmware loader
feature.  We are getting int into shape, adding integration tests
etc.

The main motivation for this project is the get movement back in
stuck discussion on the firmware loader API. Luis was very busy
writing up all the details on the current situation and purely from
the amount of documentation need to describe the API you can tell
something is awry.

Thanks,
Daniel

-- 
Pali Rohár
pali.rohar@gmail.com