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

[Robin Murphy]

On 21/11/2019 3:26 pm, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote:
> > On Thu, Nov 21, 2019 at 10:26:44AM +0100, 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 should
> > > contain the higher accesible DMA address.
> > >
> > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@xxxxxxx>
> >
> > I've tentatively added this patch to the dma-mapping tree based on
> > Robins principal approval of the last version.  That way tomorrows
> > linux-next run should still pick it up.
>
> Actually.  This doesn't apply because the dma-mapping tree doesn't
> have you zone_dma_bits change.  I guess we'll need to wait for the
> next merge window, or maybe post rc1 if this happens to fix the
> powerpc problem that Christian reported.

Hmm, there's no functional dependency though, is there? AFAICS it's 
essentially just a context conflict. Is it worth simply dropping (or 
postponing) the local renaming in __dma_direct_optimal_gfp_mask(), or 
perhaps even cross-merging arm64/for-next/zone-dma into dma/for-next?

Robin.