lkml.org 
[lkml]   [2017]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] firmware: wake all waiters
On Tue, Jun 27, 2017 at 10:48:25AM -0700, Bjorn Andersson wrote:
> On Mon, Jun 26, 2017 at 7:10 PM, Jakub Kicinski
> <jakub.kicinski@netronome.com> wrote:
> > On Mon, 26 Jun 2017 23:20:36 +0200, Luis R. Rodriguez wrote:
> [..]
> > - how to stay bound and retry the direct default FW load until rootfs
> > is mounted (equivalent to when -EPROBE_DEFER would give up);
>
> If you constrain this problem to only await the mounting of a root
> file system you miss the various cases where rootfs is later pivoted

I do believe the firmwared case can work with pivot root, I can't see
why not. In fact it was a case considered from what I can tell

> or the firmware isn't stored in the root file system (e.g. every
> Android device out there).

This was also considered as part of the design. I had particular mentioned
to Tom and Daniel the case of an NVRAM sitting somewhere custom and this
needed to be tossed laster somehow thorugh some custom mechanism.

Let's consider a crazy case where the uevent gets triggered, and userspace goes
and signals Elon Musk somehow to transmit the needed firmware from Mars through
a serial satellite link to earth, and somehow someday the device is finally
ready to upload firmware from userspace. Once Elon's firmware lands home, we
know all needed firmware has arrived so anything missing we can acknowledge now
as missing, so we upload what we can and kick firmward into final-mode to tell
the kernel we know we're really ready and any pending things will have to be
given up.

This would prove the custom fallback crap was also never needed.

I think perhaps one enhancement consideration here may be having the option
for best-effort mode and final-mode be per file, but that's all daemon
specific code.

Luis

\
 
 \ /
  Last update: 2017-06-27 20:03    [W:0.135 / U:0.896 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site