[Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name
Imre Deak
imre.deak at intel.com
Mon Jul 11 12:45:21 UTC 2016
On ma, 2016-07-11 at 13:39 +0100, chris at chris-wilson.co.uk wrote:
> On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> > On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> > > "Vivi, Rodrigo" <rodrigo.vivi at intel.com> writes:
> > >
> > > > Nak.
> > > >
> > > > I don't intend to update the symbolic links on linux-
> > > > firmware.git
> > > > repository anymore so if we receive a new minor version update
> > > > we
> > > > are
> > > > not going to load.
> > > >
> > > > I was the one advocating in the favor for the symbolic link
> > > > flexibility
> > > > but I lost the discussions for the stability and validation
> > > > etc.
> > > >
> > >
> > > And I was one advocating in favor of getting rid of symlink. But
> > > the
> > > filename versioning is superfluous as the contents has the
> > > version
> > > info
> > > which we can solely rely to not run something we dont want.
> > >
> > > So I am not sure what we lose in stability and validation front
> > > with the strict version check.
> >
> > Bisection is more cumbersome with a symlink.
>
> Did you miss a without there? Because when bisecting the kernel it's
> harder without the symlink as the build breaks otherwise and the
> runtime
> is not bisectable either.
No, I meant when bisecting we also want to load the proper fw version
for each bisect commit point. So using exact filenames we'll
automatically load the proper firmware file for a given commit, whereas
with symlinks we have to adjust the symlink at each bisect step.
You need to have all the required FW versions for the bisect range to
be present on the filesystem of course.
--Imre
More information about the Intel-gfx
mailing list