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: > > 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. > > 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
