On Sat 30 Jul 09:58 PDT 2016, Luis R. Rodriguez wrote: > On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote: > > + Luis (again) ;-) > > > > 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: > > >> > > >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote: > > >>>> From: Daniel Wagner <daniel.wagner@xxxxxxxxxxxx> > > >>>> > > >> [..] > > >>> > > >>> 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) 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. 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. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
