of: address: Work around missing device_type property in pcie nodes
Subsystems (3)
PATCH v2 1/1 of: address: Work around missing device_type property in pcie nodes
Recent changes to the DT PCI bus parsing made it mandatory for device tree nodes describing a PCI controller to have the 'device_type = "pci"' property for the node to be matched.
Although this follows the letter of the specification, it breaks existing device-trees that have been working fine for years. Rockchip rk3399-based systems are a prime example of such collateral damage, and have stopped discovering their PCI bus.
In order to paper over it, let's add a workaround to the code matching the device type, and accept as PCI any node that is named "pcie",
A warning will hopefully nudge the user into updating their DT to a fixed version if they can, but the incentive is obviously pretty small.
--- drivers/of/address.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
drivers/of/address.c +15 -1
@@ -128,15 +128,29 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr)* PCI bus specific translator */ +static bool of_node_is_pcie (struct device_node *np) +{ +bool is_pcie =of_node_name_eq (np,"pcie" ); + +if (is_pcie) +pr_warn_once ("%pOF: Missing device_type\n" , np); + +return is_pcie; +} +static int of_bus_pci_match (struct device_node *np) {/* * "pciex" is PCI Express * "vci" is for the /chaos bridge on 1st-gen PCI powermacs * "ht" is hypertransport +* +* If none of the device_type match, and that the node name is +* "pcie", accept the device as PCI (with a warning). */ return of_node_is_type (np,"pci" ) ||of_node_is_type (np,"pciex" ) || -of_node_is_type (np,"vci" ) ||of_node_is_type (np,"ht" ); +of_node_is_type (np,"vci" ) ||of_node_is_type (np,"ht" ) || +of_node_is_pcie (np); } static void of_bus_pci_count_cells(struct device_node *np,
Signature · 1 line
2.27.0
Quoted 18 lines · Marc Zyngier
Recent changes to the DT PCI bus parsing made it mandatory for device tree nodes describing a PCI controller to have the '
device_type= "pci"' property for the node to be matched.Although this follows the letter of the specification, it breaks existing device-trees that have been working fine for years. Rockchip rk3399-based systems are a prime example of such collateral damage, and have stopped discovering their PCI bus.
In order to paper over it, let's add a workaround to the code matching the device type, and accept as PCI any node that is named "pcie",
A warning will hopefully nudge the user into updating their DT to a fixed version if they can, but the incentive is obviously pretty small.
Quoted 7 lines
Fixes 2f96593ecc37 ("of_address: Add bus type match for pci ranges parser")Suggested-by Rob Herring <[email protected]>Signed-off-by Marc Zyngier <[email protected]>--- drivers/of/address.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
Applied, thanks!
Hi Marc,
I'm afraid this commit breaks booting my rk3399 device.
I bisected the problem to this patch merged as [1]. I'm testing on a Scarlet device and I'm using the unmodified upstream rk3399-gru-scarlet-inx.dtb for my tests.
The problem I'm experience is a black screen after the bootloader and the device is none responsive over the network. I have no serial console to this device so I'm afraid I can't tell you if there is anything useful on to aid debugging there.
If I try to test one commit earlier [2] the system boots as expected and everything works as it did for me in v5.8 and earlier. I have worked little with this device and have no clue about what is really on the PCI buss. But running from [2] I have this info about PCI if it's helpful, please ask if somethings missing.
# dmesg | grep -i pci [ 0.003943] PCI/MSI: /interrupt-controller@fee00000/interrupt-controller@fee20000 domain created [ 0.922022] PCI: CLS 0 bytes, default 64 [ 0.941517] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: [ 0.941577] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbefffff -> 0x00fa000000 [ 0.941962] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep [ 0.941981] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup [ 0.942018] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0) [ 0.942255] rockchip-pcie f8000000.pcie: no vpcie12v regulator found [ 4.196248] ehci-pci: EHCI PCI platform driver [ 4.214639] ohci-pci: OHCI PCI platform driver
# ls /sys/bus/{pci,pci_express}/devices
/sys/bus/pci/devices:/sys/bus/pci_express/devices:
# ls /sys/bus/{pci,pci_express}/drivers
/sys/bus/pci/drivers:
cavium_rng_pf cavium_rng_vf dwc3-haps ehci-pci exar_serial ohci-pci pcieport serial xhci_hcd/sys/bus/pci_express/drivers:pcie_pme
# ls /sys/bus/platform/drivers/rockchip-{pcie,pcie-phy}
/sys/bus/platform/drivers/rockchip-pcie:
bind uevent unbind/sys/bus/platform/drivers/rockchip-pcie-phy:
bind ff770000.syscon:pcie-phy uevent unbind
1. d1ac0002dd297069 ("of: address: Work around missing device_type property in pcie nodes")
2. 43647929175e2cd3 ("dt: writing-schema: Miscellaneous grammar fixes")
Quoted 68 lines · Marc Zyngier
Recent changes to the DT PCI bus parsing made it mandatory for device tree nodes describing a PCI controller to have the '
device_type= "pci"' property for the node to be matched.Although this follows the letter of the specification, it breaks existing device-trees that have been working fine for years. Rockchip rk3399-based systems are a prime example of such collateral damage, and have stopped discovering their PCI bus.
In order to paper over it, let's add a workaround to the code matching the device type, and accept as PCI any node that is named "pcie",
A warning will hopefully nudge the user into updating their DT to a fixed version if they can, but the incentive is obviously pretty small.
Fixes 2f96593ecc37 ("of_address: Add bus type match for pci ranges parser")Suggested-by Rob Herring <[email protected]>Signed-off-by Marc Zyngier <[email protected]>--- drivers/of/address.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)drivers/of/address.c +15
-1@@ -128,15 +128,29 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr)* PCI bus specific translator */ +static bool of_node_is_pcie (struct device_node *np) +{ +bool is_pcie =of_node_name_eq (np,"pcie" ); + +if (is_pcie) +pr_warn_once ("%pOF: Missing device_type\n" , np); + +return is_pcie; +} +static int of_bus_pci_match (struct device_node *np) {/* * "pciex" is PCI Express * "vci" is for the /chaos bridge on 1st-gen PCI powermacs * "ht" is hypertransport +* +* If none of the device_type match, and that the node name is +* "pcie", accept the device as PCI (with a warning). */ return of_node_is_type (np,"pci" ) ||of_node_is_type (np,"pciex" ) || -of_node_is_type (np,"vci" ) ||of_node_is_type (np,"ht" ); +of_node_is_type (np,"vci" ) ||of_node_is_type (np,"ht" ) || +of_node_is_pcie (np); } static void of_bus_pci_count_cells(struct device_node *np,Signature · 7 lines
2.27.0 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 2 lines
Regards, Niklas Söderlund
Hi Niklas,
[+ Samuel]
Quoted 13 lines · Niklas Söderlund
Hi Marc,
I'm afraid this commit breaks booting my rk3399 device.
I bisected the problem to this patch merged as [1]. I'm testing on a Scarlet device and I'm using the unmodified upstream rk3399-gru-scarlet-inx.dtb for my tests.
The problem I'm experience is a black screen after the bootloader and the device is none responsive over the network. I have no serial console to this device so I'm afraid I can't tell you if there is anything useful on to aid debugging there.
Quoted 5 lines
If I try to test one commit earlier [2] the system boots as expected and everything works as it did for me in v5.8 and earlier. I have worked little with this device and have no clue about what is really on the PCI buss. But running from [2] I have this info about PCI if it's helpful, please ask if somethings missing.
Please see the thread at [1]. The problem was reported a few weeks back by Samuel, and I was expecting Rob and Lorenzo to push a fix for this.
Rob, Lorenzo, any update on this?
M.
[1] https://lore.kernel.org/linux-devicetree/20200829164920.7d28e01a@DUFFMAN/
Signature · 1 line
Jazz is not dead. It just smells funny...
Hi Marc,
Quoted 18 lines · Marc Zyngier
Hi Niklas,
[+ Samuel]
Quoted 13 lines · Niklas Söderlund
Hi Marc,
I'm afraid this commit breaks booting my rk3399 device.
I bisected the problem to this patch merged as [1]. I'm testing on a Scarlet device and I'm using the unmodified upstream rk3399-gru-scarlet-inx.dtb for my tests.
The problem I'm experience is a black screen after the bootloader and the device is none responsive over the network. I have no serial console to this device so I'm afraid I can't tell you if there is anything useful on to aid debugging there.
Quoted 8 lines
Quoted 5 lines
If I try to test one commit earlier [2] the system boots as expected and everything works as it did for me in v5.8 and earlier. I have worked little with this device and have no clue about what is really on the PCI buss. But running from [2] I have this info about PCI if it's helpful, please ask if somethings missing.
Please see the thread at [1]. The problem was reported a few weeks back by Samuel, and I was expecting Rob and Lorenzo to push a fix for this.
Thanks for providing a solution.
Quoted 9 lines
Rob, Lorenzo, any update on this?
M.[1]
https://lore.kernel.org/linux-devicetree/20200829164920.7d28e01a@DUFFMAN/Signature · 1 line
Jazz is not dead. It just smells funny...
Signature · 2 lines
Regards, Niklas Söderlund
Rob Herring
maintainerQuoted 28 lines · Niklas Söderlund
Hi Marc,
Quoted 24 lines · Marc Zyngier
Hi Niklas,
[+ Samuel]
Quoted 18 lines · Niklas Söderlund
Hi Marc,
I'm afraid this commit breaks booting my rk3399 device.
I bisected the problem to this patch merged as [1]. I'm testing on a Scarlet device and I'm using the unmodified upstream rk3399-gru-scarlet-inx.dtb for my tests.
The problem I'm experience is a black screen after the bootloader and the device is none responsive over the network. I have no serial console to this device so I'm afraid I can't tell you if there is anything useful on to aid debugging there.
If I try to test one commit earlier [2] the system boots as expected and everything works as it did for me in v5.8 and earlier. I have worked little with this device and have no clue about what is really on the PCI buss. But running from [2] I have this info about PCI if it's helpful, please ask if somethings missing.
Quoted 7 lines
Quoted 2 lines
Please see the thread at [1]. The problem was reported a few weeks back by Samuel, and I was expecting Rob and Lorenzo to push a fix for this.
Thanks for providing a solution.
Quoted 2 lines
Rob, Lorenzo, any update on this?
The fix is in Bjorn's tree[1].
Bjorn, going to send this to Linus before v5.9 is out?
Rob
[1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/log/?h=for-linus
Quoted 33 lines · Rob Herring
Quoted 31 lines · Niklas Söderlund
Hi Marc,
Quoted 26 lines · Marc Zyngier
Hi Niklas,
[+ Samuel]
Quoted 13 lines · Niklas Söderlund
Hi Marc,
I'm afraid this commit breaks booting my rk3399 device.
I bisected the problem to this patch merged as [1]. I'm testing on a Scarlet device and I'm using the unmodified upstream rk3399-gru-scarlet-inx.dtb for my tests.
The problem I'm experience is a black screen after the bootloader and the device is none responsive over the network. I have no serial console to this device so I'm afraid I can't tell you if there is anything useful on to aid debugging there.
Quoted 5 lines
If I try to test one commit earlier [2] the system boots as expected and everything works as it did for me in v5.8 and earlier. I have worked little with this device and have no clue about what is really on the PCI buss. But running from [2] I have this info about PCI if it's helpful, please ask if somethings missing.
Please see the thread at [1]. The problem was reported a few weeks back by Samuel, and I was expecting Rob and Lorenzo to push a fix for this.
Quoted 8 lines
Quoted 4 lines
Thanks for providing a solution.
Quoted 2 lines
Rob, Lorenzo, any update on this?
The fix is in Bjorn's tree[1].
Bjorn, going to send this to Linus before v5.9 is out?
Definitely, thanks for the reminder. I'm assuming the fix in question
is https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=for-linus&id=e338eecf3fe79054e8a31b8c39a1234b5acfdabe
Hi Bjorn,
Quoted 37 lines · Bjorn Helgaas
Quoted 36 lines · Rob Herring
Quoted 34 lines · Niklas Söderlund
Hi Marc,
Quoted 18 lines · Marc Zyngier
Hi Niklas,
[+ Samuel]
Quoted 13 lines · Niklas Söderlund
Hi Marc,
I'm afraid this commit breaks booting my rk3399 device.
I bisected the problem to this patch merged as [1]. I'm testing on a Scarlet device and I'm using the unmodified upstream rk3399-gru-scarlet-inx.dtb for my tests.
The problem I'm experience is a black screen after the bootloader and the device is none responsive over the network. I have no serial console to this device so I'm afraid I can't tell you if there is anything useful on to aid debugging there.
Quoted 8 lines
Quoted 5 lines
If I try to test one commit earlier [2] the system boots as expected and everything works as it did for me in v5.8 and earlier. I have worked little with this device and have no clue about what is really on the PCI buss. But running from [2] I have this info about PCI if it's helpful, please ask if somethings missing.
Please see the thread at [1]. The problem was reported a few weeks back by Samuel, and I was expecting Rob and Lorenzo to push a fix for this.
Thanks for providing a solution.
Quoted 1 line
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Rob, Lorenzo, any update on this?
The fix is in Bjorn's tree[1].
Bjorn, going to send this to Linus before v5.9 is out?
Definitely, thanks for the reminder. I'm assuming the fix in question
is https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=for-linus&id=e338eecf3fe79054e8a31b8c39a1234b5acfdabe
That patch solves my boot problem.
Cherry-picked and tested directly on-top of v5.9-rc7 (which fails to boot without the patch in question).
Quoted 2 lines
Signature · 2 lines
Regards, Niklas Söderlund