[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wixqijS-ptVfduV-tAdfKjnLUBicwsXL1xf5PETfktv+w@mail.gmail.com>
Date: Tue, 27 May 2025 17:08:28 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mark Brown <broonie@...nel.org>, Raju Rangoju <Raju.Rangoju@....com>
Cc: linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] SPI updates for v6.16
On Mon, 26 May 2025 at 03:30, Mark Brown <broonie@...nel.org> wrote:
>
> Raju Rangoju (4):
> spi: spi_amd: Add PCI-based driver for AMD HID2 SPI controller
> spi: spi_amd: Remove read{q,b} usage on DMA buffer
> spi: spi_amd: Add HIDDMA basic write support
> spi: spi_amd: Update Kconfig dependencies
So the Kconfig changes made me look at this, and this is just *odd*.
The driver stops using read{q,b}, but why in the name of everything
holy did it then convert to this insanity:
u64 *buf_64 = (u64 *)op->data.buf.in;
[...]
u64 *dma_buf64 = (u64 *)amd_spi->dma_virt_addr;
[...]
/* Copy data from DMA buffer */
while (left_data >= 8) {
*buf_64++ = *dma_buf64++;
left_data -= 8;
}
buf = (u8 *)buf_64;
dma_buf = (u8 *)dma_buf64;
while (left_data--)
*buf++ = *dma_buf++;
which simply seems to be a really stupid and over-complicated way to
write a regular memory copy:
memcpy(op->data.buf.in,
amd_spi->dma_virt_addr,
nbytes);
because I'm not seeing what the point of writing it that way is.
Linus
Powered by blists - more mailing lists