linux-kernel - Re: [PATCH] spi: spi-gpio: Don't set MOSI as an input if not 3WIRE mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1670461096.7839.1.camel@embeddedTS.com>
Date:   Wed, 07 Dec 2022 16:58:16 -0800
From:   Kris Bahnsen <kris@...eddedTS.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
        mark@...eddedts.com
Subject: Re: [PATCH] spi: spi-gpio: Don't set MOSI as an input if not 3WIRE
 mode

On Thu, 2022-12-08 at 00:42 +0000, Mark Brown wrote:
> On Wed, Dec 07, 2022 at 04:36:41PM -0800, Kris Bahnsen wrote:
> > On Wed, 2022-12-07 at 23:44 +0000, Mark Brown wrote:
> > > 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.
> > That makes sense to me. I was operating under the assumption that 3WIRE
> > mode could be switched in to at a later time via ioctl(), but with the
> > death of spidev that is presumably no longer a concern.
> 
> Ugh, right, spidev.  Really even with spidev devices should probably
> have the mode configured beforehand (I'm not sure pinmux will do the
> right thing on most platforms...) but now I check it's part of the ABI
> so we can't get rid of it and therefore your current patch probably is
> what we need.  No need to reroll, sorry for the noise :/

No need to apologize, thanks for the followup. I'm not terribly
familiar with SPI internals in Linux so I'm not sure how deep that
rabbit hole goes. Let me know if you change your mind, I will happily
whip something else up.

> 
> I'm not sure why you think spidev is dying, it does still exist and
> devices use it?

"The death of spidev" _as a generic interface_.

A number of our products provide a generic pin header with SPI
available for customer use. We've been told when we RFC'ed dts files
to support our platforms that spidev isn't acceptable on these
headers and the downstream developer must add their own as needed.
Which, many of our customers use devices that don't have drivers
anyway, so we still have to assist them in getting spidev functional
in one way or another. It's just a sore spot for us.