RE: [PATCH v2] platform/x86: dell-laptop: Allocate buffer on heap rather than globally

[<Mario.Limonciello@dell.com>]

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Monday, February 5, 2018 6:58 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: andy.shevchenko@gmail.com; pali.rohar@gmail.com; linux-
> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org
> Subject: Re: [PATCH v2] platform/x86: dell-laptop: Allocate buffer on heap rather
> than globally
> 
> On Mon, Feb 05, 2018 at 04:49:35PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > > Sent: Sunday, February 4, 2018 8:28 AM
> > > To: Pali Rohár <pali.rohar@gmail.com>
> > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Darren Hart
> > > <dvhart@infradead.org>; LKML <linux-kernel@vger.kernel.org>; Platform
> Driver
> > > <platform-driver-x86@vger.kernel.org>
> > > Subject: Re: [PATCH v2] platform/x86: dell-laptop: Allocate buffer on heap
> rather
> > > than globally
> > >
> > > On Sun, Feb 4, 2018 at 2:09 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > On Wednesday 31 January 2018 11:47:35 Mario Limonciello wrote:
> > > >> There is no longer a need for the buffer to be defined in
> > > >> first 4GB physical address space.
> > > >>
> > > >> Furthermore there may be race conditions with multiple different functions
> > > >> working on a module wide buffer causing incorrect results.
> > > >>
> > > >> Fixes: 549b4930f057658dc50d8010e66219233119a4d8
> > >
> > > He-h, I had to notice this earlier...
> > >
> > > > Ok, you can add my:
> > > > Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
> > >
> > > Thanks and sorry, Pali, it's in for-next already, can't rebase.
> >
> > Andy,
> > Since it's already in for-next it's probably too late to add the stable CC too right?
> >
> > So what's the proper time now to send this to @stable?  And should I just forward
> existing
> > patch?
> 
> As a general rule, Andy and I should be adding Cc stable to most anything that
> includes a Fixes tag that isn't from this review cycle. I've forgotten in the
> past as well - sorry about that. Something we should add some tooling around I
> think, so we don't miss it when checking things in to our review branches.
> 
> As to timing. As soon as this is merged to Linus' master, it can go to stable.
> Instructions for doing this are in Documentation/process/stable-kernel-rules.rst
> 
> --

Thanks, I see it's in Linuses' tree today so I sent something to stable for it.