On Wednesday 15 July 2020 17:21:08 Lorenzo Pieralisi wrote:

On Wed, Jul 15, 2020 at 02:17:26PM +0200, Pali Rohár wrote:

quoted

On Monday 13 July 2020 12:23:25 Lorenzo Pieralisi wrote:

quoted

On Mon, Jul 13, 2020 at 10:27:47AM +0200, Pali Rohár wrote:

quoted

On Friday 10 July 2020 10:18:00 Lorenzo Pieralisi wrote:

quoted

On Thu, Jul 09, 2020 at 05:09:59PM +0200, Pali Rohár wrote:

quoted

quoted

I understand that but the bridge bus resource can be trimmed to just
contain the root bus because that's the only one where there is a
chance you can enumerate a device.

It is possible to register only root bridge without endpoint?

It is possible to register the root bridge with a trimmed IORESOURCE_BUS
so that you don't enumerate anything other than the root port.

Hello Lorenzo! I really do not know how to achieve it. From code it
looks like that pci/probe.c scans child buses unconditionally.

pci-aardvark.c calls pci_host_probe() which calls functions
pci_scan_root_bus_bridge() which calls pci_scan_child_bus() which calls
pci_scan_child_bus_extend() which calls pci_scan_bridge_extend() (bridge
needs to be reconfigured) which then try to probe child bus via
pci_scan_child_bus_extend() because bridge is not card bus.

In function pci_scan_bridge_extend() I do not see a way how to skip
probing for child buses which would avoid enumerating aardvark root
bridge when PCIe device is not connected.

dmesg output contains:

  advk-pcie d0070000.pcie: link never came up
  advk-pcie d0070000.pcie: PCI host bridge to bus 0000:00
  pci_bus 0000:00: root bus resource [bus 00-ff]

This resource can be limited to the root bus number only before calling
pci_host_probe() (ie see pci_parse_request_of_pci_ranges() and code in
pci_scan_bridge_extend() that programs primary/secondary/subordinate
busses) but I think that only papers over the issue, it does not fix it.

I looked at the code in pci/probe.c again and I do not think it is
possible to avoid scanning devices. pci_scan_child_bus_extend() is
unconditionally calling pci_scan_slot() for devfn=0 as the first thing.
And this function unconditionally calls pci_scan_device() which is
directly trying to read vendor id from config register.

So for me it looks like that kernel expects that can read vendor id and
device id from config register for device which is not connected.

Not if it is connected to a bus that the root port does not decode,
that's what I am saying.

quoted

And trying to read config register would cause those timeouts in
aardvark.

The root port (which effectively works as PCI bridge from this
standpoint) does not issue config cycles for busses that aren't within
its decoded bus range, which in turn is determined by the firmware
IORESOURCE_BUS resource.

This issue is caused by devices that are connected downstream to
the root port.

Anyway - patch merged

Could you send me a link to git commit? I have looked into
lpieralisi/pci.git repository, but I do not see it here.

but I would be happy to keep this discussion going, somehow.

Ok, no problem. As I said if anybody has any idea or would like to see
some tests from me, I can do it and provide results.

If the LPC20 VFIO/IOMMU/PCI microconference is approved it can be a
good venue for this to happen.

Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel