From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424573AbdD1Hs0 (ORCPT ); Fri, 28 Apr 2017 03:48:26 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:51208 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1424554AbdD1HsN (ORCPT ); Fri, 28 Apr 2017 03:48:13 -0400 Date: Fri, 28 Apr 2017 09:48:03 +0200 From: Greg Kroah-Hartman To: Darren Hart Cc: Arcadiy Ivanov , Mario.Limonciello@dell.com, pali.rohar@gmail.com, andy.shevchenko@gmail.com, mjg59@srcf.ucam.org, andy@infradead.org, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] dell-laptop: Adds support for keyboard backlight timeout AC settings Message-ID: <20170428074803.GA12712@kroah.com> References: <1492976447-10339-1-git-send-email-pali.rohar@gmail.com> <20170425125453.GK30553@pali> <20170425134044.GL30553@pali> <20170426224049.GB3879@fury> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170426224049.GB3879@fury> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 26, 2017 at 03:40:49PM -0700, Darren Hart wrote: > On Tue, Apr 25, 2017 at 05:50:57PM -0400, Arcadiy Ivanov wrote: > > On 2017-04-25 09:49, Mario.Limonciello@dell.com wrote: > > > > -----Original Message----- > > > > From: Pali Rohár [mailto:pali.rohar@gmail.com] > > > > Sent: Tuesday, April 25, 2017 8:41 AM > > > > To: Andy Shevchenko > > > > Cc: Matthew Garrett ; Darren Hart > > > > ; Andy Shevchenko ; Arcadiy Ivanov > > > > ; Limonciello, Mario ; > > > > Platform Driver ; linux- > > > > kernel@vger.kernel.org > > > > Subject: Re: [PATCH] dell-laptop: Adds support for keyboard backlight timeout AC > > > > settings > > > > > > > > On Tuesday 25 April 2017 16:32:36 Andy Shevchenko wrote: > > > > > On Tue, Apr 25, 2017 at 3:54 PM, Pali Rohár wrote: > > > > > > On Tuesday 25 April 2017 15:36:56 Andy Shevchenko wrote: > > > > > > > On Sun, Apr 23, 2017 at 10:40 PM, Pali Rohár wrote: > > > > > > > This patch misses few others that were applied to our testing / for-next. > > > > > > Ah... sorry for that :-( And I was in impression that there were fixes > > > > > > for that code which use mutexes... Now I know why I have not seen them! > > > > > > > > > > > > > I have applied it to testing with corrected conflict (easy to fix), > > > > > > > though check if everything still as supposed to be. > > > > > > Can you send a link to your fix? > > > > > Sure, here it is: > > > > > http://git.infradead.org/linux-platform-drivers- > > > > x86.git/commit/bcf7d8a30e2888f78a19778a16d3dd8c10b4b0ad > > > > > > > > It is OK. > > > > > > > Pali, > > > > > > Considering this is negatively affecting folks on stable kernel releases too > > > when using this newer HW, would you consider to send to @stable too? > > > > > > Thanks, > > > > I second that. Thanks! > > > > In order for this to go back to stable, we will need to include the list of > dependencies per stable-kernel-rules.txt. This can be done after it is merged, > but if you can provide the set of Cc: stable lines needed, we can look at > getting this into testing now so no further action will be required. > > ... > > Upon closer inspection, this does fail the 100 lines including context stable > rule by an additional 55 lines. This is a process issue I've been thinking about > for a while and trying to find the best way to express this problem and what a > viable solution might look like. As it stands, fixes such as these are > effectively limited to current and future kernel versions. I do think there is a > need for vendors to be able to update their drivers upstream to work with current > hardware without requiring a bleeding edge kernel. Perhaps "leaf node drivers" > should have a looser set of stable rules, but that is not currently the way the > upstream stable kernel rules work (at least as far as I understand them). > > +Greg KH who has the ultimate say on this. Greg, have I misrepresented anything > here? Nope, I usually defer to the maintainer of the subsystem to see if the patch should be a valid stable patch or not. So if you think it should be applied, and it's a "bit" larger than normal, that's fine, no objection from me. thanks, greg k-h