Hi Mani, On 11/6/24 16:35, Manivannan Sadhasivam wrote: > On Mon, Nov 04, 2024 at 05:49:37PM -0600, Bjorn Helgaas wrote: >> On Mon, Nov 04, 2024 at 08:35:21PM +0530, Manivannan Sadhasivam wrote: >>> On Mon, Nov 04, 2024 at 09:54:57AM +0100, Andrea della Porta wrote: >>>> On 22:39 Sat 02 Nov , Manivannan Sadhasivam wrote: >>>>> On Mon, Oct 28, 2024 at 03:07:22PM +0100, Andrea della Porta wrote: >>>>>> When populating "ranges" property for a PCI bridge, of_pci_prop_ranges() >>>>>> incorrectly use the CPU bus address of the resource. Since this is a PCI-PCI >>>>>> bridge, the window should instead be in PCI address space. Call >>>>>> pci_bus_address() on the resource in order to obtain the PCI bus >>>>>> address. >>>>> >>>>> of_pci_prop_ranges() could be called for PCI devices also (not just PCI >>>>> bridges), right? >>>> >>>> Correct. Please note however that while the PCI-PCI bridge has the parent >>>> address in CPU space, an endpoint device has it in PCI space: here we're >>>> focusing on the bridge part. It probably used to work before since in many >>>> cases the CPU and PCI address are the same, but it breaks down when they >>>> differ. >>> >>> When you say 'focusing', you are specifically referring to the >>> bridge part of this API I believe. But I don't see a check for the >>> bridge in your change, which is what concerning me. Am I missing >>> something? >> >> I think we want this change for all devices in the PCI address >> domain, including PCI-PCI bridges and endpoints, don't we? All those >> "ranges" addresses should be in the PCI domain. >> > > Yeah, right. I was slightly confused by the commit message. Maybe including a > sentence about how the change will work fine for endpoint devices would help. > Also, why it went unnoticed till now (ie., both CPU and PCI addresses are same > in many SoCs). Most probably it is unnoticed because until now nobody has enabled /selected CONFIG_PCI_DYNAMIC_OF_NODES ? ~Stan