linux-kernel - Re: [PATCH v4] ARM: dts: add DT for lan966 SoC and 2-port board pcb8291

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] [day] [month] [year] [list]

Message-ID: <ee1e083c29359f2afb21d0b1457cdce0@walle.cc>
Date:   Mon, 21 Feb 2022 08:28:06 +0100
From:   Michael Walle <michael@...le.cc>
To:     Kavyasree.Kotagiri@...rochip.com
Cc:     Manohar.Puri@...rochip.com, UNGLinuxDriver@...rochip.com,
        alexandre.belloni@...tlin.com, arnd@...db.de,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Nicolas.Ferre@...rochip.com,
        olof@...om.net, robh+dt@...nel.org, soc@...nel.org
Subject: Re: [PATCH v4] ARM: dts: add DT for lan966 SoC and 2-port board
 pcb8291

Am 2022-02-21 06:44, schrieb Kavyasree.Kotagiri@...rochip.com:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know 
>> the
>> content is safe
>> 
>> Am 2022-02-18 13:28, schrieb Kavyasree.Kotagiri@...rochip.com:
>> >> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> >> the
>> >> content is safe
>> >>
>> >> Am 2022-02-10 12:52, schrieb Kavyasree.Kotagiri@...rochip.com:
>> >> >> EXTERNAL EMAIL: Do not click links or open attachments unless you
>> know
>> >> >> the
>> >> >> content is safe
>> >> >>
>> >> >> Am 2022-02-10 10:40, schrieb Kavyasree.Kotagiri@...rochip.com:
>> >> >> >> EXTERNAL EMAIL: Do not click links or open attachments unless you
>> >> know
>> >> >> >> the
>> >> >> >> content is safe
>> >> >>
>> >> >> >> > +     clocks {
>> >> >> >> [..]
>> >> >> >> > +
>> >> >> >> > +             nic_clk: nic_clk {
>> >> >> >>
>> >> >> >> What does nic_clk stand for? If I had to guess, it
>> >> >> >> has something to do with network. But..
>> >> >> >>
>> >> >> > NIC clock is the clock used by AXI, AHB fabric and APB bridges which
>> >> >> > connects all the peripherals.
>> >> >> > It is named so because the AXI fabric is based on NIC400 IP from ARM
>> >> >>
>> >> >> Ok, thanks for clarification.
>> >> >>
>> >> >>
>> >> >> >> > +             watchdog: watchdog@...90000 {
>> >> >> >> > +                     compatible = "snps,dw-wdt";
>> >> >> >> > +                     reg = <0xe0090000 0x1000>;
>> >> >> >> > +                     interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
>> >> >> >> > +                     clocks = <&nic_clk>;
>> >> >> >>
>> >> >> >> Btw. can we disable all nodes by default and enable them
>> >> >> >> in the board dts files?
>> >> >> > I would like to have only board specific nodes enabled in dts files
>> >> >> > and rest of them in dtsi file
>> >> >>
>> >> >> And how do you know which ones are board specific? E.g. I would like
>> >> >> to add our board which is also based on the lan9668. Maybe I don't
>> >> >> want a watchdog (or whatever node). Of course I could use
>> >> >>
>> >> >> &watchdog {
>> >> >>    status = "disabled";
>> >> >> };
>> >> >>
>> >> >> But IMHO opt-in is better. At least thats what we are doing for
>> >> >> the layerscape over on arm64.
>> >> >>
>> >> > Basically, I am disabling only the nodes which have pinctrl settings
>> >> > in dtsi file
>> >> > and enable in dts to make sure there are no conflicts on pins on the
>> >> > board.
>> >>
>> >> Thats not what I'm asking. I would like to see *optional* nodes
>> >> disabled by default. Whether the watchdog is optional might be
>> >> debatable, but what about the usb controller and the qspi
>> >> controller? They don't have shared pins AFAIK, so according
>> >> to your rule, they will be enabled by default and each board
>> >> which doesn't have anything connected on these pins would have
>> >> to disabled it.
>> >>
>> >> Please keep in mind that this .dtsi will also be used by boards
>> >> not manufactured by microchip.
>> >>
>> > I agree with you - "disabling optional nodes in dtsi"
>> > I have gone through all the nodes.
>> > Confirmed and moved enabling optional node watchdog
>> > to dts file.
>> 
>> Great, I just wanted to get to an agreement how the optional nodes
>> should be handled. If it turns out, some are still optional or
>> some aren't. It is easy to just mark them disabled and enable them
>> in the board dts files in a later patch.
>> 
> Sorry, I didn't get you. Do you still see optional nodes in my dtsi?
> I think GPIO controller, Interrupt controller, XDMA, timers, AES, SHA, 
> TRNG are
> not optional. So, I keep them enabled in dtsi.

Agreed. Once you posted a new version, I'll post an RFC (or a regular
patch depending how fast this is picked up) for our board based on the
LAN966x.

-michael