On Thu, 28 Apr 2016, David Weinehall <david.weinehall@xxxxxxxxxxxxxxx> wrote: > On Mon, Apr 25, 2016 at 04:22:10PM -0700, tom.orourke@xxxxxxxxx wrote: >> From: Tom O'Rourke <Tom.O'Rourke@xxxxxxxxx> >> >> Load guc firmware from file with major_minor number >> in filename instead of using symolic link with only >> major number. > > What's the justification for this change? Either a release > breaks ABI (or has fixes that are so important that they're > worth treating as equivalent to an ABI-break) and thus warrants > a major-number bump, or it's a minor (non-ABI-breaking) fix, > which would then fit fine within a minor number bump. > > Since the firmware is released separately from the driver > this will most likely lead to more cases where the system ends up > running without any firmware loaded at all. Is that case better > than having an older revision of the same major release of the > firmware? The patch could use a more detailed commit message. This is what I wrote on the matter previously. On Tue, 22 Mar 2016, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > I think we should move to accepting only specific firmware versions in > the driver instead of having an illusion of forward compatible firmware > minor versions. > > By accepting any firmware with minor version greater than required, we > create a huge testing burden on all prior released kernels when we > release a new firmware version. We don't have the resources for > that. But we also can't just go ahead and release firmware versions that > might break stable kernels in distros out there. > > We need to turn this the other way round. We need to make releasing > firmware versions easy, and add the testing burden to the single kernel > commit that accepts a new firmware version. We already have CI in place > for that. > > We (and the distros) can then *choose* to backport the commits that > enable newer firmware versions, instead of having this control (or lack > thereof) in the firmware release process. For clarification, first, I don't reject the possibility of accepting multiple specific firmware versions, and second, the minor versions *should* be forward compatible but we don't know for sure without testing against each and every kernel that might load said firmware version. The combinations just explode. I have not looked into all the details here, but in general this is Acked-by: Jani Nikula <jani.nikula@xxxxxxxxx> Maybe we should also consider cc: drm-intel-fixes or even cc: stable. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
