Re: [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-----Original Message-----
From: Nikula, Jani 
Sent: Monday, August 01, 2016 6:25 AM
To: Vivi, Rodrigo; Herbert, Marc; Deak, Imre; chris@xxxxxxxxxxxxxxxxxx
Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

On Wed, 20 Jul 2016, "Vivi, Rodrigo" <rodrigo.vivi@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux