linux-kernel - Re: [PATCH] atmel_spi: Pass correct DMA address to controller

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]

Date:	Wed, 16 May 2007 23:14:18 +0200
From:	"Håvard Skinnemoen" <hskinnemoen@...il.com>
To:	"David Brownell" <david-b@...bell.net>
Cc:	"Haavard Skinnemoen" <hskinnemoen@...el.com>, wux@...dicorp.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] atmel_spi: Pass correct DMA address to controller

On 5/16/07, David Brownell <david-b@...bell.net> wrote:
> On Wednesday 16 May 2007, Haavard Skinnemoen wrote:
> > -     tx_dma = xfer->tx_dma;
> > -     rx_dma = xfer->rx_dma;
> > +     tx_dma = xfer->tx_dma + xfer->len - len;
> > +     rx_dma = xfer->rx_dma + xfer->len - len;
> >
> >       /* use scratch buffer only when rx or tx data is unspecified */
> > -     if (rx_dma == INVALID_DMA_ADDRESS) {
> > +     if (!xfer->rx_buf) {
>
> This test ...
>
> >               rx_dma = as->buffer_dma;
> >               if (len > BUFFER_SIZE)
> >                       len = BUFFER_SIZE;
> >       }
> > -     if (tx_dma == INVALID_DMA_ADDRESS) {
> > +     if (!xfer->tx_buf) {
>
> ... and this one must not assume that the relevant buffer
> is always NULL when the tx_dma has been set up.  Keep the
> test against INVALID_DMA_ADDRESS, but fetch the address
> from the spi_transfer.

No it doesn't -- it's the other way around. It assumes that if
xfer->tx_buf is NULL, the user didn't provide a buffer so it has to
use the scratch buffer instead. The driver never does PIO transfers,
so if tx_buf is valid, tx_dma ought to be valid  too. This is taken
care of elsewhere by calling dma_map_single() if the user provided a
virtual pointer but not a dma address.

Checking for an invalid cpu-virtual pointer really should be
equivalent to checking for an invalid DMA address at this point.

I could perhaps add else blocks to those two ifs and add the offset to
the respective dma addresses there instead if it makes it clearer. The
tests are supposed to be the same as before, but I had to change them
one way or another because of the added offset (which would make an
invalid dma address non-invalid.)

> It's legit to set up cpu-virtual (for PIO) and dma addresses
> for each buffer, since the upper layer driver has no way to
> know if the underlying controller driver is DMA-capable, or
> for that matter PIO-capable.

Yes, but are there any drivers that will provide a valid dma address
and a NULL cpu-virtual pointer? That would indeed break my
assumptions, but it would also break any PIO-only drivers, wouldn't
it?

Haavard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/