linux-kernel - Re: [PATCH v2 2/6] spi: microchip-core: Refactor FIFO read and write handlers

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: <20251127-pliable-magnetism-c59c560e49ad@spud>
Date: Thu, 27 Nov 2025 18:05:04 +0000
From: Conor Dooley <conor@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Prajna Rajendra Kumar <prajna.rajendrakumar@...rochip.com>,
	Mark Brown <broonie@...nel.org>,
	david laight <david.laight@...box.com>, linux-spi@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Conor Dooley - M52691 <Conor.Dooley@...rochip.com>
Subject: Re: [PATCH v2 2/6] spi: microchip-core: Refactor FIFO read and write
 handlers

On Thu, Nov 27, 2025 at 06:49:27PM +0200, Andy Shevchenko wrote:
> On Thu, Nov 27, 2025 at 04:08:25PM +0000, Prajna Rajendra Kumar wrote:
> > On 26/11/2025 12:13, Andy Shevchenko wrote:
> > > On Wed, Nov 26, 2025 at 12:05:22PM +0000, Mark Brown wrote:
> > > > On Wed, Nov 26, 2025 at 09:21:45AM +0000, david laight wrote:
> 
> ...
> 
> > > > > I'm not sure I don't prefer the version with one writeb() call.
> > > > > How about:
> > > > >              writeb(spi->tx_buf ? *spi->tx_buf++ : 0xaa,
> > > > >                      spi->regs + MCHP_CORESPI_REG_TXDATA);
> > > > Please don't abuse the ternery operator like this, just write normal
> > > > conditional statements.
> > > FWIW, that's what my patch does already :-)
> > 
> > Thanks for the series. However, this particular patch appears to
> > introduce a regression. The SPI controller reads an incorrect
> > Device ID from the peripheral.
> 
> Hmm... This is interesting. The only thing I see is missed dummy byte read in
> case of TX only transfers. Is this what you have?

Seems very likely, the hardware is pretty simple, so it has no concept
of whether bytes it receives are useful or any ability to operate on
transfers and discard data from the FIFOs when a new one starts. That's
why the unconditional read is there to make sure the rx FIFO is kept in
sync.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)