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

From: Daniel Vetter <daniel@ffwll.ch>
To: "Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Cc: "Nikula, Jani" <jani.nikula@intel.com>,
	"Herbert, Marc" <marc.herbert@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915/dmc: Accept symbolic link in firmware name
Date: Wed, 3 Aug 2016 09:25:50 +0200	[thread overview]
Message-ID: <20160803072550.GC6232@phenom.ffwll.local> (raw)
In-Reply-To: <AC49CA744796934484854BF79A8D0E564AA9E062@FMSMSX113.amr.corp.intel.com>

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.
-Daniel

> 
> -----Original Message-----
> From: Nikula, Jani 
> Sent: Monday, August 01, 2016 6:25 AM
> To: Vivi, Rodrigo; Herbert, Marc; Deak, Imre; chris@chris-wilson.co.uk
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/dmc: Accept symbolic link in firmware name
> 
> On Wed, 20 Jul 2016, "Vivi, Rodrigo" <rodrigo.vivi@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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx