[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210114135906.GF4854@sirena.org.uk>
Date: Thu, 14 Jan 2021 13:59:06 +0000
From: Mark Brown <broonie@...nel.org>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Sven Van Asbroeck <thesven73@...il.com>,
Linus Walleij <linus.walleij@...aro.org>,
linux-spi <linux-spi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linuxppc-dev@...abs.org" <linuxppc-dev@...abs.org>
Subject: Re: SPI not working on 5.10 and 5.11, bisected to 766c6b63aa04
("spi: fix client driver breakages when using GPIO descriptors")
On Thu, Jan 14, 2021 at 02:42:26PM +0100, Christophe Leroy wrote:
> Le 14/01/2021 à 14:22, Mark Brown a écrit :
> > For GPIO chipselects you should really fix the driver to just hand the
> > GPIO off to the core rather than trying to implement this itself, that
> > will avoid driver specific differences like this.
> IIUC, it is not trivial as it requires implementing transfer_one() instead
> of the existing transfer_one_message() in the driver. Am I right ?
Yes, that's a good idea in general though. It should normally be pretty
simple since the conversion is mostly just deleting code doing things
which will be handled by the core.
> What's the difference/benefit of transfer_one() compared to the existing transfer_one_message() ?
It factors out all the handling of chip selects, including per-transfer
chip select inversion and so on, and also factors out all the handling
of in-message delays. If nothing else it reduces the amount of
duplicated code that might require maintainance can have issues with
misaligned expectations from the core or client drivers.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists