[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150205143348.GV21293@sirena.org.uk>
Date: Thu, 5 Feb 2015 14:33:48 +0000
From: Mark Brown <broonie@...nel.org>
To: Esben Haabendal <esbenhaabendal@...il.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Esben Haabendal <esben.haabendal@...il.com>,
stable@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-spi@...r.kernel.org, Stefan Roese <sr@...x.de>
Subject: Re: Backport of spi-fsl-spi bugfix to 3.14.y
On Wed, Feb 04, 2015 at 10:03:33AM +0100, Esben Haabendal wrote:
> I suspect that the regression I have observed is caused by the
> combination of the following two commits:
> commit 059b8ffeee5b427949872bb6ed5db5ae0788054e
> spi: make sure all transfer has proper speed set
> commit e6811d1d7a6a38ee637fe219c3b67dbfe17e8b3f
> spi: make sure all transfer has bits_per_word set
> And the broken behaviour of the spi-fsl-spi driver prior to the (now
> backported) commit 4302a59629f7a0bd70fd1605d2b558597517372a.
> A side effect of the two above mentioned commits is that the spi all
> transfers (in multi message transfers) have their transfer speed_hz and
> bits_per_word set, which is not handled properly by spi-fsl-spi.
OK, so this is the analysis I was looking for before we merged the patch
into stable - we shouldn't normally be merging new features in so we
really need to understand why the new feature is appropriate. "This
seems to make it work" isn't doing that.
The other problem was that I didn't know this was in stable until after
the fact - we should try to avoid that happening in future.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists