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

On Tuesday 13 December 2005 8:53 am, Vitaly Wool wrote:
>
> this patch removes nasty buffer allocation in spi core for sync message transfers.

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.

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.)


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
just this WLAN code which for some reason started out using
a nonportable scheme for allocating I/O buffers.

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.
And all that to support a new less-portable I/O buffer model...

It's way better to just insist that all I/O buffers (in all
generic APIs) be DMA-safe. AFAICT that's a pretty standard
rule everywhere in Linux.

- Dave

-
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/

Relevant Pages

  • Re: Status of buffered write path (deadlock fixes)
    ... We can't zero these guys and do the commit_write, ... buffers because we'd write junk over good data. ... If they've done allocation, yes. ... You're telling the file system to stop ...
    (Linux-Kernel)
  • Status of buffered write path (deadlock fixes)
    ... I'd like to try to state where we are WRT the buffered write patches, ... !uptodate page remains!uptodate, an uptodate page can handle the ... But WRT block allocation in the case of errors, ... is enough to just zero out any new buffers. ...
    (Linux-Kernel)
  • Re: Status of buffered write path (deadlock fixes)
    ... because we might be talking about buffers that haven't been newly ... We can't zero these guys and do the commit_write, ... If they've done allocation, yes. ... You're telling the file system to stop ...
    (Linux-Kernel)
  • [RFC][PATCH] EXT3: problem with page fault inside a transaction
    ... GFP_FS allocation, re-entering into ext3 code possibly with a different ... * Here we make sure that the set of buffers written at once either ... int ret = 0, ret2; ...
    (Linux-Kernel)