[Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

[Jani Nikula]

On Wed, 03 Aug 2016, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Aug 03, 2016 at 06:00:14AM +0000, Vivi, Rodrigo wrote:
>> So, what should we do in cases like this missed 1.23? 
>> Close the bug as wontfix?
>> 
>> We are blocking users from upgrade the component, or worst, like in this
>> case where 1.23 was causing bugs we are removing at all and preventing
>> the user to have the extra power savings with another stable version of
>> the firmware.
>
> Restore the 1.23 version to the linux firmware repo imo. It's a
> regression, best way to fix it is by (partial) revert.

Yes, if there's a kernel out there that requires firmware 1.23, you need
to keep that version of the firmware in linux-firmware. This should be
obvious.

If you manage the firmware version bumps in kernel commits properly, you
can backport the firmware version bumps to appropriate stable kernels,
*after* you've ensured it doesn't cause other problems.

I don't think we should encourage users to upgrade firmware on their
own. It'll just blow up the firmware/kernel combinations and make it
harder for us to manage the bugs.

For testing, we could add a module parameter to have the driver request
a specific version of the firmware. _unsafe, of course.

Also, I never argued we should only accept *one* version. I believe we
could try one, and if it's not there, try another. Both tested versions
against that specific kernel. But this should be limited to not blow up
the combinations.

BR,
Jani.


> -Daniel
>
>> 
>> -----Original Message-----
>> From: Nikula, Jani 
>> Sent: Monday, August 01, 2016 6:25 AM
>> To: Vivi, Rodrigo; Herbert, Marc; Deak, Imre; chris at chris-wilson.co.uk
>> Cc: intel-gfx at lists.freedesktop.org
>> Subject: Re: [PATCH] drm/i915/dmc: Accept symbolic link in firmware name
>> 
>> On Wed, 20 Jul 2016, "Vivi, Rodrigo" <rodrigo.vivi at intel.com> wrote:
>> > We don't hardcode all userspace libraries in the userspace side for 
>> > the graphics stack and we do not validate all possible combinations of 
>> > libdrm, mesa, ddx, libva, etc... Why should we need this with 
>> > firmware?
>> 
>> Because the firmware blob is more like a binary kernel module that works with a specific kernel version than an open source userspace component written on top of a stable ABI.
>> 
>> You do not know what the firmware does, nor what the future versions of it will do. The kernel provides an ABI with a strict no regressions policy for its users. The firmware has no such guarantees, and it is expected to go hand in hand with the operating system versions it has been validated against. And as I've explained numerous times, we do not have the resources to validate all kernel releases against all firmware releases.
>> 
>> 
>> BR,
>> Jani.
>> 
>> 
>> --
>> Jani Nikula, Intel Open Source Technology Center
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center