On Mon, Aug 01, 2016 at 10:19:51AM -0700, Bjorn Andersson wrote:

On Sat 30 Jul 09:58 PDT 2016, Luis R. Rodriguez wrote:

quoted

On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote:

quoted

+ Luis (again) ;-)

On 29-07-16 08:13, Daniel Wagner wrote:

quoted

On 07/28/2016 09:01 PM, Bjorn Andersson wrote:

quoted

On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote:

quoted

On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote:

quoted

From: Daniel Wagner <redacted>

[..]

quoted

Do not quite like it... I'd rather asynchronous request give out a
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.

In the remoteproc world there are several systems where we see 100+MB of
firmware being loaded. It's unfeasible to have these files in an
initramfs, so we need a way to indicate to the kernel that the
second/primary (or a dedicated firmware partition) is mounted.

We're currently loading these files with request_firmware_nowait(), so
either one can either use kernel modules or the user-helper fallback to
delay the loading until the files are available. (I don't like to
enforce the usage of kernel modules)

Now that the firmware API is sharing the same API call to read files
the existential issue of the file is not unique issue of firmware,
but also to any other caller of it.

I'm open to alternative ways of having firmware loading wait on
secondary filesystems to be mounted, but have not yet tried to tackle
this problem. I do believe something that waits and retries the firmware
load as additional file systems gets mounted would be prettier than
forcing user space to tell us it's time to move on.

Agreed. We simply have not addressed this problem yet. Let's discuss a
possible solution on the other reply thread I provided with more details
to Dmitry.

Due to the size of these firmware files we release the firmware as soon
as we have copied the content into the appropriate memory segments, so
we're not utilizing the caching mechanisms of the current fw loader.

BTW my goal with the sysdata API is to automatically free this for you too :)

  Luis