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

[Vivi, Rodrigo]

So, issues like https://bugs.freedesktop.org/show_bug.cgi?id=97182

will appear with frequency now...

should we just close all as wontfix?

On Wed, 2016-08-03 at 17:02 +0200, Daniel Vetter wrote:
> On Wed, Aug 3, 2016 at 11:08 AM, Jani Nikula
> <jani.nikula at linux.intel.com> wrote:
> > 
> > > 
> > > > 
> > > > 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.
> +1
> 
> We discussed why symlinks are not a great pick for gpus at length,
> all
> those reasons are still valid. Mostly it boils down to that the
> actual
> interface between gpu components is _extremely_ wide, and includes
> all
> kinds of fun things like minute timing details, w/a settings and
> really just everything.
> 
> I'd say for the same reasons we only support open source userspace
> drivers (anything else can't be audited when it breaks and debugged)
> we need to restrict the combinatorial interaction madness with
> firmware. If that makes gpus special in yet another way, so be it.
> -Daniel