Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 13 Nov 2019 20:50:10 +0000
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
Message-ID: <20191113205010.GY11244@42.do-not-panic.com>
References: <20191103180646.34880-1-sir@cmpwn.com>
 <20191113005628.GT11244@42.do-not-panic.com>
 <robbat2-20191113T195158-869302266Z@orbis-terrarum.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE"
Content-Disposition: inline
In-Reply-To: <robbat2-20191113T195158-869302266Z@orbis-terrarum.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--Kj7319i9nmIyA2yE
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEENnNq2KuOejlQLZofziMdCjCSiKcFAl3MbHsACgkQziMdCjCS
iKd3Nw//RxzcY2Mjyw2f+UtCBV8rIRfl5oyu4HTDDyy0DnCjL0zBQtWqIdTkP4oI
jYd6QnYDRO929sBkagad6c5tWTKd9kup8cpyrpZsRZ/FtYoo/0QC/Jyww1pea2gJ
J/aKwHpBti4lKTz5dwqWM5Vh2EVyMhQmNeMYQiXc03FhGDaFa6RRIjdkWsTQdfjK
rIIj2dWiquzVwUadro4TfLPU2ZLd06vBwG7dO1FSd7IPlFMxslz+uyH2udND2NTf
hEZXonNrgoDm6nfv8ZrQWRVQdb2efg5d2K5EAWS2HWz6dzemL7FFJaSxtKf9Gbsi
c4cdpWGKBKsQmGSG7+Cylu2W0qQvYFzYlKVb37s8eozWPRfQPh0P9KY/QHqrPXtv
avQe72l1uht70/LwBP7Q8BT1UqberV/waqqY5xLRjyntOkUnUbgyf3ztUMGZTvTj
YlBVil3fpLzWtgIL527toPD+49ntQ1c0+sxryvlUg8LfWm4VxmT4aJKfIYMLIvbR
49qy/ouUqmz4iL3h0KplqEVnVvTHRdbY4DZ0DOfcT2DRc4sCjqjKDJ0odrskuNDf
rHnTqjU0QasgMOeIhXQLoiUK7wr1fWJZ4/JIet2sewi9UNPhEvPMtQLC7TzXppfF
7fj2/ZxjdKh1Gxe+KDm2M0omMj4bqJJJMny4da+yftmBY7fzJqk=
=sLKK
-----END PGP SIGNATURE-----

--Kj7319i9nmIyA2yE--