From: Vitaly W. <vw...@ru...> - 2005-12-13 21:48:46
|
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 |