On 2022-04-11 13:54, Christoph Hellwig wrote: > Yeah, there's some smelly history here... Originally, of_dma_configure() > pre-set the masks as an attempt to impose any restriction represented by > DT "dma-ranges" - the platform it was implemented in aid of happened to > have a 31-bit DMA range, which may well have coloured some implicit > assumptions. IIRC, when I first implemented the separate bus_dma_mask to > properly solve the general constraint problem, I left the other > mask-setting in place since even though it shouldn't have served any > purpose any more, I figured it wasn't actively harmful, and by that > point it had been around long enough that I was a little wary of opening > a can of worms if anything *had* erroneously started relying on it. > > I'm not against making the change now though - I'm about to get to the > point of turning all the dma_configure stuff inside-out in the course of > my IOMMU rework anyway, so I fully expect to be breaking things and > picking up the pieces. Getting this in first so it's easily bisectable > and leaves me less code to further break seems most sensible :) > > If you're happy to write up the patch, please also do the equivalent for > acpi_arch_dma_setup() too. > > This is all orthogonal to why the original patch in this thread is > wrong, though. If the pcie-designware driver could somehow guarantee > that all endpoint functions present, or able to appear later, can handle > MSI addresses of some width >32, then it could set its DMA mask for the > fake DMA mapping accordingly, but that has nothing at all to do with how > many address bits might happen to be wired up on the external AXI interface. > > Robin. Hi, Thank you for your review. It is clear there is something we don't understand here, I'll return when we have done some more work in this.
