| Message ID | 20200819094255.474565-1-maz@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] of: address: Work around missing device_type property in pcie nodes | expand |
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(-) > 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")
On 2020-08-19 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(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 590493e04b01..b37bd9cc2810 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -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,
> --
> 2.27.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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/
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: > > 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. > > 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...
On Wed, Sep 30, 2020 at 12:37 PM Niklas Söderlund <niklas.soderlund@ragnatech.se> wrote: > > 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: > > > 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. > > > > > 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
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 > <niklas.soderlund@ragnatech.se> wrote: > > > > 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: > > > > 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. > > > > > > > > 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 > [1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/log/?h=for-linus
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: > > On Wed, Sep 30, 2020 at 12:37 PM Niklas Söderlund > > <niklas.soderlund@ragnatech.se> wrote: > > > > > > 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: > > > > > 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. > > > > > > > > > > > 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). > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/log/?h=for-linus
diff --git a/drivers/of/address.c b/drivers/of/address.c index 590493e04b01..b37bd9cc2810 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -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,
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(-)