[Intel-gfx] linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Jani Nikula]

On Wed, 03 Aug 2016, Ben Hutchings <ben at decadent.org.uk> wrote:
> [ Unknown signature status ]
> On Tue, 2016-08-02 at 20:48 +0000, Vivi, Rodrigo wrote:
>> On Tue, 2016-08-02 at 14:04 +0300, Jani Nikula wrote:
> [...]
>> > Why are you deleting old versions?
>> 
>> Mainly to keep it clean. OSVs pack that entire repo, I don't want i915
>> taking unnecessary space from final users.
>
> Any filename requested by a driver in a stable release of Linux should
> not be removed from linux-firmware.git.  If it's buggy then it should
> be replaced it with a fixed version.  I can envisage extreme cases
> where we might make an exception but AFAIK this has not happened yet.

Rodrigo, https://bugs.freedesktop.org/show_bug.cgi?id=97182

> The OS vendor knows which kernel versions they want to support and
> which files can therefore be dropped.  I do that for Debian
> periodically.
>
>> 
>> I believe this is another point in favor of bringing the sym links
>> back.
>> 
>> But also because we need to remove any firmware that we know it is bad
>> and that would break the user. If it was blacklisted it was removed
>> from repo.
>>
>> Yet another reason for symbolic link. If we know the firmware is bad it
>> is bad for previous versions as well, but if we stay with the version
>> hardcoded we are forcing the user to stay with a firmware that we know
>> it is bad.
>
> Indeed.  Please don't put a full version number in the filenames
> requested by drivers.  Where it's not possible to maintain ABI
> compatibility between driver and firmware indefinitely then include an
> ABI version in the filename, but not the full version.

I'm starting to sound like a broken record, but here goes again.

We do not have the bandwidth to test all combinations of kernel and
firmware versions.

If we update linux-firmware to change the firmware blob to use (either
by changing where the symlink points or by replacing the file) we roll
out untested firmware/kernel combinations to stable kernel users.

IMO we should be specific which firmware version(s) to accept in the
kernel, limiting to known good and tested combinations. If there's a
need to update the firmware to use for stable kernels, it's a matter of
backporting the commit accepting another firmware version. This can be
done by us or an OSV.

Even when there's supposed to be ABI compatibility, I wouldn't liberally
roll out firmware updates across all past stable kernels without
testing. Anyone suggesting that obviously doesn't have to be in the
receiving end of the bug reports when things go wrong in mysterious and
non-bisectable ways.

I don't think it's a good idea to give the control of firmware version
selection to the user space and linux-firmware.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center