>OK, so that's really just another variant of the existing problem we have with >certain PCI root complexes with restrictive inbound windows. >The appropriate way to handle that is to reserve the unusable areas of the >IOVA space up-front. > Since the support for the ACPI equivalent of "dma-ranges" has just landed, > this is now pretty much top of my to-do-list for > the upcoming cycle (there's various things still to fix in the DT code, but > that's essentially part of the same job).
Reserving upfront would work. If you already have in it in to-do-list, we will wait for your patches. >In the case of a 64-bit-capable IP block with only 34 bits of address wired up >externally, if that 34-bit interconnect is described by "dma-ranges" > then the device will already be created with an appropriate 34-bit DMA mask. > The fact that the driver can stomp on that with a 64-bit mask later >is entirely down to the implementations of >dma_set_mask() etc. (I've had a patch to restrict masks for arm64 for a while, >but I worry that it carries quite a high risk of breakage in default cases). Exactly, It is the stomping issue. dma-ranges code updates the mask earlier than sdhci code. Sdhci code is overwriting the dma mask afterwards. -KR
