[RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Rodrigo Vivi]

On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote:
> On Mon, 16 Apr 2018, "Srivatsa, Anusha" <anusha.srivatsa at intel.com> wrote:
> >>-----Original Message-----
> >>From: Jani Nikula [mailto:jani.nikula at linux.intel.com]
> >>Sent: Wednesday, April 11, 2018 5:27 AM
> >>To: Ian W MORRISON <ianwmorrison at gmail.com>
> >>Cc: Vivi, Rodrigo <rodrigo.vivi at intel.com>; Srivatsa, Anusha
> >><anusha.srivatsa at intel.com>; Wajdeczko, Michal
> >><Michal.Wajdeczko at intel.com>; Greg KH <gregkh at linuxfoundation.org>;
> >>airlied at linux.ie; joonas.lahtinen at linux.intel.com; linux-kernel at vger.kernel.org;
> >>stable at vger.kernel.org; intel-gfx at lists.freedesktop.org; dri-
> >>devel at lists.freedesktop.org
> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for
> >>Geminilake
> >>
> >>On Wed, 11 Apr 2018, Ian W MORRISON <ianwmorrison at gmail.com> wrote:
> >>> <snip>
> >>>
> >>>>
> >>>> NAK on indiscriminate Cc: stable. There are zero guarantees that
> >>>> older kernels will work with whatever firmware you throw at them.
> >>>>
> >>>
> >>> I included 'Cc: stable' so the patch would get added to the v4.16 and
> >>> v4.15 kernels which I have tested with the patch. I found that earlier
> >>> kernels didn't support the 'linux-firmware' package required to get
> >>> wifi working on Intel's new Gemini Lake NUC.
> >>
> >>You realize that this patch should have nothing to do with wifi?
> >>
> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please indicate the specific
> >>versions of stable it is appropriate for.
> >
> > Hi Jani,
> >
> > The stable kernel version is 4.12 and beyond.
> > It is appropriate to add the CC: stable in my opinion
> 
> Who tested the firmware with v4.12 and later? We only have the CI
> results against *current* drm-tip. We don't even know about v4.16.
> 

I understand your concerns, but the problem was that our old process
was a bit (lot?) messed and there was the unreliable time
until the firmware really lands on linux-firmware.git. So MODULE_FIRMWARE
call was only added after firmware was really there on firmware repository
but it wasn't about the testing.

In other words, the bump version patch was merged after tested, but
MODULE_FIRMWARE was left behind because firmware blob took a while to get
pulled into linux-firmware.git and we end up forgetting to add it there.

In my opinion it should be safe to add the MODULE_FIRMWARE there
based on the tests from when the version was bumped.

> I'm not going to ack and take responsibility for the stable backports
> unless someone actually comes forward with credible Tested-bys.
> 
> BR,
> Jani.
> 
> 
> >
> > Anusha
> >>BR,
> >>Jani.
> >>
> >>>
> >>>>
> >>>> PS. How is this a "RESEND"? I haven't seen this before.
> >>>>
> >>>
> >>> It is a 'RESEND' for that very reason. I initially sent the patch to
> >>> the same people as a similar patch
> >>> (https://patchwork.kernel.org/patch/10143637/) however after realising
> >>> this omitted required addresses I added them and resent the patch.
> >>>
> >>> Best regards,
> >>> Ian
> >>
> >>--
> >>Jani Nikula, Intel Open Source Technology Center
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel