David Brownell wrote:
That's not "core" in the normal "everyone must use this" sense.
Even the folk that do use synchronous transfers aren't always
going to use that particular codepath.
Lemme explain once more why what you have is a lot worse than what I
suggest.
Take for instance spi_w8r8 function used in lotsa places in the drivers
you and Stephen have posted.
This function has a) *implicit memcpy* inherited from
spi_write_then_read b) *implicit priority inversion* inherited from the
same place.
On the other hand, any smart enough SPI controller driver wouldn't ever
want to send and receive one byte via DMA, especially chaining messages
because the overhead will be great; memcpy's also adding overhead. It's
gonna use PIO instead.
So this is a serious reason to let controller driver decide things
related to memory allocation. It doesn't concern only static-allocated
buffers but also, say, stack-allocated (used in your core in many
places). And controller driver needs something to track whether it has
allocated a buffer for transfer for DMA safety or not. Don't you want a
linked list of allocated buffers in the controller driver?! And the
flag I'm adding within the patch does that with minimal intrusion to
your core.
Hope that helps understand my reasons.
Vitaly
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
