From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: [PATCH] RS485: fix inconsistencies in the meaning of some variables Date: Tue, 8 Nov 2011 06:24:32 -0800 Message-ID: <20111108142432.GA11293@kroah.com> References: <4E492CFF.7040905@pwrnet.de> <20110822211832.GA8023@kroah.com> <4EB3A009.10502@evidence.eu.com> <4EB8F6B9.6010008@atmel.com> <4EB90902.4030200@evidence.eu.com> <20111108134804.07095c5d@lxorguk.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20111108134804.07095c5d@lxorguk.ukuu.org.uk> Sender: linux-kernel-owner@vger.kernel.org To: Alan Cox Cc: Claudio Scordino , Nicolas Ferre , alan@linux.intel.com, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jesper Nilsson , Mikael Starvik , Darron Black List-Id: linux-serial@vger.kernel.org On Tue, Nov 08, 2011 at 01:48:04PM +0000, Alan Cox wrote: > > The modifications that I have proposed are very minimal, and most > > user-space code should continue to work without any difference. Any Cris > > user-space code will continue to work, because we didn't change the > > behavior of the driver. For Atmel user-space code, instead, the behavior > > of the driver changes only if flags are not set and delay variables > > contain a value different than 0 (which, hopefully, is not a very common > > situation). That's the reason why I preferred to not change the names of > > the variables, even if better names would be desirable. > > We have inconsistency between implementations. We don't have a change in > implementation. There isn't any way to resolve that except by fixing the > deviating implementation and doing it promptly. > > With my tty hat on I'm quite happy with this patch. The sooner it is > upstream the better. Ok, I'll push to get it to Linus for the next rc release. greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 From: greg@kroah.com (Greg KH) Date: Tue, 8 Nov 2011 06:24:32 -0800 Subject: [PATCH] RS485: fix inconsistencies in the meaning of some variables In-Reply-To: <20111108134804.07095c5d@lxorguk.ukuu.org.uk> References: <4E492CFF.7040905@pwrnet.de> <20110822211832.GA8023@kroah.com> <4EB3A009.10502@evidence.eu.com> <4EB8F6B9.6010008@atmel.com> <4EB90902.4030200@evidence.eu.com> <20111108134804.07095c5d@lxorguk.ukuu.org.uk> Message-ID: <20111108142432.GA11293@kroah.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Nov 08, 2011 at 01:48:04PM +0000, Alan Cox wrote: > > The modifications that I have proposed are very minimal, and most > > user-space code should continue to work without any difference. Any Cris > > user-space code will continue to work, because we didn't change the > > behavior of the driver. For Atmel user-space code, instead, the behavior > > of the driver changes only if flags are not set and delay variables > > contain a value different than 0 (which, hopefully, is not a very common > > situation). That's the reason why I preferred to not change the names of > > the variables, even if better names would be desirable. > > We have inconsistency between implementations. We don't have a change in > implementation. There isn't any way to resolve that except by fixing the > deviating implementation and doing it promptly. > > With my tty hat on I'm quite happy with this patch. The sooner it is > upstream the better. Ok, I'll push to get it to Linus for the next rc release. greg k-h