Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On Tue, Jul 28, 2015 at 11:54:28AM -0700, josh@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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]