Re: [PATCH] dma-mapping: treat dev->bus_dma_mask as a DMA limit

[Robin Murphy]

On 2019-11-13 8:41 pm, Florian Fainelli wrote:
> On 11/13/19 12:34 PM, Robin Murphy wrote:
> > On 13/11/2019 4:13 pm, Nicolas Saenz Julienne wrote:
> > > Using a mask to represent bus DMA constraints has a set of limitations.
> > > The biggest one being it can only hold a power of two (minus one). The
> > > DMA mapping code is already aware of this and treats dev->bus_dma_mask
> > > as a limit. This quirk is already used by some architectures although
> > > still rare.
> > >
> > > With the introduction of the Raspberry Pi 4 we've found a new contender
> > > for the use of bus DMA limits, as its PCIe bus can only address the
> > > lower 3GB of memory (of a total of 4GB). This is impossible to represent
> > > with a mask. To make things worse the device-tree code rounds non power
> > > of two bus DMA limits to the next power of two, which is unacceptable in
> > > this case.
> > >
> > > In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
> > > over the tree and treat it as such. Note that dev->bus_dma_limit is
> > > meant to contain the higher accesible DMA address.
> >
> > Neat, you win a "why didn't I do it that way in the first place?" :)
> >
> > Looking at it without all the history of previous attempts, this looks
> > entirely reasonable, and definitely a step in the right direction.
>
> And while you are changing those, would it make sense to not only rename
> the structure member but introduce a getter and setter in order to ease
> future work where this would no longer be a scalar?

I doubt it - once we get as a far as supporting multiple DMA ranges, 
there will be a whole load of infrastructure churn anyway if only to 
replace dma_pfn_offset, and I'm not sure a simple get/set paradigm would 
even be viable, so it's probably better to save that until clearly 
necessary.

Robin.