Messages in this thread | | | Date | Mon, 5 Oct 2020 15:08:52 +0200 | From | Christoph Hellwig <> | Subject | Re: [RFC 0/3] iommu: Reserved regions for IOVAs beyond dma_mask and iommu aperture |
| |
On Mon, Oct 05, 2020 at 11:44:10AM +0100, Lorenzo Pieralisi wrote: > > I see that there are both OF and ACPI hooks in pci_dma_configure() and > > both modify dev->dma_mask, which is what pci-sysfs is exposing here, > > but I'm not convinced this even does what it's intended to do. The > > driver core calls this via the bus->dma_configure callback before > > probing a driver, but then what happens when the driver calls > > pci_set_dma_mask()? This is just a wrapper for dma_set_mask() and I > > don't see anywhere that would take into account the existing > > dev->dma_mask. It seems for example that pci_dma_configure() could > > produce a 42 bit mask as we have here, then the driver could override > > that with anything that the dma_ops.dma_supported() callback finds > > acceptable, and I don't see any instances where the current > > dev->dma_mask is considered. Am I overlooking something? > > I don't think so but Christoph and Robin can provide more input on > this - it is a long story. > > ACPI and OF bindings set a default dma_mask (and dev->bus_dma_limit), > this does not prevent a driver from overriding the dev->dma_mask but DMA > mapping code still takes into account the dev->bus_dma_limit. > > This may help: > > git log -p 03bfdc31176c
This is at best a historic artefact. Bus drivers have no business messing with the DMA mask, dev->bus_dma_limit is the way to communicate addressing limits on the bus (or another interconnect closer to the CPU).
| |