Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 7 Dec 2022 23:44:30 +0000
From:   Mark Brown <broonie@kernel.org>
To:     Kris Bahnsen <kris@embeddedts.com>
Cc:     linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
        mark@embeddedts.com
Subject: Re: [PATCH] spi: spi-gpio: Don't set MOSI as an input if not 3WIRE
 mode
Message-ID: <Y5ElXqDduIZhIiAm@sirena.org.uk>
References: <20221207230853.6174-1-kris@embeddedTS.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="56KIyPEz17IU8OgZ"
Content-Disposition: inline
In-Reply-To: <20221207230853.6174-1-kris@embeddedTS.com>
Precedence: bulk


--56KIyPEz17IU8OgZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 07, 2022 at 03:08:53PM -0800, Kris Bahnsen wrote:
> The addition of 3WIRE support would affect MOSI direction even
> when still in standard (4 wire) mode. This can lead to MOSI being
> at an invalid logic level when a device driver sets an SPI
> message with a NULL tx_buf.
>=20
> spi.h states that if tx_buf is NULL then "zeros will be shifted
> out ... " If MOSI is tristated then the data shifted out is subject
> to pull resistors, keepers, or in the absence of those, noise.
>=20
> This issue came to light when using spi-gpio connected to an
> ADS7843 touchscreen controller. MOSI pulled high when clocking
> MISO data in caused the SPI device to interpret this as a command
> which would put the device in an unexpected and non-functional
> state.

A cleaner fix which is probably marginally more performant would be to
make the setting of spi_gpio_set_direction() conditional on SPI_3WIRE -
then we won't call into the function at all when not doing 3 wire,
avoiding the issue entirely.

> As an aside, I wasn't sure how to best put down the Fixes: tags.
> 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support") introduced the
> actual bug, but 5132b3d28371 ("spi: gpio: Support 3WIRE high-impedance tu=
rn-around")
> modified that commit slightly and is what this patch actually applies
> to. Let me know if marking both as fixes is incorrect and I can
> create another patch.

That's fine, it doesn't really matter either way.

--56KIyPEz17IU8OgZ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmORJV0ACgkQJNaLcl1U
h9Be+Qf+MxW4hMRQzDRJd9NFAhwkIiirk2ELo1vuSbRGPl/593kSW6wvsgXW+0zG
EWFNMMbJ0cJqDUbCxSOGAC9MCg0Rg6gDoFeFf0JLWzB1A6a7bRQ/jkzUqyQV/R0H
LqCAaAPvqFseiYJmoIinWc6Qb/5ANNC9/VEt6wFNefFY4gXDcqQBS2ccN29cay62
2I6rfBf3646lDLVbZOpJe00HKwn0mJV7Ga8Amol6lNu8qrVHXlgXOJz6rJggTI+T
FbGtaTtzYwwBCGj9najlZKH0R1UVY+cdqnkBwGLwymyR6534+kDIGqG6D9d/dtx7
J9Ftqf+gqMSYxLpSAweFLrRGJHbtAg==
=zBN5
-----END PGP SIGNATURE-----

--56KIyPEz17IU8OgZ--