| Message ID | 20210830103909.323356-1-nsaenzju@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: dts: bcm2711-rpi-4-b: Fix pcie0's unit address | expand |
On Mon, Aug 30, 2021 at 12:39:09PM +0200, Nicolas Saenz Julienne wrote: > dtbs_check currently complains that: > > arch/arm/boot/dts/bcm2711-rpi-4-b.dts:220.10-231.4: Warning > (pci_device_reg): /scb/pcie@7d500000/pci@1,0: PCI unit address format > error, expected "0,0" > > Unsurprisingly pci@0,0 is the right address, as illustrated by its reg > property: > > &pcie0 { > pci@0,0 { > /* > * As defined in the IEEE Std 1275-1994 document, > * reg is a five-cell address encoded as (phys.hi > * phys.mid phys.lo size.hi size.lo). phys.hi > * should contain the device's BDF as 0b00000000 > * bbbbbbbb dddddfff 00000000. The other cells > * should be zero. > */ > reg = <0 0 0 0 0>; > }; > }; > > The bus is clearly 0. So fix it. s/bus/device/ The unit-address format is '<device>,<function>' (and function is optional). The bus number is not part of the unit-address because that is dynamic and then the path would not be fixed/known. The bus is part of 'reg' for true OpenFirmware, but for FDT I think it should always be 0 as the DT is static. Looks like the child node is wrong (both unit-address and reg) as well: usb@1,0 { reg = <0x10000 0 0 0 0>; resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>; }; It doesn't warn because the bridge node is also missing 'device_type = "pci";'. This is all fairly hard to get right (see recent hikey970 patches for a complex example). I'm thinking about writing a tool that generates a DT with PCI nodes by reading the PCI hierachy from sysfs. Rob
On Mon, 2021-08-30 at 08:39 -0500, Rob Herring wrote: > On Mon, Aug 30, 2021 at 12:39:09PM +0200, Nicolas Saenz Julienne wrote: > > dtbs_check currently complains that: > > > > arch/arm/boot/dts/bcm2711-rpi-4-b.dts:220.10-231.4: Warning > > (pci_device_reg): /scb/pcie@7d500000/pci@1,0: PCI unit address format > > error, expected "0,0" > > > > Unsurprisingly pci@0,0 is the right address, as illustrated by its reg > > property: > > > > &pcie0 { > > pci@0,0 { > > /* > > * As defined in the IEEE Std 1275-1994 document, > > * reg is a five-cell address encoded as (phys.hi > > * phys.mid phys.lo size.hi size.lo). phys.hi > > * should contain the device's BDF as 0b00000000 > > * bbbbbbbb dddddfff 00000000. The other cells > > * should be zero. > > */ > > reg = <0 0 0 0 0>; > > }; > > }; > > > > The bus is clearly 0. So fix it. > > s/bus/device/ > > The unit-address format is '<device>,<function>' (and function is > optional). The bus number is not part of the unit-address because that > is dynamic and then the path would not be fixed/known. The bus is part > of 'reg' for true OpenFirmware, but for FDT I think it should always be > 0 as the DT is static. > > Looks like the child node is wrong (both unit-address and reg) as well: > > usb@1,0 { > reg = <0x10000 0 0 0 0>; > resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>; > }; > > It doesn't warn because the bridge node is also missing 'device_type = > "pci";'. > > This is all fairly hard to get right (see recent hikey970 patches for a > complex example). I'm thinking about writing a tool that generates a DT > with PCI nodes by reading the PCI hierachy from sysfs. Thanks for the review, I'll fix all those. That tool would be very helpful.
On Mon, 2021-08-30 at 08:39 -0500, Rob Herring wrote: > On Mon, Aug 30, 2021 at 12:39:09PM +0200, Nicolas Saenz Julienne wrote: > > dtbs_check currently complains that: > > > > arch/arm/boot/dts/bcm2711-rpi-4-b.dts:220.10-231.4: Warning > > (pci_device_reg): /scb/pcie@7d500000/pci@1,0: PCI unit address format > > error, expected "0,0" > > > > Unsurprisingly pci@0,0 is the right address, as illustrated by its reg > > property: > > > > &pcie0 { > > pci@0,0 { > > /* > > * As defined in the IEEE Std 1275-1994 document, > > * reg is a five-cell address encoded as (phys.hi > > * phys.mid phys.lo size.hi size.lo). phys.hi > > * should contain the device's BDF as 0b00000000 > > * bbbbbbbb dddddfff 00000000. The other cells > > * should be zero. > > */ > > reg = <0 0 0 0 0>; > > }; > > }; > > > > The bus is clearly 0. So fix it. > > s/bus/device/ > > The unit-address format is '<device>,<function>' (and function is > optional). The bus number is not part of the unit-address because that > is dynamic and then the path would not be fixed/known. The bus is part > of 'reg' for true OpenFirmware, but for FDT I think it should always be > 0 as the DT is static. > > Looks like the child node is wrong (both unit-address and reg) as well: > > usb@1,0 { > reg = <0x10000 0 0 0 0>; > resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>; > }; > > It doesn't warn because the bridge node is also missing 'device_type = > "pci";'. > > This is all fairly hard to get right (see recent hikey970 patches for a > complex example). I'm thinking about writing a tool that generates a DT > with PCI nodes by reading the PCI hierachy from sysfs. Just to double-check I understood everything, with: lspci -D -PP 0000:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge (rev 10) 0000:00:00.0/01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller (rev 01) It should look like this: &pcie0 { pci@0,0 { device_type = "pci"; #address-cells = <3>; #size-cells = <2>; ranges; reg = <0 0 0 0 0>; usb@0,0 { reg = <0 0 0 0 0>; resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>; }; }; }; Thanks!
On Mon, Aug 30, 2021 at 11:45 AM <nsaenzju@redhat.com> wrote: > > On Mon, 2021-08-30 at 08:39 -0500, Rob Herring wrote: > > On Mon, Aug 30, 2021 at 12:39:09PM +0200, Nicolas Saenz Julienne wrote: > > > dtbs_check currently complains that: > > > > > > arch/arm/boot/dts/bcm2711-rpi-4-b.dts:220.10-231.4: Warning > > > (pci_device_reg): /scb/pcie@7d500000/pci@1,0: PCI unit address format > > > error, expected "0,0" > > > > > > Unsurprisingly pci@0,0 is the right address, as illustrated by its reg > > > property: > > > > > > &pcie0 { > > > pci@0,0 { > > > /* > > > * As defined in the IEEE Std 1275-1994 document, > > > * reg is a five-cell address encoded as (phys.hi > > > * phys.mid phys.lo size.hi size.lo). phys.hi > > > * should contain the device's BDF as 0b00000000 > > > * bbbbbbbb dddddfff 00000000. The other cells > > > * should be zero. > > > */ > > > reg = <0 0 0 0 0>; > > > }; > > > }; > > > > > > The bus is clearly 0. So fix it. > > > > s/bus/device/ > > > > The unit-address format is '<device>,<function>' (and function is > > optional). The bus number is not part of the unit-address because that > > is dynamic and then the path would not be fixed/known. The bus is part > > of 'reg' for true OpenFirmware, but for FDT I think it should always be > > 0 as the DT is static. > > > > Looks like the child node is wrong (both unit-address and reg) as well: > > > > usb@1,0 { > > reg = <0x10000 0 0 0 0>; > > resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>; > > }; > > > > It doesn't warn because the bridge node is also missing 'device_type = > > "pci";'. > > > > This is all fairly hard to get right (see recent hikey970 patches for a > > complex example). I'm thinking about writing a tool that generates a DT > > with PCI nodes by reading the PCI hierachy from sysfs. > > Just to double-check I understood everything, with: > > lspci -D -PP > 0000:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge (rev 10) > 0000:00:00.0/01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller (rev 01) > > It should look like this: > > &pcie0 { > pci@0,0 { > device_type = "pci"; > #address-cells = <3>; > #size-cells = <2>; > ranges; > > reg = <0 0 0 0 0>; > > usb@0,0 { > reg = <0 0 0 0 0>; > resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>; > }; > }; > }; Yes, that looks correct. Rob
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts index f24bdd0870a5..8a77f9e942be 100644 --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts @@ -217,7 +217,7 @@ phy1: ethernet-phy@1 { }; &pcie0 { - pci@1,0 { + pci@0,0 { #address-cells = <3>; #size-cells = <2>; ranges;
dtbs_check currently complains that: arch/arm/boot/dts/bcm2711-rpi-4-b.dts:220.10-231.4: Warning (pci_device_reg): /scb/pcie@7d500000/pci@1,0: PCI unit address format error, expected "0,0" Unsurprisingly pci@0,0 is the right address, as illustrated by its reg property: &pcie0 { pci@0,0 { /* * As defined in the IEEE Std 1275-1994 document, * reg is a five-cell address encoded as (phys.hi * phys.mid phys.lo size.hi size.lo). phys.hi * should contain the device's BDF as 0b00000000 * bbbbbbbb dddddfff 00000000. The other cells * should be zero. */ reg = <0 0 0 0 0>; }; }; The bus is clearly 0. So fix it. Fixes: 258f92d2f840 ("ARM: dts: bcm2711: Add reset controller to xHCI node") Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com> --- arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)