[Ksummit-discuss] [TECH TOPIC] Firmware signing

Mark Brown broonie at kernel.org
Wed Jul 29 11:57:10 UTC 2015


On Tue, Jul 28, 2015 at 11:54:28AM -0700, josh at joshtriplett.org wrote:
> On Tue, Jul 28, 2015 at 11:44:21AM -0700, James Bottomley wrote:

> > So in that case, what's the advantage of separating the firmware from
> > the driver?  If we can't update it without updating the driver, we could
> > just build it in and save a huge amount of hassle.

> Licensing, which is a large part of why we have request_firmware to
> begin with.  Let's not make distribution kernel maintainers' lives more
> difficult than they already are.

Also developer convenience when people are working on the firmware
(which presumably isn't built as part of the kernel build process).

> For the drivers I'm most familiar with, new versions of firmware have
> new filenames and are requested from userspace in most-preferred to
> least-preferred order.  The expectation of those drivers is that any
> given firmware version should be binary-identical.

> Are there drivers for which the expected firmware update cycle is *more*
> rapid than the kernel release cycle?  That would be quite a surprise,
> though not an unpleasant one.

Some of the audio ones are like this, especially during development -
firmware is used to get system specific callibration data (to account
for the plastics and the taste of the system integator).  Those
firmwares would need system specific lists which would be miserable.

The code firmwares themselves do also get updated rather rapidly at
times.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20150729/5be19dd3/attachment.sig>


More information about the Ksummit-discuss mailing list