linux-kernel - Re: [PATCH 1/2] spi: spi-cadence: Avoid read of RX FIFO before its ready

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 17 May 2023 10:46:29 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     "Goud, Srinivas" <srinivas.goud@....com>
CC:     "broonie@...nel.org" <broonie@...nel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "patches@...nsource.cirrus.com" <patches@...nsource.cirrus.com>
Subject: Re: [PATCH 1/2] spi: spi-cadence: Avoid read of RX FIFO before its
 ready

On Wed, May 17, 2023 at 05:24:10AM +0000, Goud, Srinivas wrote:
> >On Mon, May 15, 2023 at 12:04:38PM +0000, Goud, Srinivas wrote:
> >> Cadence SPI configured in Slave mode,  when threshold is half of FIFO
> >> depth cdns_spi_read_rx_fifo() function continuously in read mode, due to
> >this we see incorrect data received on the Master side as Slave is failed to
> >update the TX FIFO on time.
> >
> >Apologies I am having a little trouble following this are you saying this part of
> >the patch cases issues for you running in slave mode?
> Yes, we see issue with this patch when we run in Slave mode.
> 
> When any master is in continuous read mode (anything > FIFO depth), 
> with updated logic cdns_spi_read_rx_fifo() function in cdns_spi_irq
> continuously in read loop to read complete half FIFO data.
> due to this Slave failed to write the TX FIFO on time and result in
> incorrect data in Master receive. 
> Whereas in my previous patch, data read and write happening byte wise,
> by which we are making sure data availability in TXFIFO on time.

That is a very tight system if reading 64 sequential memory locations
is the timing difference between success and failure, Linux is
not a real-time OS.

But I don't really mind moving back to a byte-wise operation. Although
we need to avoid the issues introduced by the first attempt at that. I
will have a look at doing a patch to put the byte-wise back in.

Thanks,
Charles