On Thu, Aug 14, 2025 at 09:39:58PM -0300, Jason Gunthorpe wrote:
On Thu, Aug 14, 2025 at 04:30:18PM -0700, Shyam Saini wrote:
quoted
or were you referring to [2]?
In that case, the PCI child node data needs to be parsed, which is
currently handled individually by each host controller driver.
Yes, this looks like it may be what I was thinking of, the pci@1,0
specifes the BDF effectively
In that case, we'll need to parse the child DTS nodes properly
within of_iommu_get_resv_regions(). I'll include this in v4.
quoted
This might not be a strong argument, but since firmware updates tend
to happen less frequently than OS updates, any addition or modification
to the FDT would require a firmware update. Wouldn't it be more
maintainable to keep this logic in Linux, which is easier to update
and typically updated more often?
The DT is supposed to describe the HW, if the PCI device has an issue
with its dma ranges then it seems reasonable to me the FW will use the
existing standards based way to describe that issue?
If that's the preferred approach, I'll revise the next version accordingly
Presumably this is a fixed issue of the platform. You never did
explain how your system has such werdio behavior, or how something
like iommu=pt can function on it...
Yes, this issue is platform-specific. On this platform, the default MSI IOVA
range overlaps with an address region that is reserved for another purpose,
Other than that we haven't observed any obvious issues for DMA operations
Thanks,
Shyam