From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
"Johannes Berg" <johannes@sipsolutions.net>,
"Pavel Machek" <pavel@ucw.cz>, "Daniel Wagner" <wagi@monom.org>,
"Tom Gundersen" <teg@jklm.no>,
"Pali Rohár" <pali.rohar@gmail.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Kalle Valo" <kvalo@codeaurora.org>,
"David Gnedt" <david.gnedt@davizone.at>,
"Tony Lindgren" <tony@atomide.com>,
"Sebastian Reichel" <sre@kernel.org>,
"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
"Aaro Koskinen" <aaro.koskinen@iki.fi>,
"Takashi Iwai" <tiwai@suse.de>,
"AKASHI Takahiro" <takahiro.akashi@linaro.org>,
"David Woodhouse" <dwmw2@infradead.org>,
"Bjorn Andersson" <bjorn.andersson@linaro.org>,
"Grazvydas Ignotas" <notasas@gmail.com>,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, "Michał Kazior" <kazikcz@gmail.com>
Subject: Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
Date: Wed, 17 May 2017 01:57:52 +0200 [thread overview]
Message-ID: <20170516235752.GM17314@wotan.suse.de> (raw)
In-Reply-To: <0c43c825-df2a-b427-4b67-f17fd644667f@broadcom.com>
On Tue, May 16, 2017 at 10:41:08AM +0200, Arend Van Spriel wrote:
> On 16-5-2017 1:13, Luis R. Rodriguez wrote:
> > On Fri, May 12, 2017 at 11:02:26PM +0200, Arend Van Spriel wrote:
> >> try again.. replacing email address from Michał
> >> On 12-5-2017 22:55, Arend Van Spriel wrote:
> >>> Let me explain the idea to refresh your memory (and mine). It started
> >>> when we were working on adding driver support for OpenWrt in brcmfmac.
> >>> The driver requests for firmware calibration data, but on routers it is
> >>> stored in flash. So after failing on the firmware request we now call a
> >>> platform specific API. That was my itch, but it was not bad enough to go
> >>> and scratch. Now for N900 case there is a similar scenario alhtough it
> >>> has additional requirement to go to user-space due to need to use a
> >>> proprietary library to obtain the NVS calibration data. My thought: Why
> >>> should firmware_class care?
> >
> > Agreed.
> >
> >>> So the idea is that firmware_class provides
> >>> a registry for modules that can produce a certain firmware "file". Those
> >>> modules can do whatever is needed. If they need to use umh so be it.
> >>> They would only register themselves with firmware_class on platforms
> >>> that need them. It would basically be replacing the fallback mechanism
> >>> and only be effective on certain platforms.
> >
> > Sure, so it sounds like the work that Daniel Wagner and Tom Gundersen worked
> > [0] on which provides a firmwared with two modes: best-effort, and final-mode,
> > would address what you are looking for but without requiring any upstream
> > changes, *and* it also helps solve the rootfs race remote-proc folks had
> > concerns over.
> >
> > The other added gain over this solution is if folks need their own proprietary
> > concoction they can just fork firmwared and have that do whatever it needs
> > for the specific device on the specific rootfs. That is, firmwared can be the
> > upstream solution if folks need it, but if folks need something custom they can
> > just mimic the implementation: best-effort, and and final-mode.
> >
> > Yet another added gain over this solution we can do *not* support the
> > custom fallback mechanism as its not needed, the udev event should suffice
> > to let userspace do what it needs.
> >
> > Lastly, if we did not want to deal with timeouts for the way the driver data
> > API implements it I think we might be able to do away with them for for async
> > requests if we assume there will be a daemon that spawns in final-mode eventually,
> > and since it *knows* when the rootfs is ready it should be able to do a final
> > lookup, if it returns -ENOENT; then indeed we know we can give up. Now, perhaps
> > how and if we want to deal with timeouts when using the driver data API for
> > the fallback mechanism is worth considering given it does not have a fallback
> > mechanism support yet. If we *add* them it would seem this would also put an
> > implicit race against userspace finishing initialization and running firmwared
> > in final-mode.
>
> Just to be clear. When you are saying "rootfs" in this story, you mean
> any (mounted) file-system which may hold the firmware. At least that was
> one of the arguments. In kernel space we can not know how the system is
> setup in terms of mount points, let alone on which mounted file-system
> the firmware resides.
Right, wherever the hell that thing is on, which could be on a crypic fuse
drive waiting for some bits to be decrypted from Elon Musk on a spaceship on his
way to Mars, and only userspace knows how to decrypt this thing through some
evil proprietary thing, way way after a full bootup.
> > Johannes, do you recall the corner cases we spoke about regarding timeouts?
> > Does this match what we spoke about?
> >
> >>> Let me know if this idea is still of interest and I will rebase what I
> >>> have for an RFC round.
> >
> > Since no upstream delta is needed for firmwared I'd like to first encourage
> > evaluating the above. While distributions don't carry it yet that may be seen as
> > an issue but since what we are looking for are corner cases, only folks needing
> > to deploy a specific solution would need it or a custom proprietary solution.
>
> Ok. I will go try and run firmwared in OpenWrt on a router platform.
> Have to steal one from a colleague :-p Will study firmwared.
The finale-mode is the trick.
> > [0] https://github.com/teg/firmwared.git
> >
> > PS.
> >
> > Note that firmware signing will require an additional file, the detached
> > signature. The driver data API does not currently support the fallback
> > mechanism so we would not have to worry about that yet but once we add
> > fallback support we'd need to consider this.
>
> Do you have references to the firmware signing design. Is the idea to
> have one signature and all "firmware files" need to be signed with it?
Nope, I'm afraid a lot has been discussed so best we can do is wait.
Luis
next prev parent reply other threads:[~2017-05-16 23:57 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0fd90416-f33c-a6be-14fd-5e964583e9cb@broadcom.com>
2017-05-15 23:13 ` [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data Luis R. Rodriguez
2017-05-16 8:41 ` Arend Van Spriel
2017-05-16 23:57 ` Luis R. Rodriguez [this message]
2017-06-23 21:53 ` Luis R. Rodriguez
2017-06-30 21:35 ` Arend van Spriel
2017-08-10 19:43 ` Luis R. Rodriguez
2017-05-17 12:06 ` Johannes Berg
2017-05-17 12:53 ` Pali Rohár
2017-05-17 13:04 ` Johannes Berg
2017-05-17 13:21 ` Pali Rohár
2017-05-17 13:22 ` Johannes Berg
2017-05-18 0:08 ` Bjorn Andersson
2016-12-24 16:52 [PATCH 0/6] wl1251: Fix MAC address for Nokia N900 Pali Rohár
2016-12-24 16:52 ` [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data Pali Rohár
2016-12-25 20:15 ` Arend Van Spriel
2016-12-25 20:46 ` Pali Rohár
2016-12-26 15:43 ` Pavel Machek
2016-12-26 16:04 ` Pali Rohár
2016-12-26 16:35 ` Pavel Machek
2017-01-03 17:59 ` Luis R. Rodriguez
2017-05-03 19:02 ` Arend Van Spriel
2017-05-04 2:28 ` Luis R. Rodriguez
2017-05-12 20:55 ` Arend Van Spriel
2017-01-27 7:33 ` Kalle Valo
2017-01-27 8:58 ` Arend Van Spriel
2017-01-27 9:43 ` Pali Rohár
2017-01-27 10:05 ` Arend Van Spriel
2017-01-27 10:10 ` Pali Rohár
2017-01-27 10:19 ` Arend Van Spriel
2017-01-27 10:34 ` Pali Rohár
2017-01-27 11:49 ` Kalle Valo
2017-01-27 11:57 ` Pali Rohár
2017-01-27 12:26 ` Kalle Valo
2017-01-27 12:53 ` Arend Van Spriel
2017-01-27 13:16 ` Pali Rohár
2017-01-27 13:11 ` Pali Rohár
2017-01-27 15:23 ` Kalle Valo
2017-01-27 15:41 ` Pali Rohár
2017-01-27 19:40 ` Pavel Machek
2017-01-30 17:53 ` Tony Lindgren
2017-01-30 18:03 ` Pali Rohár
2017-01-31 6:35 ` Kalle Valo
2017-01-31 15:59 ` Tony Lindgren
2017-02-01 8:33 ` Pali Rohár
2017-02-01 9:35 ` Michal Kazior
2017-01-29 17:10 ` Luis R. Rodriguez
2017-01-27 12:03 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170516235752.GM17314@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=aaro.koskinen@iki.fi \
--cc=arend.vanspriel@broadcom.com \
--cc=bjorn.andersson@linaro.org \
--cc=david.gnedt@davizone.at \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=ivo.g.dimitrov.75@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=kazikcz@gmail.com \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=notasas@gmail.com \
--cc=pali.rohar@gmail.com \
--cc=pavel@ucw.cz \
--cc=sre@kernel.org \
--cc=takahiro.akashi@linaro.org \
--cc=teg@jklm.no \
--cc=tiwai@suse.de \
--cc=tony@atomide.com \
--cc=wagi@monom.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).