Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Fri, 18 Feb 2022 13:32:11 +0100
From:   Michael Walle <michael@walle.cc>
To:     Kavyasree.Kotagiri@microchip.com
Cc:     Manohar.Puri@microchip.com, UNGLinuxDriver@microchip.com,
        alexandre.belloni@bootlin.com, arnd@arndb.de,
        devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, Nicolas.Ferre@microchip.com,
        olof@lixom.net, robh+dt@kernel.org, soc@kernel.org
Subject: Re: [PATCH v4] ARM: dts: add DT for lan966 SoC and 2-port board
 pcb8291
In-Reply-To: <CO1PR11MB4865B205DF4490D37E96524792379@CO1PR11MB4865.namprd11.prod.outlook.com>
References: <20220209111318.21112-1-kavyasree.kotagiri@microchip.com>
 <20220209184600.1230365-1-michael@walle.cc>
 <CO1PR11MB486534A2987684CC7402CE06922F9@CO1PR11MB4865.namprd11.prod.outlook.com>
 <97bcfa4417d5f8c41cc6aa1e411c8747@walle.cc>
 <CO1PR11MB4865E913D083C1D80D4E1F80922F9@CO1PR11MB4865.namprd11.prod.outlook.com>
 <b98f40575f88a0bbf205d628f73cccac@walle.cc>
 <CO1PR11MB4865B205DF4490D37E96524792379@CO1PR11MB4865.namprd11.prod.outlook.com>
User-Agent: Roundcube Webmail/1.4.12
Message-ID: <426e31325066cfa9f0ab50860289e12a@walle.cc>
Precedence: bulk

Am 2022-02-18 13:28, schrieb Kavyasree.Kotagiri@microchip.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@microchip.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@microchip.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@e0090000 {
>> >> >> > +                     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.

-michael