linux-kernel - Re: [PATCH v2 5/7] arm64: dts: rockchip: add Pine64 Quartz64-B device tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMdYzYpStDyKxrWgeMyQNs6tGzzVKCbVR_8JZck8Q_0NVU6jxQ@mail.gmail.com>
Date:   Sun, 1 May 2022 07:48:02 -0400
From:   Peter Geis <pgwipeout@...il.com>
To:     Heiko Stübner <heiko@...ech.de>
Cc:     "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Johan Jonker <jbx6244@...il.com>,
        devicetree <devicetree@...r.kernel.org>,
        arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 5/7] arm64: dts: rockchip: add Pine64 Quartz64-B device tree

On Sun, May 1, 2022 at 7:31 AM Heiko Stübner <heiko@...ech.de> wrote:
>
> Am Sonntag, 1. Mai 2022, 09:06:33 CEST schrieb Johan Jonker:
> >
> > On 4/29/22 13:52, Peter Geis wrote:
> > > Add a device tree for the Pine64 Quartz64 Model B single board computer.
> > > This board ouputs debug on uart2 and supports the following components:
> > > Gigabit Ethernet
> > > USB2 x2 (one port otg capable)
> > > USB3
> > > PCIe/SATA M2
> > > HDMI
> > > DSI (RPi compatible pinout)
> > > CSI (RPi compatible pinout)
> > > A/B/G/N WiFi
> > > Bluetooth
> > > SDMMC
> > > eMMC
> > > SPI Flash
> > > PI-40 compatible pin header
> > >
> > > Signed-off-by: Peter Geis <pgwipeout@...il.com>
> > > ---
> > >  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
> > >  .../boot/dts/rockchip/rk3566-quartz64-b.dts   | 615 ++++++++++++++++++
> > >  2 files changed, 616 insertions(+)
> > >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> > > index 4ae9f35434b8..252ee47b8a1d 100644
> > > --- a/arch/arm64/boot/dts/rockchip/Makefile
> > > +++ b/arch/arm64/boot/dts/rockchip/Makefile
> > > @@ -59,5 +59,6 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
> > >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
> > >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
> > >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
> > > +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
> > >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
> > >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-bpi-r2-pro.dtb
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts
> > > new file mode 100644
> > > index 000000000000..184ab7e1d178
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts
> > > @@ -0,0 +1,615 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > +/*
> > > + *
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include <dt-bindings/gpio/gpio.h>
> > > +#include <dt-bindings/pinctrl/rockchip.h>
> > > +#include "rk3566.dtsi"
> > > +
> > > +/ {
> > > +   model = "Pine64 RK3566 Quartz64-B Board";
> > > +   compatible = "pine64,quartz64-b", "rockchip,rk3566";
> > > +
> >
> > [..]
> >
> > > +
> > > +&mdio1 {
> >
> > > +   rgmii_phy1: ethernet-phy@0 {
> > > +           compatible = "ethernet-phy-ieee802.3-c22";
> > > +           reg = <0x1>;
> >
> > Hi,
> >
> > The reg value doesn't match the node name.
> > Other 2 boards use "reg = <0>" with label "rgmii_phy1".
> > Could you check?
>
> I do have an older Quartz-B in my boardfarm and in that older
> devicetree the phy-reg also is "0" instead of the "1" used here.
>
> Is that a hardware-change?

The ethernet maintainers previously brought up that 0x0 is the
broadcast address for the mdio-bus. They requested we put the actual
bus id of the phy even on single phy busses. This is the first one
I've confirmed the bus address on.

Though I realized ethernet-phy@0 should be ethernet-phy@1 since you
mentioned this. Strange dtbs-check doesn't catch this, would you fix
it in line Heiko or do you want another revision?

>
> Thanks
> Heiko
>
>