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). Also there should be a fixes tag (also CC stable) since this is a potential bug fix. - Mani -- மணிவண்ணன் சதாசிவம்
