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  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]
Date:   Thu, 21 May 2020 14:47:36 +0300
From:   Serge Semin <>
To:     Feng Tang <>
CC:     Serge Semin <>,
        Mark Brown <>,
        Grant Likely <>,
        Vinod Koul <>, Alan Cox <>,
        Linus Walleij <>,
        Georgy Vlasov <>,
        Ramil Zaripov <>,
        Alexey Malahov <>,
        Thomas Bogendoerfer <>,
        Paul Burton <>,
        Ralf Baechle <>,
        Arnd Bergmann <>,
        Andy Shevchenko <>,
        Rob Herring <>, <>,
        Jarkko Nikula <>,
        Thomas Gleixner <>,
        Wan Ahmad Zainie <>,
        Linus Walleij <>,
        Clement Leger <>, <>,
Subject: Re: [PATCH v3 01/16] spi: dw: Add Tx/Rx finish wait methods to the

Hello Feng,

On Thu, May 21, 2020 at 11:09:24AM +0800, Feng Tang wrote:
> Hi Serge,
> On Thu, May 21, 2020 at 04:21:51AM +0300, Serge Semin wrote:


> >  /*
> >   * dws->dma_chan_busy is set before the dma transfer starts, callback for rx
> >   * channel will clear a corresponding bit.
> > @@ -200,6 +267,8 @@ static void dw_spi_dma_rx_done(void *arg)
> >  {
> >  	struct dw_spi *dws = arg;
> >  
> > +	dw_spi_dma_wait_rx_done(dws);
> I can understand the problem about TX, but I don't see how RX
> will get hurt, can you elaborate more? thanks
> - Feng

Your question is correct. You are right with your hypothesis. Ideally upon the
dw_spi_dma_rx_done() execution Rx FIFO must be already empty. That's why the
commit log signifies the error being mostly related with Tx FIFO. But
practically there are many reasons why Rx FIFO might be left with data:
DMA engine failures, incorrect DMA configuration (if DW SPI or DW DMA driver
messed something up), controller hanging up, and so on. It's better to catch
an error at this stage while propagating it up to the SPI device drivers.
Especially seeing the wait-check implementation doesn't gives us much of the
execution overhead in normal conditions. So by calling dw_spi_dma_wait_rx_done()
we make sure that all the data has been fetched and we may freely get the
buffers back to the client driver.


Powered by blists - more mailing lists