On July 30, 2016 9:58:17 AM PDT, "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx> wrote:
On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote:
On 29-07-16 08:13, Daniel Wagner wrote:
On 07/28/2016 09:01 PM, Bjorn Andersson wrote:
On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote:
+ Luis (again) ;-)
Do not quite like it... I'd rather asynchronous request give out
firmware status pointer that could be used later on.
Excellent. Why not get rid of the callback function as well and have
fw_loading_wait() return result (0 = firmware available, < 0 = fail).
Just to confirm, you are proposing a new API function next to
request_firmware_nowait(), right?
If proposing new firmware_class patches please bounce / Cc me, I've
recently asked for me to be added to MAINTAINERS so I get these
e-mails as I'm working on a new flexible API which would allow us
to extend the firmware API without having to care about the old
stupid usermode helper at all.
I am not sure why we started calling usermode helper "stupid". We
only had to implement direct kernel firmware loading because udev/stsremd
folks had "interesting" ideas how events should be handled; but having
userspace to feed us data is not stupid.
If we want to overhaul firmware loading support we need to figure
out how to support case when a driver want to [asynchronously] request
firmware/config/blob and the rest of the system is not ready. Even if we
want kernel to do read/load the data we need userspace to tell kernel
when firmware partition is available, until then the kernel should not
fail the request.