Re: should struct device.dma_mask still be a pointer?

From: FUJITA Tomonori
Date: Wed Jun 30 2010 - 21:37:05 EST

> IMHO it's strange that struct device.dma_mask is a pointer instead of a
> plain u64. The reason this was done back then is described in
> 8ab1bc19e974fdebe76c065fe444979c84ba2f74[1]:
> Attached is a patch which moves dma_mask into struct device and cleans up the
> scsi mid-layer to use it (instead of using struct pci_dev). The advantage to
> doing this is probably most apparent on non-pci bus architectures where
> currently you have to construct a fake pci_dev just so you can get the bounce
> buffers to work correctly.
> The patch tries to perturb the minimum amount of code, so dma_mask in struct
> device is simply a pointer to the one in pci_dev. However, it will make it
> easy for me now to add generic device to MCA without having to go the fake pci
> route.

Yeah, that's a strange design. As the commit log said, it's due to the
historical reason. We invented the pci dma model first then moved to
the generic dma model.

> As I work on such a non-pci bus architecture it's still ugly that this
> is a pointer because I have to allocate extra memory for that.

The popular trick to avoid allocating the extra memory for that is:

device.dma_mask = &device.coherent_dma_mask;

> Is there a reason not to get rid of struct pci_dev.dma_mask and use
> struct instead? (Well apart from the needed
> effort of course.)
> If not, the following would be needed:
> - remove struct pci.dma_mask
> - make struct device.dma_mask an u64 (instead of u64*)
> - substitue var.dma_mask by for all
> struct pci_dev var
> - substitue var.dma_mask by &(var.dma_mask) for all
> struct device var
> and note that there are statically initialized struct device (and maybe
> struct pci_dev?) that need fixing, too. (e.g.
> )

That's exactly the perturbation that the commit log refers to.

We need to modify all the struct device at a time. We could, however,
I don't think that it's worth doing. Little gain.

> Additionally this could be done for struct device.dma_parms.

Yeah, we should have all the dma parameters in dma_parms.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at