Re: [PATCH/RFC] SPI: add DMAUNSAFE analog to David Brownell's core

From: Vitaly Wool
Date: Tue Dec 13 2005 - 16:47:19 EST


David Brownell wrote:

Neither is it "remove" in the normal sense either. The hot
path never had an allocation before ... but it could easily
have one now, because that sort of bounce-buffer semantic is
what a DMA_UNSAFE flag demands from the lower levels. (That's
a key part part of the proposed change that's not included in
this patch... making the chage look much smaller.)


Makes no sense to me, sorry. What 'not included' changes are you talking about?


How much of the reason you're arguing for this is because you
have that WLAN stack that does some static allocation for I/O
buffers? Changing that to use dynamic allocation -- the more
usual style -- should be easy. But instead, you want all code
in the SPI stack to need to worry about two different kinds of
I/O memory: the normal stuff, and the DMA-unsafe kind. Not


Err, this change also allows to get rid of ugly stuff in write_then_read.
It also allows to keep track of memory allocation in SPI controller driver withough hacky tricks.
And... it's not *all* the code; if it doesn't provide such means, it's also fine.

just this WLAN code which for some reason started out using
a nonportable scheme for allocating I/O buffers.


I'm afraid I just can't understand what you mean by 'portable' here.

It'd take a lot more persuasion to make me think that's a good
idea. That's the kind of subtle confusion that really promotes
hard-to-find bugs in drivers, and lots of developer confusion.


What hard-to-find bugs, I wonder?
And... I'm afraid that your core is unacceptable for us w/o the changes proposed.

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