On Sun, Aug 16, 2020 at 4:40 AM Marc Zyngier [off-list ref] wrote:

On Sun, 16 Aug 2020 00:22:28 +0100,
Bjorn Helgaas [off-list ref] wrote:

quoted

On Sat, Aug 15, 2020 at 01:51:11PM +0100, Marc Zyngier wrote:

quoted

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 the blunder, let's add a workaround
to the pcie-rockchip driver, adding the missing property when
none is found at boot time. A warning will hopefully nudge the
user into updating their DT to a fixed version if they can, but
the insentive is obviously pretty small.

s/insentive/incentive/ (Lorenzo or I can fix this up)

quoted

Fixes: 2f96593ecc37 ("of_address: Add bus type match for pci ranges parser")
Suggested-by: Roh Herring <robh+dt@kernel.org>

s/Roh/Rob/ (similarly)

Clearly not my day when it comes to proofreading commit messages.
Thanks for pointing this out, and in advance for fixing it up.

quoted

quoted

Signed-off-by: Marc Zyngier <maz@kernel.org>

This looks like a candidate for v5.9, since 2f96593ecc37 was merged
during the v5.9 merge window, right?

Absolutely.

quoted

I wonder how many other DTs are similarly broken?  Maybe Rob's DT
checker has already looked?

I've just managed to run the checker, which comes up with all kinds of
goodies. Apart from the above, it also spots the following:

- arch/arm64/boot/dts/mediatek/mt7622.dtsi: Has a device_type property
  in its main PCIe node, but not in the child nodes. It isn't obvious
  to me whether that's a violation or not (the spec doesn't say
  whether the property should be set on a per-port basis). Rob?

The rule is bridge nodes should have 'device_type = "pci"'. But what's
needed to fix these cases is setting device_type where we are parsing
ranges or dma-ranges which we're not doing on the child ndes.
Otherwise, I don't think it matters in this case unless you have child
(grandchild here) nodes for PCI devices. If you did have child nodes,
the address translation was already broken before this change.

- arch/arm64/boot/dts/qcom/msm8996.dtsi: Only one out of the three
  PCIe nodes has the device_type property, probably broken similarly
  to rk3399.

The only upstream board is DB820c, so probably not as wide an impact...

There are also 92 (lots of duplicates due to multiple boards) more
cases in arch/arm/. A log is here[1].

I could move the workaround to drivers/pci/of.c, and have it called
from the individual drivers. I don't have the HW to test those though.

Thoughts?

I think we should go with my other suggestion of looking at the node
name. Looks like just checking 'pcie' is enough. We can skip 'pci' as
I don't see any cases.

Rob

[1] https://gitlab.com/robherring/linux-dt-bindings/-/jobs/688752562

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