[Intel-gfx] [PATCH] drm/i915/guc: Use major_minor version for filename

[Jani Nikula]

On Thu, 28 Apr 2016, David Weinehall <david.weinehall at linux.intel.com> wrote:
> On Mon, Apr 25, 2016 at 04:22:10PM -0700, tom.orourke at intel.com wrote:
>> From: Tom O'Rourke <Tom.O'Rourke at intel.com>
>> 
>> Load guc firmware from file with major_minor number
>> in filename instead of using symolic link with only
>> major number.
>
> What's the justification for this change? Either a release
> breaks ABI (or has fixes that are so important that they're
> worth treating as equivalent to an ABI-break) and thus warrants
> a major-number bump, or it's a minor (non-ABI-breaking) fix,
> which would then fit fine within a minor number bump.
>
> Since the firmware is released separately from the driver
> this will most likely lead to more cases where the system ends up
> running without any firmware loaded at all. Is that case better
> than having an older revision of the same major release of the
> firmware?

The patch could use a more detailed commit message.

This is what I wrote on the matter previously.

On Tue, 22 Mar 2016, Jani Nikula <jani.nikula at linux.intel.com> wrote:
> I think we should move to accepting only specific firmware versions in
> the driver instead of having an illusion of forward compatible firmware
> minor versions.
>
> By accepting any firmware with minor version greater than required, we
> create a huge testing burden on all prior released kernels when we
> release a new firmware version. We don't have the resources for
> that. But we also can't just go ahead and release firmware versions that
> might break stable kernels in distros out there.
>
> We need to turn this the other way round. We need to make releasing
> firmware versions easy, and add the testing burden to the single kernel
> commit that accepts a new firmware version. We already have CI in place
> for that.
>
> We (and the distros) can then *choose* to backport the commits that
> enable newer firmware versions, instead of having this control (or lack
> thereof) in the firmware release process.

For clarification, first, I don't reject the possibility of accepting
multiple specific firmware versions, and second, the minor versions
*should* be forward compatible but we don't know for sure without
testing against each and every kernel that might load said firmware
version. The combinations just explode.

I have not looked into all the details here, but in general this is

Acked-by: Jani Nikula <jani.nikula at intel.com>

Maybe we should also consider cc: drm-intel-fixes or even cc: stable.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center