Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)

["Vivi, Rodrigo" <rodrigo.vivi@intel.com>]

But we know that 1.23 is bad and cause issues regardless the kernel
version. And please keep in mind this is the most common case.
Usually a previous minor version was dropped in favor of a new one
because we found a bug that got fixed in a following minor version.
This is the minor version idea. So regardless the kernel version, the
newest minor is probably safest than the previous one.

So, I don't want to keep all versions in linux-firmware.git, specially
those that we know that cause bad issues.

And here is the case were only symbolic link would help imho.

On Wed, 2016-08-03 at 17:08 +0200, Daniel Vetter wrote:
> On Wed, Aug 3, 2016 at 5:06 PM, Vivi, Rodrigo <rodrigo.vivi@intel.com
> > wrote:
> > 
> > So, issues like https://bugs.freedesktop.org/show_bug.cgi?id=97182
> > 
> > will appear with frequency now...
> > 
> > should we just close all as wontfix?
> It sounds like we should fix that by restoring 1.23. Certainly not
> WONTFIX. WONTIFXing regression is pretty much the only guaranteed way
> to terminally piss of Dave&Linus.
> -Daniel
> 
> > 
> > 
> > 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@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
> 
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx