From: Marc Zyngier <maz@kernel.org> Date: 2020-08-19 09:43:09
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 <robh+dt@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/of/address.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
From: Rob Herring <robh@kernel.org> Date: 2020-08-19 22:30:37
On Wed, 19 Aug 2020 10:42:55 +0100, Marc Zyngier wrote:
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 <robh+dt@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/of/address.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
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")
On 2020-08-19 10:42:55 +0100, Marc Zyngier wrote:
quoted hunk
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 <robh+dt@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/of/address.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
From: Marc Zyngier <maz@kernel.org> Date: 2020-09-30 17:23:30
Hi Niklas,
[+ Samuel]
On 2020-09-30 17:27, Niklas Söderlund wrote:
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.
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/
--
Jazz is not dead. It just smells funny...
Hi Marc,
On 2020-09-30 18:23:21 +0100, Marc Zyngier wrote:
Hi Niklas,
[+ Samuel]
On 2020-09-30 17:27, Niklas Söderlund wrote:
quoted
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.
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.
From: Rob Herring <robh@kernel.org> Date: 2020-09-30 20:34:24
On Wed, Sep 30, 2020 at 12:37 PM Niklas Söderlund
[off-list ref] wrote:
Hi Marc,
On 2020-09-30 18:23:21 +0100, Marc Zyngier wrote:
quoted
Hi Niklas,
[+ Samuel]
On 2020-09-30 17:27, Niklas Söderlund wrote:
quoted
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.
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.
On Wed, Sep 30, 2020 at 03:34:10PM -0500, Rob Herring wrote:
On Wed, Sep 30, 2020 at 12:37 PM Niklas Söderlund
[off-list ref] wrote:
quoted
Hi Marc,
On 2020-09-30 18:23:21 +0100, Marc Zyngier wrote:
quoted
Hi Niklas,
[+ Samuel]
On 2020-09-30 17:27, Niklas Söderlund wrote:
quoted
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.
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
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?
Hi Bjorn,
On 2020-09-30 17:51:54 -0500, Bjorn Helgaas wrote:
On Wed, Sep 30, 2020 at 03:34:10PM -0500, Rob Herring wrote:
quoted
On Wed, Sep 30, 2020 at 12:37 PM Niklas Söderlund
[off-list ref] wrote:
quoted
Hi Marc,
On 2020-09-30 18:23:21 +0100, Marc Zyngier wrote:
quoted
Hi Niklas,
[+ Samuel]
On 2020-09-30 17:27, Niklas Söderlund wrote:
quoted
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.
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
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?