linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Kavyasree.Kotagiri@microchip.com
Cc: devicetree@vger.kernel.org, alexandre.belloni@bootlin.com,
	arnd@arndb.de, linux-kernel@vger.kernel.org,
	UNGLinuxDriver@microchip.com, soc@kernel.org, robh+dt@kernel.org,
	olof@lixom.net, Manohar.Puri@microchip.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4] ARM: dts: add DT for lan966 SoC and 2-port board pcb8291
Date: Mon, 21 Feb 2022 08:28:06 +0100	[thread overview]
Message-ID: <ee1e083c29359f2afb21d0b1457cdce0@walle.cc> (raw)
In-Reply-To: <CO1PR11MB4865E667CB963C8B5DE5000B923A9@CO1PR11MB4865.namprd11.prod.outlook.com>

Am 2022-02-21 06:44, schrieb Kavyasree.Kotagiri@microchip.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@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.
>> 
> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2022-02-21  7:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09 11:13 [PATCH v4] ARM: dts: add DT for lan966 SoC and 2-port board pcb8291 Kavyasree Kotagiri
2022-02-09 12:32 ` Tudor.Ambarus
2022-02-10 12:37   ` Michael Walle
2022-02-10 13:02     ` Kavyasree.Kotagiri
2022-02-10 13:33       ` Michael Walle
2022-02-18 10:55     ` Kavyasree.Kotagiri
2022-02-09 18:46 ` Michael Walle
2022-02-10  9:40   ` Kavyasree.Kotagiri
2022-02-10  9:50     ` Michael Walle
2022-02-10 11:52       ` Kavyasree.Kotagiri
2022-02-10 12:05         ` Michael Walle
2022-02-18 12:28           ` Kavyasree.Kotagiri
2022-02-18 12:32             ` Michael Walle
2022-02-21  5:44               ` Kavyasree.Kotagiri
2022-02-21  7:28                 ` Michael Walle [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ee1e083c29359f2afb21d0b1457cdce0@walle.cc \
    --to=michael@walle.cc \
    --cc=Kavyasree.Kotagiri@microchip.com \
    --cc=Manohar.Puri@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=robh+dt@kernel.org \
    --cc=soc@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).