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
| ||
|
Message-ID: <7b253e51-30d4-7a71-2b14-7b987c3045fc@linaro.org> Date: Mon, 3 Oct 2022 09:45:57 +0200 From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> To: Conor Dooley <conor@...nel.org>, Hal Feng <hal.feng@...ux.starfivetech.com> Cc: linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org, linux-clk@...r.kernel.org, linux-gpio@...r.kernel.org, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, Daniel Lezcano <daniel.lezcano@...aro.org>, Thomas Gleixner <tglx@...utronix.de>, Marc Zyngier <maz@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>, Stephen Boyd <sboyd@...nel.org>, Michael Turquette <mturquette@...libre.com>, Linus Walleij <linus.walleij@...aro.org>, Emil Renner Berthing <kernel@...il.dk>, linux-kernel@...r.kernel.org Subject: Re: [PATCH v1 27/30] RISC-V: Add initial StarFive JH7110 device tree On 01/10/2022 12:52, Conor Dooley wrote: > On Fri, Sep 30, 2022 at 03:49:14PM +0800, Hal Feng wrote: >> From: Emil Renner Berthing <kernel@...il.dk> >> >> Add initial device tree for the JH7110 RISC-V SoC by >> StarFive Technology Ltd. >> >> Signed-off-by: Emil Renner Berthing <kernel@...il.dk> >> Signed-off-by: Jianlong Huang <jianlong.huang@...rfivetech.com> >> Signed-off-by: Hal Feng <hal.feng@...ux.starfivetech.com> > > There's little point reviewing this dt since there's a load of issues > that you can trivially find by running dtbs_check/dt_binding_check, but Yep... > this SoB change is wrong - if Emil wrote the patch, then Jianlong's SoB > is either redundant or should be accompanied by a Co-developed-by tag. Depends. Jianlong might have just rebased the patch. > > Ditto for patch 28/30 "RISC-V: Add StarFive JH7110 VisionFive2 board > device tree". > >> --- >> arch/riscv/boot/dts/starfive/jh7110.dtsi | 449 +++++++++++++++++++++++ >> 1 file changed, 449 insertions(+) >> create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi >> >> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi >> new file mode 100644 >> index 000000000000..46f418d4198a >> --- /dev/null >> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi > >> + >> + osc: osc { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + }; >> + >> + clk_rtc: clk_rtc { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + }; >> + >> + gmac0_rmii_refin: gmac0_rmii_refin { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <50000000>; > > I assume, given osc has it's frequency set in the board dts, that these > are all oscillators on the SoC? > >> + }; >> + >> + gmac0_rgmii_rxin: gmac0_rgmii_rxin { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <125000000>; >> + }; >> + >> + gmac1_rmii_refin: gmac1_rmii_refin { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <50000000>; >> + }; >> + >> + gmac1_rgmii_rxin: gmac1_rgmii_rxin { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <125000000>; >> + }; >> + >> + i2stx_bclk_ext: i2stx_bclk_ext { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <12288000>; >> + }; >> + >> + i2stx_lrck_ext: i2stx_lrck_ext { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <192000>; >> + }; >> + >> + i2srx_bclk_ext: i2srx_bclk_ext { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <12288000>; >> + }; >> + >> + i2srx_lrck_ext: i2srx_lrck_ext { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <192000>; >> + }; >> + >> + tdm_ext: tdm_ext { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <49152000>; >> + }; >> + >> + mclk_ext: mclk_ext { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <49152000>; >> + }; > >> + syscrg: syscrg@...20000 { > > The generic node name for syscons is just "syscon" afaik. Yes. > >> + compatible = "syscon", "simple-mfd"; And this is not allowed. Needs specific compatible. >> + reg = <0x0 0x13020000 0x0 0x10000>; >> + > >> + aoncrg: aoncrg@...00000 { > > Again, syscon as the node name? Yes. > >> + compatible = "syscon", "simple-mfd"; And this is a NAK. >> + reg = <0x0 0x17000000 0x0 0x10000>; >> + >> + gpio: gpio@...40000 { > > Someone else (Krzysztof maybe?) should comment, but is "pinctrl" not the > genric node name for pinctrl nodes? Yes, for pin controller nodes, this should be "pinctrl" and schema requires it. The problem was that his driver did not use generic pinctrl bindings, which is no-go on its own. This could be a gpio controller (so "gpio" would be fine), although compatible suggests otherwise. Best regards, Krzysztof
Powered by blists - more mailing lists