By the way Vitaly ... I'm still not getting responses directly from you.No, definitely I'm not. I'm just responding with "Reply All" button in my Thunderbird, if you wanna know the details.
Are you pruning me off CC lists, or is there something between us that's
filtering out posts? It's certainly hard to respond to comments of yours
when I can only find them by going through some list archive I wouldn't
Again, a single working driver cannot disapprove anything.No, but it's a good indication :).So for example one way you know that (c) is well met is that it's the sameLemme point you out that if somehting is "working" on a limited number of platforms within the limited number of use cases, that's not necessarily a correct implementation.
approach used in USB (both host and peripheral/gadget sides); that's been
working well for quite a few years now. (Despite comments from Dmitry
and Vitaly to the contrary.)
And I'm not sure what a "limited number of platforms" etc is supposed
to suggest. In terms of platforms supporting USB on Linux, there are
surely more of them than there are for PCI ... since every PCI platform
can support USB, and many non-PCI platforms do also. A better word
for that DMA support would seem to be "extensive", not "limited".
In fact, the support for non-PCI platforms was one of the things that
led to the last DMA-related reworks for USB. The PCI calls wouldn't
work (of course), but USB needs things like DMA-coherent buffers (for
transfer and queue head descriptors, used by most controllers) as well
as bus-neutral DMA operations. And it even works for things like
scatterlist merging through IOMMU mappings ... that wide portability
is **very much** a good indication that (c) is a non-issue with the
framework I've assembled.
Vitaly, you're really going to have to come up with some facts if you
keep claiming the SPI framework I've posted doesn't support DMA.
(I'm not going to let you pull a SCO on us here.) For that matter,
you might want to consider the fact that Stephen's pxa2xx_spi
driver disproves your arguments (it includes DMA support).
Oh no, you've got me wrong. I was tryng to say that an upper level driver which copies the data from the userspace should be copying it to GFP_DMA buffer, otherwise it won't work or will force the controller driver to allocate/copy.
Yeah within this requirement it's correct. But that requirement may really make the SPI controller driver a lot more complex ifMake that "requirements"; FWIW they're the same ones that apply to all- (A) has some assumptions on buffers that are passed down to spi
other kernel driver frameworks I've seen: that buffers be DMA-safe.
It would not be helpful (IMO) to define different rules; that's also
called the "Principle of Least Astonishment". :)
- it has to send something received from the userland
Controller drivers don't deal with userland addresses. That's the
responsibility of the layers on top ... e.g. the filesystem or driver
code that accepts them. Most just copy to/from userspace, but some
pay the costs to support direct I/O.
I'm afraid that you were not reading my response attentively. Credentials are stored in a staic-allocated buffer in the upper level driver. Then they are passed down to the SPI core which will fail to send the buffer containing the credentials if it's not copied to DMAable memory somewhere in between.
- it needs to timely send some credentials (what is the case for the WLAN driver, for instance).
Again, not the responsibility of the lowest level driver. A WLAN driver
layered on top could, of course. That's the way such things are done in
other driver stacks.
Are you seriously suggesting that an SPI controller driver should have any
clue whatever about credentials?? Which of the dozens of schemes should
become that "special", then ... and why??