If it's going to be a pointer, it might as well be normal kmalloc data,
avoiding obfuscation of the memory model used by USB device drivers.
(They don't have to worry about DMA addresses, which IMO is a feature.)
Seems like there are two basic options for how to handle all this.
(a) Expose the dma/cache interaction to device drivers, so
they can manage (and prevent) bad ones like the cacheline
sharing scenarios.
(b) Require drivers to provide I/O buffers that are slab/page/...
pointers from some API that prevents such problems.
I think (a) is more or less a variant of the existing alignment
requirements that get embedded in ABIs, but which still show up
in code that's very close to the hardware. Many device driver
folk are familiar with them, or performance tuners, but not so
many folk doing USB device drivers would be. (They are thankfully
far from host controller hardware and its quirks!)
Personally I'd avoid (b) since I like to allocate memory all at
once in most cases ... lots fewer error cases to cope with (or,
more typically _not_ cope with :).
One question is whether to support only one of them, or allow both.
In either case the DMA-mapping.txt will need to touch on the issue.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/