On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote: > On Mon, 16 Apr 2018, "Srivatsa, Anusha" <anusha.srivatsa@xxxxxxxxx> wrote: > >>-----Original Message----- > >>From: Jani Nikula [mailto:jani.nikula@xxxxxxxxxxxxxxx] > >>Sent: Wednesday, April 11, 2018 5:27 AM > >>To: Ian W MORRISON <ianwmorrison@xxxxxxxxx> > >>Cc: Vivi, Rodrigo <rodrigo.vivi@xxxxxxxxx>; Srivatsa, Anusha > >><anusha.srivatsa@xxxxxxxxx>; Wajdeczko, Michal > >><Michal.Wajdeczko@xxxxxxxxx>; Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>; > >>airlied@xxxxxxxx; joonas.lahtinen@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > >>stable@xxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; dri- > >>devel@xxxxxxxxxxxxxxxxxxxxx > >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for > >>Geminilake > >> > >>On Wed, 11 Apr 2018, Ian W MORRISON <ianwmorrison@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
