Re: [PATCH 2/9] Move dma_ops from archdata into struct device

On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote:

On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:

quoted

Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
transfer data between memory and PCIe adapter. Because of performance
reasons it is important that the CPU cache is not flushed when such
drivers transfer data. Make this possible by allowing these drivers to
override the dma_map_ops pointer. Additionally, introduce the function
set_dma_ops() that will be used by a later patch in this series.
=20
Signed-off-by: Bart Van Assche <redacted>
Cc: [ ... ]

=20
That's a crazy cc: list, you should break this up into smaller pieces,
otherwise it's going to bounce...

That's a subset of what scripts/get_maintainer.pl came up with. Suggestions
for a more appropriate cc-list for a patch like this that touches all
architectures would be welcome.

quoted

diff --git a/include/linux/device.h b/include/linux/device.h
index 491b4c0ca633..c7cb225d36b0 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h

@@ -885,6 +885,8 @@ struct dev_links_info {

=A0 * a higher-level representation of the device.
=A0 */
=A0struct device {
+	const struct dma_map_ops *dma_ops; /* See also get_dma_ops() */
+
=A0	struct device		*parent;
=A0
=A0	struct device_private	*p;

=20
Why not put this new pointer down with the other dma fields in this
structure?=A0=A0Any specific reason it needs to be first?

Are there CPU architectures for which access to the first member of a
structure can be encoded and/or executed more efficiently than access to
other members of a structure? If not, I'm fine with moving the new pointer
further down.

Bart.=