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: <CAP6Zq1iXaN8D-g2O=cD-XERGj3BROQO=NJ66mquVsOw8nSM=0A@mail.gmail.com>
Date:   Fri, 10 Jun 2022 01:29:50 +0300
From:   Tomer Maimon <tmaimon77@...il.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Avi Fishman <avifishman70@...il.com>,
        Tali Perry <tali.perry1@...il.com>,
        Joel Stanley <joel@....id.au>,
        Patrick Venture <venture@...gle.com>,
        Nancy Yuen <yuenn@...gle.com>,
        Benjamin Fair <benjaminfair@...gle.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Greg KH <gregkh@...uxfoundation.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Olof Johansson <olof@...om.net>,
        Jiri Slaby <jirislaby@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        Vinod Koul <vkoul@...nel.org>,
        Biju Das <biju.das.jz@...renesas.com>,
        Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
        Robert Hancock <robert.hancock@...ian.com>,
        Jonathan Neuschäfer <j.neuschaefer@....net>,
        Lubomir Rintel <lkundrak@...sk>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        LINUXWATCHDOG <linux-watchdog@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 18/20] arm64: dts: nuvoton: Add initial NPCM8XX device tree

Hi Krzysztof,

Sorry, probably I missed your comments (too many patches to handle at
one time :-))...

On Wed, 8 Jun 2022 at 13:21, Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 08/06/2022 11:56, Tomer Maimon wrote:
> > This adds initial device tree support for the
> > Nuvoton NPCM845 Board Management controller (BMC) SoC family.
> >
> > The NPCM845 based quad-core Cortex-A35 ARMv8 architecture and
> > have various peripheral IPs.
> >
> > Signed-off-by: Tomer Maimon <tmaimon77@...il.com>
> > ---
> >  arch/arm64/boot/dts/Makefile                  |   1 +
> >  .../dts/nuvoton/nuvoton-common-npcm8xx.dtsi   | 197 ++++++++++++++++++
> >  .../boot/dts/nuvoton/nuvoton-npcm845.dtsi     |  76 +++++++
> >  3 files changed, 274 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
> >  create mode 100644 arch/arm64/boot/dts/nuvoton/nuvoton-npcm845.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> > index 1ba04e31a438..7b107fa7414b 100644
> > --- a/arch/arm64/boot/dts/Makefile
> > +++ b/arch/arm64/boot/dts/Makefile
> > @@ -19,6 +19,7 @@ subdir-y += lg
> >  subdir-y += marvell
> >  subdir-y += mediatek
> >  subdir-y += microchip
> > +subdir-y += nuvoton
> >  subdir-y += nvidia
> >  subdir-y += qcom
> >  subdir-y += realtek
> > diff --git a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
> > new file mode 100644
> > index 000000000000..97e108c50760
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
> > @@ -0,0 +1,197 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (c) 2021 Nuvoton Technology tomer.maimon@...oton.com
> > +
> > +#include <dt-bindings/clock/nuvoton,npcm8xx-clock.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +
> > +/ {
> > +     #address-cells = <2>;
> > +     #size-cells = <2>;
> > +     interrupt-parent = <&gic>;
> > +
> > +     /* external reference clock */
> > +     clk_refclk: clk-refclk {
> > +             compatible = "fixed-clock";
> > +             #clock-cells = <0>;
> > +             clock-frequency = <25000000>;
>
> Ignored comment.
Could we use it as a default clock-frequency?
>
> > +             clock-output-names = "refclk";
> > +     };
> > +
> > +     /* external reference clock for cpu. float in normal operation */
> > +     clk_sysbypck: clk-sysbypck {
> > +             compatible = "fixed-clock";
> > +             #clock-cells = <0>;
> > +             clock-frequency = <1000000000>;
>
> Ignored comment.
same as above
>
> > +             clock-output-names = "sysbypck";
> > +     };
> > +
> > +     /* external reference clock for MC. float in normal operation */
> > +     clk_mcbypck: clk-mcbypck {
> > +             compatible = "fixed-clock";
> > +             #clock-cells = <0>;
> > +             clock-frequency = <1050000000>;
same as above
> > +             clock-output-names = "mcbypck";
> > +     };
> > +
> > +     soc {
> > +             #address-cells = <2>;
> > +             #size-cells = <2>;
> > +             compatible = "simple-bus";
> > +             interrupt-parent = <&gic>;
> > +             ranges;
> > +
> > +             gcr: gcr@...00000 {
I understand it sounds generic but I try to be as much compatible with NPCM7XX
https://elixir.bootlin.com/linux/v5.19-rc1/source/arch/arm/boot/dts/nuvoton-common-npcm7xx.dtsi#L91
>
> Ignored comment.
>
> > +                     compatible = "nuvoton,npcm845-gcr", "syscon",
> > +                             "simple-mfd";
>
> This is not a simple-mfd... I see original bindings defined it that way,
> but why? I think they should be corrected - remove simple-mfd from the
> bindings and DTS.
will remove in both places in V3
>
>
> > +                     reg = <0x0 0xf0800000 0x0 0x1000>;
> > +             };
> > +
> > +             gic: interrupt-controller@...f9000 {
> > +                     compatible = "arm,gic-400";
> > +                     reg = <0x0 0xdfff9000 0x0 0x1000>,
> > +                           <0x0 0xdfffa000 0x0 0x2000>,
> > +                           <0x0 0xdfffc000 0x0 0x2000>,
> > +                           <0x0 0xdfffe000 0x0 0x2000>;
> > +                     interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > +                     #interrupt-cells = <3>;
> > +                     interrupt-controller;
> > +                     #address-cells = <0>;
> > +                     ppi-partitions {
> > +                             ppi_cluster0: interrupt-partition-0 {
> > +                                     affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
> > +                             };
> > +                     };
> > +             };
> > +     };
> > +
> > +     ahb {
> > +             #address-cells = <2>;
> > +             #size-cells = <2>;
> > +             compatible = "simple-bus";
> > +             interrupt-parent = <&gic>;

> > +             ranges;
> > +
> > +             rstc: rstc@...01000 {
>
> Ignored comment.
>
I understand it sounds generic but I try to be as much compatible with NPCM7XX
https://elixir.bootlin.com/linux/v5.19-rc1/source/arch/arm/boot/dts/nuvoton-common-npcm7xx.dtsi#L109
> Four comments from v1 ignored in this patch alone.
>
one more comment in V1
 "+             cpu0: cpu@0 {
 +                     device_type = "cpu";
 +                     compatible = "arm,cortex-a35";
 +                     clocks = <&clk NPCM8XX_CLK_CPU>;
 +                     reg = <0x0 0x0>;
Why do you have two address cells? A bit more complicated and not
necessary, I think."
the arm,cortex-a35 is 64 Bit this is why we use  #address-cells = <2>;
and therefore reg = <0x0 0x0>;

> I'll stop reviewing, it is a waste of my time.
>
> NAK for this change.
>
> Best regards,
> Krzysztof

Again sorry to miss these comments in V1.

Appreciate your time.

Best regards,

Tomer

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ