PCI: aardvark: Don't touch PCIe registers if no card connected
Subsystems (3)
Pali Rohár
maintainerPATCH 1/1 PCI: aardvark: Don't touch PCIe registers if no card connected
When there is no PCIe card connected and advk_pcie_rd_conf() or advk_pcie_wr_conf() is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:
advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in advk_pcie_valid_device() function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.
--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/pci/controller/pci-aardvark.c +3 -0
@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false; +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false; +return true; }
Signature · 1 line
2.20.1
Quoted 22 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.Signed-off-by Pali Rohár <[email protected]>--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0
drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 648
Quoted 5 lines
drivers/pci/controller/pci-aardvark.c +2
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false; +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false;
I don't think this is the right fix. This makes it racy because the link may go down after we call advk_pcie_valid_device() but before we perform the config read.
I have no objection to removing the "config read/write timed out" message. The "return PCIBIOS_SET_FAILED" in the read case probably should be augmented by setting "*val = 0xffffffff".
Quoted 6 lines
drivers/pci/controller/pci-aardvark.c +0
-0return true; }Signature · 1 line
2.20.1
Pali Rohár
maintainerQuoted 26 lines · On Thursday 28 May 2020 11:26:04 Bjorn Helgaas wrote:
Quoted 25 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.Signed-off-by Pali Rohár <[email protected]>--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;
Quoted 6 lines
drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 648
Quoted 2 lines
drivers/pci/controller/pci-aardvark.c +2
-0+if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false;I don't think this is the right fix. This makes it racy because the link may go down after we call
advk_pcie_valid_device()but before we perform the config read.
Yes, it is racy, but I do not think it cause problems. Trying to read PCIe registers when device is not connected cause just those timeouts, printing error message and increased delay in advk_pcie_wait_pio() due to polling loop. This patch reduce unnecessary access to PCIe registers when advk_pcie_wait_pio() polling just fail.
I think it is a good idea to not call blocking advk_pcie_wait_pio() when it is not needed. We could have faster enumeration of PCIe buses when card is not connected.
Quoted 10 lines
I have no objection to removing the "config read/write timed out" message. The "return
PCIBIOS_SET_FAILED" in the read case probably should be augmented by setting "*val =0xffffffff".Quoted 6 lines
drivers/pci/controller/pci-aardvark.c +0
-0return true; }Signature · 1 line
2.20.1
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 40 lines · Pali Rohár
Quoted 26 lines · On Thursday 28 May 2020 11:26:04 Bjorn Helgaas wrote:
Quoted 25 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.Signed-off-by Pali Rohár <[email protected]>--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;Quoted 6 lines
drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 648
Quoted 2 lines
drivers/pci/controller/pci-aardvark.c +2
-0+if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false;I don't think this is the right fix. This makes it racy because the link may go down after we call
advk_pcie_valid_device()but before we perform the config read.Yes, it is racy, but I do not think it cause problems. Trying to read PCIe registers when device is not connected cause just those timeouts, printing error message and increased delay in
advk_pcie_wait_pio()due to polling loop. This patch reduce unnecessary access to PCIe registers whenadvk_pcie_wait_pio()polling just fail.
Quoted 3 lines
I think it is a good idea to not call blocking
advk_pcie_wait_pio()when it is not needed. We could have faster enumeration of PCIe buses when card is not connected.
Maybe advk_pcie_check_pio_status() and advk_pcie_wait_pio() could be combined so we could get the correct error status as soon as it's available, without waiting for a timeout?
In any event, the "return PCIBIOS_SET_FAILED" needs to be fixed. Most callers of config read do not check for failure, but most of the ones that do, check for "val == ~0". Only a few check for a status of other than PCIBIOS_SUCCESSFUL.
Quoted 10 lines
Quoted 10 lines
I have no objection to removing the "config read/write timed out" message. The "return
PCIBIOS_SET_FAILED" in the read case probably should be augmented by setting "*val =0xffffffff".Quoted 6 lines
drivers/pci/controller/pci-aardvark.c +0
-0return true; }Signature · 1 line
2.20.1
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Pali Rohár
maintainerQuoted 41 lines · On Thursday 28 May 2020 11:49:38 Bjorn Helgaas wrote:
Quoted 40 lines · Pali Rohár
Quoted 26 lines · On Thursday 28 May 2020 11:26:04 Bjorn Helgaas wrote:
Quoted 25 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.Signed-off-by Pali Rohár <[email protected]>--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;Quoted 6 lines
drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 648
Quoted 2 lines
drivers/pci/controller/pci-aardvark.c +2
-0+if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false;I don't think this is the right fix. This makes it racy because the link may go down after we call
advk_pcie_valid_device()but before we perform the config read.Yes, it is racy, but I do not think it cause problems. Trying to read PCIe registers when device is not connected cause just those timeouts, printing error message and increased delay in
advk_pcie_wait_pio()due to polling loop. This patch reduce unnecessary access to PCIe registers whenadvk_pcie_wait_pio()polling just fail.
Quoted 7 lines
Quoted 3 lines
I think it is a good idea to not call blocking
advk_pcie_wait_pio()when it is not needed. We could have faster enumeration of PCIe buses when card is not connected.Maybe
advk_pcie_check_pio_status()andadvk_pcie_wait_pio()could be combined so we could get the correct error status as soon as it's available, without waiting for a timeout?
Any idea how to achieve it?
First call is polling function advk_pcie_wait_pio() and second call is advk_pcie_check_pio_status() which just reads status register and prints error message to dmesg.
So for me it looks like that combining these two functions into one does not change anything. We always need to call polling code prior to checking status register. And therefore need to wait for timeout. Unless something like in this proposed patch is not used (to skip whole register access if it would fail).
Quoted 8 lines
In any event, the "return
PCIBIOS_SET_FAILED" needs to be fixed. Most callers of config read do not check for failure, but most of the ones that do, check for "val == ~0". Only a few check for a status of other thanPCIBIOS_SUCCESSFUL.Quoted 3 lines
Quoted 3 lines
I have no objection to removing the "config read/write timed out" message. The "return
PCIBIOS_SET_FAILED" in the read case probably should be augmented by setting "*val =0xffffffff".
Now I see, "*val = 0xffffffff" should be really set when function advk_pcie_rd_conf() fails.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/pci/controller/pci-aardvark.c +0
-0return true; }Signature · 1 line
2.20.1
Pali Rohár
maintainerHello!
Quoted 56 lines · On Friday 29 May 2020 10:30:13 Pali Rohár wrote:
Quoted 41 lines · On Thursday 28 May 2020 11:49:38 Bjorn Helgaas wrote:
Quoted 40 lines · Pali Rohár
Quoted 26 lines · On Thursday 28 May 2020 11:26:04 Bjorn Helgaas wrote:
Quoted 25 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.Signed-off-by Pali Rohár <[email protected]>--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;Quoted 6 lines
drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 648
Quoted 2 lines
drivers/pci/controller/pci-aardvark.c +2
-0+if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false;I don't think this is the right fix. This makes it racy because the link may go down after we call
advk_pcie_valid_device()but before we perform the config read.Yes, it is racy, but I do not think it cause problems. Trying to read PCIe registers when device is not connected cause just those timeouts, printing error message and increased delay in
advk_pcie_wait_pio()due to polling loop. This patch reduce unnecessary access to PCIe registers whenadvk_pcie_wait_pio()polling just fail.Quoted 7 lines
Quoted 3 lines
I think it is a good idea to not call blocking
advk_pcie_wait_pio()when it is not needed. We could have faster enumeration of PCIe buses when card is not connected.Maybe
advk_pcie_check_pio_status()andadvk_pcie_wait_pio()could be combined so we could get the correct error status as soon as it's available, without waiting for a timeout?Any idea how to achieve it?
First call is polling function
advk_pcie_wait_pio()and second call isadvk_pcie_check_pio_status()which just reads status register and prints error message to dmesg.
Quoted 5 lines
So for me it looks like that combining these two functions into one does not change anything. We always need to call polling code prior to checking status register. And therefore need to wait for timeout. Unless something like in this proposed patch is not used (to skip whole register access if it would fail).
So to answer your question, correct status is possible to retrieve only after waiting for timeout. As status would be available only after timeout expires.
Therefore my proposed patch in this (or some other) form is needed if we want to prevent trying to read from registers and waiting for answer when card is disconnected.
I would really like to see this issue fixed, so booting linux kernel on board without connected PCIe card would not be delayed.
Thomas, Lorenzo, Bjorn: do you have any idea how to fix it differently? Or if not, could be my proposed patch accepted in some form?
Quoted 11 lines
Quoted 8 lines
In any event, the "return
PCIBIOS_SET_FAILED" needs to be fixed. Most callers of config read do not check for failure, but most of the ones that do, check for "val == ~0". Only a few check for a status of other thanPCIBIOS_SUCCESSFUL.Quoted 3 lines
Quoted 3 lines
I have no objection to removing the "config read/write timed out" message. The "return
PCIBIOS_SET_FAILED" in the read case probably should be augmented by setting "*val =0xffffffff".Now I see, "*val =
0xffffffff" should be really set when functionadvk_pcie_rd_conf()fails.
I have already sent separate patch which fixes this issue.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/pci/controller/pci-aardvark.c +0
-0return true; }Signature · 1 line
2.20.1
Quoted 34 lines · Pali Rohár
Quoted 26 lines · On Thursday 28 May 2020 11:26:04 Bjorn Helgaas wrote:
Quoted 25 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.Signed-off-by Pali Rohár <[email protected]>--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;Quoted 6 lines
drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 648
Quoted 2 lines
drivers/pci/controller/pci-aardvark.c +2
-0+if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false;I don't think this is the right fix. This makes it racy because the link may go down after we call
advk_pcie_valid_device()but before we perform the config read.
Quoted 5 lines
Yes, it is racy, but I do not think it cause problems. Trying to read PCIe registers when device is not connected cause just those timeouts, printing error message and increased delay in
advk_pcie_wait_pio()due to polling loop. This patch reduce unnecessary access to PCIe registers whenadvk_pcie_wait_pio()polling just fail.
What happens when the device is removed after advk_pcie_link_up() returns true, but before we actually do the config access?
Pali Rohár
maintainerQuoted 35 lines · On Tuesday 30 June 2020 08:51:27 Bjorn Helgaas wrote:
Quoted 34 lines · Pali Rohár
Quoted 32 lines · On Thursday 28 May 2020 11:26:04 Bjorn Helgaas wrote:
Quoted 22 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.Signed-off-by Pali Rohár <[email protected]>--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 648
Quoted 5 lines
drivers/pci/controller/pci-aardvark.c +2
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false; +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false;I don't think this is the right fix. This makes it racy because the link may go down after we call
advk_pcie_valid_device()but before we perform the config read.
Quoted 8 lines
Quoted 5 lines
Yes, it is racy, but I do not think it cause problems. Trying to read PCIe registers when device is not connected cause just those timeouts, printing error message and increased delay in
advk_pcie_wait_pio()due to polling loop. This patch reduce unnecessary access to PCIe registers whenadvk_pcie_wait_pio()polling just fail.What happens when the device is removed after
advk_pcie_link_up()returns true, but before we actually do the config access?
Do you mean to remove device physically at runtime? I was told that our board would crash or issue reset. Removing device from mini PCIe slot without power off is not supported.
Anyway, currently we are trying to read from device registers even when no device is connected. So when advk_pcie_link_up() returns true and after that device is not connected (somehow board and kernel would be still alive) I guess that it would behave as without applying this patch. So kernel starts reading from register and would wait until timeout expires. As device is not connected there would be no answer, so kernel print error message to dmesg (same as in commit message) and returns error that read failed.
Quoted 42 lines · Pali Rohár
Quoted 41 lines · On Tuesday 30 June 2020 08:51:27 Bjorn Helgaas wrote:
Quoted 39 lines · Pali Rohár
Quoted 26 lines · On Thursday 28 May 2020 11:26:04 Bjorn Helgaas wrote:
Quoted 25 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.Signed-off-by Pali Rohár <[email protected]>--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;Quoted 6 lines
drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 648
Quoted 2 lines
drivers/pci/controller/pci-aardvark.c +2
-0+if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false;I don't think this is the right fix. This makes it racy because the link may go down after we call
advk_pcie_valid_device()but before we perform the config read.Yes, it is racy, but I do not think it cause problems. Trying to read PCIe registers when device is not connected cause just those timeouts, printing error message and increased delay in
advk_pcie_wait_pio()due to polling loop. This patch reduce unnecessary access to PCIe registers whenadvk_pcie_wait_pio()polling just fail.
Quoted 6 lines
Quoted 2 lines
What happens when the device is removed after
advk_pcie_link_up()returns true, but before we actually do the config access?Do you mean to remove device physically at runtime? I was told that our board would crash or issue reset. Removing device from mini PCIe slot without power off is not supported.
Right, I don't think PCIe mini cards support hotplug.
Quoted 8 lines
Anyway, currently we are trying to read from device registers even when no device is connected. So when
advk_pcie_link_up()returns true and after that device is not connected (somehow board and kernel would be still alive) I guess that it would behave as without applying this patch. So kernel starts reading from register and would wait until timeout expires. As device is not connected there would be no answer, so kernel print error message to dmesg (same as in commit message) and returns error that read failed.
OK, so if I understand correctly, checking advk_pcie_link_up() is strictly an optimization. If we guess wrong (e.g., after calling advk_pcie_link_up(), the link went down because the card was removed, DPC triggered, etc), the only bad thing is that we wait for a timeout; it never causes a crash.
If that's the case, I'm fine with this. But please add a comment to that effect.
I think several other drivers check for the link being up because we actually crash if we try to read config space when the link is down. That's what I was trying to avoid here.
Bjorn
Pali Rohár
maintainerQuoted 61 lines · On Tuesday 30 June 2020 09:58:48 Bjorn Helgaas wrote:
Quoted 42 lines · Pali Rohár
Quoted 41 lines · On Tuesday 30 June 2020 08:51:27 Bjorn Helgaas wrote:
Quoted 39 lines · Pali Rohár
Quoted 26 lines · On Thursday 28 May 2020 11:26:04 Bjorn Helgaas wrote:
Quoted 25 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.Signed-off-by Pali Rohár <[email protected]>--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;Quoted 6 lines
drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 648
Quoted 2 lines
drivers/pci/controller/pci-aardvark.c +2
-0+if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false;I don't think this is the right fix. This makes it racy because the link may go down after we call
advk_pcie_valid_device()but before we perform the config read.Yes, it is racy, but I do not think it cause problems. Trying to read PCIe registers when device is not connected cause just those timeouts, printing error message and increased delay in
advk_pcie_wait_pio()due to polling loop. This patch reduce unnecessary access to PCIe registers whenadvk_pcie_wait_pio()polling just fail.Quoted 6 lines
Quoted 2 lines
What happens when the device is removed after
advk_pcie_link_up()returns true, but before we actually do the config access?Do you mean to remove device physically at runtime? I was told that our board would crash or issue reset. Removing device from mini PCIe slot without power off is not supported.
Right, I don't think PCIe mini cards support hotplug.
Quoted 8 lines
Anyway, currently we are trying to read from device registers even when no device is connected. So when
advk_pcie_link_up()returns true and after that device is not connected (somehow board and kernel would be still alive) I guess that it would behave as without applying this patch. So kernel starts reading from register and would wait until timeout expires. As device is not connected there would be no answer, so kernel print error message to dmesg (same as in commit message) and returns error that read failed.
Quoted 5 lines
OK, so if I understand correctly, checking
advk_pcie_link_up()is strictly an optimization. If we guess wrong (e.g., after callingadvk_pcie_link_up(), the link went down because the card was removed, DPC triggered, etc), the only bad thing is that we wait for a timeout; it never causes a crash.
Yes.
Quoted 2 lines
If that's the case, I'm fine with this. But please add a comment to that effect.
Ok, I will send V2 with updated commit message.
Quoted 5 lines
I think several other drivers check for the link being up because we actually crash if we try to read config space when the link is down. That's what I was trying to avoid here.
Bjorn
Pali Rohár
maintainerPATCH v2 1/1 PCI: aardvark: Don't touch PCIe registers if no card connected
In reply to Pali RohárWhen there is no PCIe card connected and advk_pcie_rd_conf() or advk_pcie_wr_conf() is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:
advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in advk_pcie_valid_device() function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.
This is just an optimization to prevent accessing PCIe registers when card is disconnected. Trying to access PCIe registers of disconnected card does not cause any crash, kernel just needs to wait for a timeout. So if card disappear immediately after checking for PCIe link (before accessing PCIe registers), it does not cause any problems.
---
Changes in V2:
* Update commit message, mention that this is optimization
--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/pci/controller/pci-aardvark.c +3 -0
@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false; +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false; +return true; }
Signature · 1 line
2.20.1
Quoted 12 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.
Quoted 5 lines
This is just an optimization to prevent accessing PCIe registers when card is disconnected. Trying to access PCIe registers of disconnected card does not cause any crash, kernel just needs to wait for a timeout. So if card disappear immediately after checking for PCIe link (before accessing PCIe registers), it does not cause any problems.
Thanks, this is good. I'd really like a short comment in the code as well, because this sort of link-up check tends to get copied to new drivers where it shouldn't be used, e.g., something like this:
/*
* If the link goes down after we check for link-up, nothing bad
* happens but the config access times out.
*/
Quoted 26 lines
Signed-off-by Pali Rohár <[email protected]>---
Changes in V2:
* Update commit message, mention that this is optimization--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +3
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false; +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false; +return true; }Signature · 1 line
2.20.1
Pali Rohár
maintainerQuoted 19 lines · On Wednesday 01 July 2020 16:34:42 Bjorn Helgaas wrote:
Quoted 12 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.Quoted 5 lines
This is just an optimization to prevent accessing PCIe registers when card is disconnected. Trying to access PCIe registers of disconnected card does not cause any crash, kernel just needs to wait for a timeout. So if card disappear immediately after checking for PCIe link (before accessing PCIe registers), it does not cause any problems.
Quoted 8 lines
Thanks, this is good. I'd really like a short comment in the code as well, because this sort of link-up check tends to get copied to new drivers where it shouldn't be used, e.g., something like this:
/*
* If the link goes down after we check for link-up, nothing bad
* happens but the config access times out.
*/
Ok, it makes sense! I will send a new patch version.
Quoted 26 lines
Quoted 26 lines
Signed-off-by Pali Rohár <[email protected]>---
Changes in V2:
* Update commit message, mention that this is optimization--- drivers/pci/controller/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+)drivers/pci/controller/pci-aardvark.c +3
-0@@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false; +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false; +return true; }Signature · 1 line
2.20.1
Pali Rohár
maintainerPATCH v3 1/1 PCI: aardvark: Don't touch PCIe registers if no card connected
In reply to Pali RohárWhen there is no PCIe card connected and advk_pcie_rd_conf() or advk_pcie_wr_conf() is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:
advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in advk_pcie_valid_device() function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.
This is just an optimization to prevent accessing PCIe registers when card is disconnected. Trying to access PCIe registers of disconnected card does not cause any crash, kernel just needs to wait for a timeout. So if card disappear immediately after checking for PCIe link (before accessing PCIe registers), it does not cause any problems.
---
Changes in V3:
* Add comment to the code
Changes in V2:
* Update commit message, mention that this is optimization
--- drivers/pci/controller/pci-aardvark.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/pci/controller/pci-aardvark.c +7 -0
@@ -644,6 +644,13 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false; +/* +* If the link goes down after we check for link-up, nothing bad +* happens but the config access times out. +*/ +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false; +return true; }
Signature · 1 line
2.20.1
Quoted 36 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.This is just an optimization to prevent accessing PCIe registers when card is disconnected. Trying to access PCIe registers of disconnected card does not cause any crash, kernel just needs to wait for a timeout. So if card disappear immediately after checking for PCIe link (before accessing PCIe registers), it does not cause any problems.
Signed-off-by Pali Rohár <[email protected]>---
Changes in V3:
* Add comment to the code
Changes in V2:
* Update commit message, mention that this is optimization--- drivers/pci/controller/pci-aardvark.c | 7 +++++++ 1 file changed, 7 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,13 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;
drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 655
Quoted 10 lines
drivers/pci/controller/pci-aardvark.c +7
-0+/* +* If the link goes down after we check for link-up, nothing bad +* happens but the config access times out. +*/ +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false; +return true; }
Question: this basically means that you can only effectively enumerate bus number == root_bus_nr and AFAICS if at probe the link did not come up it will never do, will it ?
Isn't this equivalent to limiting the bus numbers the bridge is capable of handling ?
Reworded: if in advk_pcie_setup_hw() the link does not come up, what's the point of trying to enumerate the bus hierarchy below the root bus ?
Thanks,
Lorenzo
Pali Rohár
maintainerQuoted 52 lines · On Thursday 09 July 2020 12:35:09 Lorenzo Pieralisi wrote:
Quoted 36 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.This is just an optimization to prevent accessing PCIe registers when card is disconnected. Trying to access PCIe registers of disconnected card does not cause any crash, kernel just needs to wait for a timeout. So if card disappear immediately after checking for PCIe link (before accessing PCIe registers), it does not cause any problems.
Signed-off-by Pali Rohár <[email protected]>---
Changes in V3:
* Add comment to the code
Changes in V2:
* Update commit message, mention that this is optimization--- drivers/pci/controller/pci-aardvark.c | 7 +++++++ 1 file changed, 7 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,13 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 655
Quoted 10 lines
drivers/pci/controller/pci-aardvark.c +7
-0+/* +* If the link goes down after we check for link-up, nothing bad +* happens but the config access times out. +*/ +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false; +return true; }Question: this basically means that you can only effectively enumerate bus number ==
root_bus_nrand AFAICS if at probe the link did not come up it will never do, will it ?
Quoted 5 lines
Isn't this equivalent to limiting the bus numbers the bridge is capable of handling ?
Reworded: if in
advk_pcie_setup_hw()the link does not come up, what's the point of trying to enumerate the bus hierarchy below the root bus ?
Hello Lorenzo!
PCIe link can theoretically come up even after boot, but aardvark driver currently does not support link detection at runtime. So it checks and enumerate device only at probe time.
I do not know if hardware has some mechanism to inform kernel that PCIe link come up (or down) and re-enumeration is required. Or the only option is polling via advk_pcie_link_up().
So if device is not visible at the probe time then it would not appear in system and cannot be used. This is current state.
Just to note that our hardware does not support physical hotplug of mPCIe cards. You need to connect card when board is powered off.
So if at the aardvark probe time PCIe link is not up then trying to enumerate devices under (software) root bridge is not needed. But it is needed to register/enumerate software root bridge device and currently both is done by one (recursive) call pci_host_probe().
Quoted 56 lines · Pali Rohár
Quoted 55 lines · On Thursday 09 July 2020 12:35:09 Lorenzo Pieralisi wrote:
Quoted 36 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.This is just an optimization to prevent accessing PCIe registers when card is disconnected. Trying to access PCIe registers of disconnected card does not cause any crash, kernel just needs to wait for a timeout. So if card disappear immediately after checking for PCIe link (before accessing PCIe registers), it does not cause any problems.
Signed-off-by Pali Rohár <[email protected]>---
Changes in V3:
* Add comment to the code
Changes in V2:
* Update commit message, mention that this is optimization--- drivers/pci/controller/pci-aardvark.c | 7 +++++++ 1 file changed, 7 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,13 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 655
Quoted 10 lines
drivers/pci/controller/pci-aardvark.c +7
-0+/* +* If the link goes down after we check for link-up, nothing bad +* happens but the config access times out. +*/ +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false; +return true; }Question: this basically means that you can only effectively enumerate bus number ==
root_bus_nrand AFAICS if at probe the link did not come up it will never do, will it ?Isn't this equivalent to limiting the bus numbers the bridge is capable of handling ?
Quoted 8 lines
Quoted 2 lines
Reworded: if in
advk_pcie_setup_hw()the link does not come up, what's the point of trying to enumerate the bus hierarchy below the root bus ?Hello Lorenzo!
PCIe link can theoretically come up even after boot, but aardvark driver currently does not support link detection at runtime. So it checks and enumerate device only at probe time.
If the link is not up at probe enumerating devices below the root bus is basically useless and that's actually what is causing the delays you are fixing. Is this correct ?
Quoted 7 lines
I do not know if hardware has some mechanism to inform kernel that PCIe link come up (or down) and re-enumeration is required. Or the only option is polling via
advk_pcie_link_up().So if device is not visible at the probe time then it would not appear in system and cannot be used. This is current state.
Quoted 7 lines
Just to note that our hardware does not support physical hotplug of mPCIe cards. You need to connect card when board is powered off.
So if at the aardvark probe time PCIe link is not up then trying to enumerate devices under (software) root bridge is not needed. But it is needed to register/enumerate software root bridge device and currently both is done by one (recursive) call
pci_host_probe().
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.
I would like to get Bjorn's opinion on this, I don't like these "link is up" checks in config accessors (they are racy and honestly it is a run-time check that does not make much sense, either it is always true/false or it is inevitably racy) I was wondering if we can find an alternative solution but I am not sure the one I suggested above is better than this patch.
Lorenzo
Pali Rohár
maintainerQuoted 62 lines · On Thursday 09 July 2020 15:47:01 Lorenzo Pieralisi wrote:
Quoted 61 lines · Pali Rohár
Quoted 52 lines · On Thursday 09 July 2020 12:35:09 Lorenzo Pieralisi wrote:
Quoted 36 lines · Pali Rohár
When there is no PCIe card connected and
advk_pcie_rd_conf()oradvk_pcie_wr_conf()is called for PCI bus which doesn't belong to emulated root bridge, the aardvark driver throws the following error message:advk-pcie d0070000.pcie: config read/write timed out
Obviously accessing PCIe registers of disconnected card is not possible.
Extend check in
advk_pcie_valid_device()function for validating availability of PCIe bus. If PCIe link is down, then the device is marked as Not Found and the driver does not try to access these registers.This is just an optimization to prevent accessing PCIe registers when card is disconnected. Trying to access PCIe registers of disconnected card does not cause any crash, kernel just needs to wait for a timeout. So if card disappear immediately after checking for PCIe link (before accessing PCIe registers), it does not cause any problems.
Signed-off-by Pali Rohár <[email protected]>---
Changes in V3:
* Add comment to the code
Changes in V2:
* Update commit message, mention that this is optimization--- drivers/pci/controller/pci-aardvark.c | 7 +++++++ 1 file changed, 7 insertions(+)drivers/pci/controller/pci-aardvark.c +0
-0@@ -644,6 +644,13 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,if ((bus->number == pcie->root_bus_nr) &&PCI_SLOT (devfn) !=0 )return false;drivers/pci/controller/pci-aardvark.c static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, · line 655
Quoted 10 lines
drivers/pci/controller/pci-aardvark.c +7
-0+/* +* If the link goes down after we check for link-up, nothing bad +* happens but the config access times out. +*/ +if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up (pcie)) +return false; +return true; }Question: this basically means that you can only effectively enumerate bus number ==
root_bus_nrand AFAICS if at probe the link did not come up it will never do, will it ?Quoted 5 lines
Isn't this equivalent to limiting the bus numbers the bridge is capable of handling ?
Reworded: if in
advk_pcie_setup_hw()the link does not come up, what's the point of trying to enumerate the bus hierarchy below the root bus ?Hello Lorenzo!
Quoted 7 lines
Quoted 3 lines
PCIe link can theoretically come up even after boot, but aardvark driver currently does not support link detection at runtime. So it checks and enumerate device only at probe time.
If the link is not up at probe enumerating devices below the root bus is basically useless and that's actually what is causing the delays you are fixing. Is this correct ?
Yes, this is one (but not the only one) delay.
Quoted 10 lines
Quoted 10 lines
I do not know if hardware has some mechanism to inform kernel that PCIe link come up (or down) and re-enumeration is required. Or the only option is polling via
advk_pcie_link_up().So if device is not visible at the probe time then it would not appear in system and cannot be used. This is current state.
Just to note that our hardware does not support physical hotplug of mPCIe cards. You need to connect card when board is powered off.
Quoted 8 lines
Quoted 4 lines
So if at the aardvark probe time PCIe link is not up then trying to enumerate devices under (software) root bridge is not needed. But it is needed to register/enumerate software root bridge device and currently both is done by one (recursive) call
pci_host_probe().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?
Quoted 4 lines
I would like to get Bjorn's opinion on this, I don't like these "link is up" checks in config accessors (they are racy and honestly it is a run-time check that does not make much sense, either it is always true/false or it is inevitably racy)
It is runtime check, but does not have to be always true/false. I have tested more Compex wifi cards and under certain conditions they "disappear" from the bus during usage.
So I think it still make sense to do this "fast" check as it is only optimization.
Quoted 3 lines
I was wondering if we can find an
alternative solution but I am not sure the one I suggested above is better than this patch.
I do not know if it helps in situation when card disappear from bus on runtime...
On Thu, Jul 09, 2020 at 05:09:59PM +0200, Pali Rohár wrote:
[...]
Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 4 lines
I would like to get Bjorn's opinion on this, I don't like these "link is up" checks in config accessors (they are racy and honestly it is a run-time check that does not make much sense, either it is always true/false or it is inevitably racy)
It is runtime check, but does not have to be always true/false. I have tested more Compex wifi cards and under certain conditions they "disappear" from the bus during usage.
I would be very grateful if you could describe what happens in HW when these conditions trigger - I would like to understand if this issue is aardvark specific or it isn't.
Quoted 2 lines
So I think it still make sense to do this "fast" check as it is only optimization.
I will merge this patch but I'd also like to understand the underlying issue better.
Thanks,
Lorenzo
Pali Rohár
maintainerQuoted 3 lines · On Friday 10 July 2020 10:18:00 Lorenzo Pieralisi wrote:
I would be very grateful if you could describe what happens in HW when these conditions trigger - I would like to understand if this issue is aardvark specific or it isn't.
Hello Lorenzo! We are not sure what is the problem and where it happens.
There are more issues which happens randomly or under some specific conditions.
I can reproduce following issue: Connect Compex WLE900VX card, configure aardvark to gen2 mode. And then card is detected only after the first link training. If kernel tries to retrain link again (e.g. via ASPM code) then card is not detected anymore. To detect it again it is needed to reset card via PERST# signal (assert PERST#, wait, de-assert PERST#). PCI warm, hot or function reset does not help. When aardvark is configured in gen1 mode then card is detected fine also after multiple link training.
Above problem does not happen with Compex WLE200VX (ath9k) or Compex WLE1216V5-20 cards.
Sometimes WLE900VX card disappear from the bus during usage. It just stop communicates with ath10k driver and aardvark does not see link.
Another issue which happens for WLE900VX, WLE600VX and WLE1216VS-20 (but not for WLE200VX): Linux kernel can detect these cards only if it issues card reset via PERST# signal and start link training (via standard pcie endpoint register PCI_EXP_LNKCTL/PCI_EXP_LNKCTL_RL) immediately after enable link training in aardvark (via aardvark specific LINK_TRAINING_EN bit). If there is e.g. 100ms delay between enabling link training and setting PCI_EXP_LNKCTL_RL bit then these cards are not detected.
Also issuing reset via PERST# signal is required to detect these cards if either board was rebooted (not started from cold power off state) or if U-Boot touched/initialized PCIe aardvark.
WLE200VX works fine also after doing second or third link training and also works without need to issue reset via PERST# signal.
And WLE900VX card is not detected even after resetting it via PERST# signal if aardvark link training (LINK_TRAINING_EN bit) was enabled prior toggling PERST#. PERST# signal is controlled via GPIO.
When I put WLE900VX card into board with uses mvebu PCI driver (not aardvak) then card is working fine, there is no need to issue card reset via PERST#, no need to explicitly set gen mode and card is also working after more link training.
So basically I have no idea why it happens or where is the problem, either in aardvark or in cards or on both places. As you can see each of tested card has different set problems.
Today I tested card from different vendor but with same Qualcomm chip as is in WLE900VX and I observe same behavior as from Compex WLE900VX. So it looks like that card vendor does not have to matter, important is wifi chip inside.
I read in kernel bugzilla that WLE600VX and WLE900VX cards are buggy and more people have problems with them. But issues described in kernel bugzilla (like card is reporting incorrect PCI device id) I'm not observing.
If you have any idea how to either debug these problems or come up with idea where could be the problem, please let me know.
Quoted 4 lines · Pali Rohár
I can reproduce following issue: Connect Compex WLE900VX card, configure aardvark to gen2 mode. And then card is detected only after the first link training. If kernel tries to retrain link again (e.g. via ASPM code) then card is not detected anymore.
Somebody should go over the ASPM retrain link code and the PCIe spec with a fine-toothed comb. Maybe we're doing something wrong there. Or maybe aardvark has some hardware issue and we need some sort of quirk to work around it.
Quoted 4 lines
Another issue which happens for WLE900VX, WLE600VX and WLE1216VS-20 (but not for WLE200VX): Linux kernel can detect these cards only if it issues card reset via PERST# signal and start link training (via standard pcie endpoint register PCI_EXP_LNKCTL/PCI_EXP_LNKCTL_RL)
I think you mean "downstream port" (not "endpoint") register? PCI_EXP_LNKCTL_RL is only applicable to *downstream ports* (root ports or switch downstream ports) and is reserved for endpoints.
Quoted 4 lines
immediately after
enable link training in aardvark (via aardvark specificLINK_TRAINING_ENbit). If there is e.g. 100ms delay between enabling link training and settingPCI_EXP_LNKCTL_RLbit then these cards are not detected.
This sounds problematic. Hardware should not be dependent on the software being "fast enough". In general we should be able to insert arbitrary delays at any point without breaking anything.
But I have the impression that aardvark requires more software hand-holding that most hardware does. If it imposes timing requirements on the software, that *should* be documented in the aardvark spec.
Quoted 4 lines
I read in kernel bugzilla that WLE600VX and WLE900VX cards are buggy and more people have problems with them. But issues described in kernel bugzilla (like card is reporting incorrect PCI device id) I'm not observing.
Pointer? Is the incorrect device ID 0xffff? That could be a symptom of a PCIe error. If we read a device ID that's something other than 0, 0xffff, or the correct ID, that would be really weird. Even 0 would be really strange.
I suspect these wifi cards are a little special because they probably play unusual games with power for airplane mode and the like.
Bjorn
Pali Rohár
maintainerQuoted 8 lines · On Friday 10 July 2020 11:08:28 Bjorn Helgaas wrote:
Quoted 4 lines · Pali Rohár
I can reproduce following issue: Connect Compex WLE900VX card, configure aardvark to gen2 mode. And then card is detected only after the first link training. If kernel tries to retrain link again (e.g. via ASPM code) then card is not detected anymore.
Somebody should go over the ASPM retrain link code and the PCIe spec with a fine-toothed comb. Maybe we're doing something wrong there.
I think this is not ASPM related as card simply disappear just after flipping PCI_EXP_LNKCTL_RL bit second time without changing ASPM bits.
Quoted 2 lines
Or maybe aardvark has some hardware issue and we need some sort of quirk to work around it.
It is possible that this is aardvark issue. As I said I really do not know.
In aardvark driver there is already merged workaround for this issue:
driver force gen1 aardvark mode for gen1 card.
Quoted 6 lines
Quoted 4 lines
Another issue which happens for WLE900VX, WLE600VX and WLE1216VS-20 (but not for WLE200VX): Linux kernel can detect these cards only if it issues card reset via PERST# signal and start link training (via standard pcie endpoint register PCI_EXP_LNKCTL/PCI_EXP_LNKCTL_RL)
I think you mean "downstream port" (not "endpoint") register?
Yes.
Quoted 11 lines
PCI_EXP_LNKCTL_RLis only applicable to *downstream ports* (root ports or switch downstream ports) and is reserved for endpoints.Quoted 4 lines
immediately after
enable link training in aardvark (via aardvark specificLINK_TRAINING_ENbit). If there is e.g. 100ms delay between enabling link training and settingPCI_EXP_LNKCTL_RLbit then these cards are not detected.This sounds problematic. Hardware should not be dependent on the software being "fast enough". In general we should be able to insert arbitrary delays at any point without breaking anything.
Yes, it is problematic. For example following commit broke those cards:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4c7d053d7f77cd5c1a1ba7c7ce085ddba13d1d7
And this commit fixed it (just msleep was moved to different stage):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6964494582f56a3882c2c53b0edbfe99eb32b2e1
But we somehow need to deal with it until we find root cause.
Basically additional sleep in aardvark init phase can break WLE900VX cards, but not WLE200VX.
And because WLE900VX works fine with pci-mvebu and WLE200VX works fine with pci-aardvark we cannot deduce from it if problem for combination of WLE900VX and aardvark is in WLE900VX or in aardvark.
Quoted 4 lines
But I have the impression that aardvark requires more software hand-holding that most hardware does. If it imposes timing requirements on the software, that *should* be documented in the aardvark spec.
There is absolutely nothing regarding to timings in documentation which I saw. In documentation are just instructions/steps how to init PCI subsystem and it is basically advk_pcie_setup_hw() function.
Quoted 6 lines
Quoted 4 lines
I read in kernel bugzilla that WLE600VX and WLE900VX cards are buggy and more people have problems with them. But issues described in kernel bugzilla (like card is reporting incorrect PCI device id) I'm not observing.
Pointer?
Hm... I cannot find right now pointer to bugzilla, but I have pointer to ath9k-devel mailing list with that incorrect device id:
https://www.mail-archive.com/[email protected]/msg07529.html
Quoted 1 line
Is the incorrect device ID
0xffff?
No, incorrect device ID in that case is 0xabcd and vendor ID is correct (Qualcomm).
Quoted 4 lines
That could be a symptom
of a PCIe error. If we read a device ID that's something other than 0,0xffff, or the correct ID, that would be really weird. Even 0 would be really strange.
It is strange and also reason why discussion on that list is long.
As I said, I'm not seeing that problem with wrong device ID.
But I know people who are observing same problem on different boards (which do not use aardvark) as described in above mailing list thread with Compex ath10k cards.
Quoted 2 lines
I suspect these wifi cards are a little special because they probably play unusual games with power for airplane mode and the like.
This is another/different problem and is already "documented" in kernel
bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=84821#c52
Quoted 7 lines · Pali Rohár
Quoted 6 lines · On Friday 10 July 2020 11:08:28 Bjorn Helgaas wrote:
Quoted 4 lines · Pali Rohár
I can reproduce following issue: Connect Compex WLE900VX card, configure aardvark to gen2 mode. And then card is detected only after the first link training. If kernel tries to retrain link again (e.g. via ASPM code) then card is not detected anymore.
Quoted 5 lines
Quoted 2 lines
Somebody should go over the ASPM retrain link code and the PCIe spec with a fine-toothed comb. Maybe we're doing something wrong there.
I think this is not ASPM related as card simply disappear just after flipping
PCI_EXP_LNKCTL_RLbit second time without changing ASPM bits.
Right. The retrain code in aspm.c doesn't really have anything in particular to do with ASPM and it should probably be moved elsewhere. So I think the problem may be related to retrain and the delays after it in general, not to ASPM.
Quoted 12 lines
There is absolutely nothing regarding to timings in documentation which I saw. In documentation are just instructions/steps how to init PCI subsystem and it is basically
advk_pcie_setup_hw()function.Quoted 4 lines
Quoted 4 lines
I read in kernel bugzilla that WLE600VX and WLE900VX cards are buggy and more people have problems with them. But issues described in kernel bugzilla (like card is reporting incorrect PCI device id) I'm not observing.
Hm... I cannot find right now pointer to bugzilla, but I have pointer to ath9k-devel mailing list with that incorrect device id:
Quoted 6 lines
https://www.mail-archive.com/[email protected]/msg07529.html
Quoted 1 line
Is the incorrect device ID
0xffff?No, incorrect device ID in that case is
0xabcdand vendor ID is correct (Qualcomm).
From a quick look at that thread, it sounds like the device isn't quite ready yet. In that case, it's supposed to respond with Config Request Retry Status, and Linux is supposed to wait longer and retry. But I don't think Linux does that quite correctly, so it could be either a hardware problem or Linux being broken. But I guess that's not the current problem so I don't want to go down that rathole right now.
Pali Rohár
maintainerQuoted 9 lines · On Friday 10 July 2020 10:18:00 Lorenzo Pieralisi wrote:
Quoted 5 lines · Pali Rohár
Quoted 3 lines
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_BUSso 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]
pci_bus 0000:00: root bus resource [mem 0xe8000000-0xe8ffffff]
pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0xe9000000-0xe900ffff]) pci_bus 0000:00: scanning bus
pci 0000:00:00.0: [1b4b:0100] type 01 class 0x060400
pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
pci_bus 0000:00: fixups for bus
pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 0
pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:01: scanning bus
advk-pcie d0070000.pcie: advk_pcie_valid_device
Quoted 24 lines · Pali Rohár
Quoted 9 lines · On Friday 10 July 2020 10:18:00 Lorenzo Pieralisi wrote:
Quoted 5 lines · Pali Rohár
Quoted 3 lines
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_BUSso 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.cscans child buses unconditionally.
pci-aardvark.ccallspci_host_probe()which calls functionspci_scan_root_bus_bridge()which callspci_scan_child_bus()which callspci_scan_child_bus_extend()which callspci_scan_bridge_extend()(bridge needs to be reconfigured) which then try to probe child bus viapci_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.
Quoted 5 lines
dmesg output contains:
advk-pcie d0070000.pcie: link never came up advk-pcie d0070000.pcie: PCI host bridge to bus 0000:00
pci_bus0000: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 will go over the thread again but I suspect I can merge the patch even though I still believe there is work to be done to understand the issue we are facing.
Lorenzo
Quoted 11 lines
pci_bus0000:00: root bus resource [mem 0xe8000000-0xe8ffffff]
pci_bus0000:00: root bus resource [io 0x0000-0xffff] (bus address [0xe9000000-0xe900ffff])pci_bus0000:00: scanning bus
pci 0000:00:00.0: [1b4b:0100] type 01 class0x060400
pci 0000:00:00.0: reg0x38: [mem 0x00000000-0x000007ff pref]
pci_bus0000:00: fixups for bus
pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 0
pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus0000:01: scanning bus
advk-pcie d0070000.pcie:advk_pcie_valid_device
Pali Rohár
maintainerQuoted 3 lines · On Monday 13 July 2020 12:23:25 Lorenzo Pieralisi wrote:
I will go over the thread again but I suspect I can merge the patch even though I still believe there is work to be done to understand the issue we are facing.
Just to note that pci-mvebu.c also checks if pcie link is up before trying to access the real PCIe interface registers, similarly as in my patch.
Quoted 8 lines · Pali Rohár
Quoted 3 lines · On Monday 13 July 2020 12:23:25 Lorenzo Pieralisi wrote:
I will go over the thread again but I suspect I can merge the patch even though I still believe there is work to be done to understand the issue we are facing.
Just to note that
pci-mvebu.calso checks if pcie link is up before trying to access the real PCIe interface registers, similarly as in my patch.
I understand - that does not change my opinion though, the link check is just a workaround, it'd be best if we pinpoint the real issue which is likely to a HW one.
Lorenzo
Pali Rohár
maintainerQuoted 6 lines · On Monday 13 July 2020 17:41:40 Lorenzo Pieralisi wrote:
Quoted 5 lines · Pali Rohár
Quoted 3 lines · On Monday 13 July 2020 12:23:25 Lorenzo Pieralisi wrote:
I will go over the thread again but I suspect I can merge the patch even though I still believe there is work to be done to understand the issue we are facing.
Quoted 7 lines
Quoted 3 lines
Just to note that
pci-mvebu.calso checks if pcie link is up before trying to access the real PCIe interface registers, similarly as in my patch.I understand - that does not change my opinion though, the link check is just a workaround, it'd be best if we pinpoint the real issue which is likely to a HW one.
Lorenzo, if you have an idea how to debug this issue or if you would like to see some test results, let me know. I can do some tests, but I currently really do not know more then what I wrote in previous emails.
In my opinion, problem is in HW which Marvell has not documented nor proved that it exists. Other option is that problem is in Compex card which can be triggered only by Marvell aardvark HW.
Pali Rohár
maintainerQuoted 27 lines · On Monday 13 July 2020 12:23:25 Lorenzo Pieralisi wrote:
Quoted 26 lines · Pali Rohár
Quoted 9 lines · On Friday 10 July 2020 10:18:00 Lorenzo Pieralisi wrote:
Quoted 5 lines · Pali Rohár
Quoted 3 lines
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_BUSso 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.cscans child buses unconditionally.
pci-aardvark.ccallspci_host_probe()which calls functionspci_scan_root_bus_bridge()which callspci_scan_child_bus()which callspci_scan_child_bus_extend()which callspci_scan_bridge_extend()(bridge needs to be reconfigured) which then try to probe child bus viapci_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:
Quoted 8 lines
Quoted 3 lines
advk-pcie d0070000.pcie: link never came up advk-pcie d0070000.pcie: PCI host bridge to bus 0000:00
pci_bus0000:00: root bus resource [bus 00-ff]This resource can be limited to the root bus number only before calling
pci_host_probe()(ie seepci_parse_request_of_pci_ranges()and code inpci_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.
And trying to read config register would cause those timeouts in aardvark.
Quoted 37 lines · Pali Rohár
Quoted 27 lines · On Monday 13 July 2020 12:23:25 Lorenzo Pieralisi wrote:
Quoted 26 lines · Pali Rohár
Quoted 9 lines · On Friday 10 July 2020 10:18:00 Lorenzo Pieralisi wrote:
Quoted 5 lines · Pali Rohár
Quoted 3 lines
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_BUSso 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.cscans child buses unconditionally.
pci-aardvark.ccallspci_host_probe()which calls functionspci_scan_root_bus_bridge()which callspci_scan_child_bus()which callspci_scan_child_bus_extend()which callspci_scan_bridge_extend()(bridge needs to be reconfigured) which then try to probe child bus viapci_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:
Quoted 8 lines
Quoted 3 lines
advk-pcie d0070000.pcie: link never came up advk-pcie d0070000.pcie: PCI host bridge to bus 0000:00
pci_bus0000:00: root bus resource [bus 00-ff]This resource can be limited to the root bus number only before calling
pci_host_probe()(ie seepci_parse_request_of_pci_ranges()and code inpci_scan_bridge_extend()that programs primary/secondary/subordinate busses) but I think that only papers over the issue, it does not fix it.
Quoted 8 lines
I looked at the code in
pci/probe.cagain and I do not think it is possible to avoid scanning devices.pci_scan_child_bus_extend()is unconditionally callingpci_scan_slot()for devfn=0 as the first thing. And this function unconditionally callspci_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 2 lines
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 but I would be happy to keep this discussion going, somehow.
If the LPC20 VFIO/IOMMU/PCI microconference is approved it can be a good venue for this to happen.
Lorenzo
Pali Rohár
maintainerQuoted 58 lines · On Wednesday 15 July 2020 17:21:08 Lorenzo Pieralisi wrote:
Quoted 37 lines · Pali Rohár
Quoted 27 lines · On Monday 13 July 2020 12:23:25 Lorenzo Pieralisi wrote:
Quoted 26 lines · Pali Rohár
Quoted 9 lines · On Friday 10 July 2020 10:18:00 Lorenzo Pieralisi wrote:
Quoted 5 lines · Pali Rohár
Quoted 3 lines
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_BUSso 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.cscans child buses unconditionally.
pci-aardvark.ccallspci_host_probe()which calls functionspci_scan_root_bus_bridge()which callspci_scan_child_bus()which callspci_scan_child_bus_extend()which callspci_scan_bridge_extend()(bridge needs to be reconfigured) which then try to probe child bus viapci_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:
Quoted 8 lines
Quoted 3 lines
advk-pcie d0070000.pcie: link never came up advk-pcie d0070000.pcie: PCI host bridge to bus 0000:00
pci_bus0000:00: root bus resource [bus 00-ff]This resource can be limited to the root bus number only before calling
pci_host_probe()(ie seepci_parse_request_of_pci_ranges()and code inpci_scan_bridge_extend()that programs primary/secondary/subordinate busses) but I think that only papers over the issue, it does not fix it.Quoted 8 lines
I looked at the code in
pci/probe.cagain and I do not think it is possible to avoid scanning devices.pci_scan_child_bus_extend()is unconditionally callingpci_scan_slot()for devfn=0 as the first thing. And this function unconditionally callspci_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 2 lines
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_BUSresource.
Quoted 4 lines
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.
Quoted 1 line
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.
Quoted 4 lines
If the LPC20 VFIO/IOMMU/PCI microconference is approved it can be a good venue for this to happen.
Lorenzo
Quoted 59 lines · Pali Rohár
Quoted 58 lines · On Wednesday 15 July 2020 17:21:08 Lorenzo Pieralisi wrote:
Quoted 37 lines · Pali Rohár
Quoted 27 lines · On Monday 13 July 2020 12:23:25 Lorenzo Pieralisi wrote:
Quoted 26 lines · Pali Rohár
Quoted 9 lines · On Friday 10 July 2020 10:18:00 Lorenzo Pieralisi wrote:
Quoted 5 lines · Pali Rohár
Quoted 3 lines
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_BUSso 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.cscans child buses unconditionally.
pci-aardvark.ccallspci_host_probe()which calls functionspci_scan_root_bus_bridge()which callspci_scan_child_bus()which callspci_scan_child_bus_extend()which callspci_scan_bridge_extend()(bridge needs to be reconfigured) which then try to probe child bus viapci_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:
Quoted 8 lines
Quoted 3 lines
advk-pcie d0070000.pcie: link never came up advk-pcie d0070000.pcie: PCI host bridge to bus 0000:00
pci_bus0000:00: root bus resource [bus 00-ff]This resource can be limited to the root bus number only before calling
pci_host_probe()(ie seepci_parse_request_of_pci_ranges()and code inpci_scan_bridge_extend()that programs primary/secondary/subordinate busses) but I think that only papers over the issue, it does not fix it.Quoted 8 lines
I looked at the code in
pci/probe.cagain and I do not think it is possible to avoid scanning devices.pci_scan_child_bus_extend()is unconditionally callingpci_scan_slot()for devfn=0 as the first thing. And this function unconditionally callspci_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 2 lines
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_BUSresource.
Quoted 7 lines
Quoted 4 lines
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.
Apologies - I did not push it out, I have pushed it out on pci/aardvark now.
Quoted 4 lines
Quoted 1 line
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.
Sounds good, I will let you know, thanks.
Lorenzo
Quoted 4 lines
Quoted 4 lines
If the LPC20 VFIO/IOMMU/PCI microconference is approved it can be a good venue for this to happen.
Lorenzo