From: Luis Chamberlain <mcgrof@kernel.org>
To: "Robin H. Johnson" <robbat2@gentoo.org>
Cc: Drew DeVault <sir@cmpwn.com>,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
" Rafael J. Wysocki" <rafael@kernel.org>,
~sircmpwn/public-inbox@lists.sr.ht
Subject: Re: [PATCH v2] firmware loader: log path to loaded firmwares
Date: Wed, 13 Nov 2019 20:50:10 +0000 [thread overview]
Message-ID: <20191113205010.GY11244@42.do-not-panic.com> (raw)
In-Reply-To: <robbat2-20191113T195158-869302266Z@orbis-terrarum.net>
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
On Wed, Nov 13, 2019 at 08:19:07PM +0000, Robin H. Johnson wrote:
> I have two uses cases overall:
> - log so you know exactly when it's loaded successfully (great if
> loading a firmware causes your system to lock up a few seconds later)
Then you can change the driver to confirm this, not impose every driver
to do the same.
> - at some point in the future, being able to query what firmware was
> loaded in the past, and esp. exactly what version/data was in that
> firmware file.
Firmware data is opaque to the firmware loader, as such details to
extract generic information about firmware details can only be done
by the driver, which could decode the firmware information. Many
drivers print these details themselves already, if they want it.
A generic interface to let us query *all* devices and currently loaded
firmware through the firmware loader would only be possible today for
firmware which requests (the default) caching of firmware upon
suspend/resume given that we keep the device / firmware name pair
around prior to suspend. For those devices it could be possible to
extend the firmware loader with a driver callback which can extract
firmware details in a generic codified way. To support *all* drivers
though, in a more clean way for this, a separate but similar list
could be kept which enables one to do this. Such items would be
torn down upon driver removal. But that would then be an opt-in
new mechanism.
Luis
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-11-13 20:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-03 18:06 [PATCH v2] firmware loader: log path to loaded firmwares Drew DeVault
2019-11-13 0:56 ` Luis Chamberlain
2019-11-13 14:05 ` Drew DeVault
2019-11-13 20:19 ` Robin H. Johnson
2019-11-13 20:50 ` Luis Chamberlain [this message]
2019-11-17 18:46 ` Drew DeVault
2019-11-17 23:47 ` [PATCH v3] firmware: log name & outcome of loaded firmware Robin H. Johnson
2019-11-18 17:53 ` Greg KH
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=20191113205010.GY11244@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robbat2@gentoo.org \
--cc=sir@cmpwn.com \
--cc=~sircmpwn/public-inbox@lists.sr.ht \
/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