[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFd5g45s6yo=HSut76YknOkUeKbV8yOXWbivc=EyM2s7R8DOrA@mail.gmail.com>
Date: Wed, 6 Sep 2017 01:19:11 -0700
From: Brendan Higgins <brendanhiggins@...gle.com>
To: Joel Stanley <joel@....id.au>
Cc: Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Russell King <linux@...linux.org.uk>, avifishman70@...il.com,
tmaimon77@...il.com, Rick Altherr <raltherr@...gle.com>,
Florian Fainelli <f.fainelli@...il.com>,
devicetree <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arm-kernel@...ts.infradead.org,
OpenBMC Maillist <openbmc@...ts.ozlabs.org>
Subject: Re: [PATCH v3 2/3] arm: dts: add Nuvoton NPCM750 device tree
On Tue, Sep 5, 2017 at 10:23 PM, Joel Stanley <joel@....id.au> wrote:
> On Wed, Sep 6, 2017 at 10:00 AM, Brendan Higgins
> <brendanhiggins@...gle.com> wrote:
>> +++ b/Documentation/devicetree/bindings/arm/npcm/npcm.txt
>> @@ -0,0 +1,6 @@
>> +NPCM Platforms Device Tree Bindings
>> +-----------------------------------
>> +NPCM750 SoC
>> +Required root node properties:
>> + - compatible = "nuvoton,npcm750";
>> +
>
> This is minimal. I assume there will be more content added as more
> support is added?
Yep, that's the plan. They have a number of similar BMCs, both those
based on different ARM cores and some with different peripheral sets,
so we will probably want to have different compat strings for those.
>
> Does it need it's own directory?
Not sure, I saw that some of the other architectures did it, some did
not. I don't feel strongly about it.
>
>
>> diff --git a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
>> new file mode 100644
>> index 000000000000..54df32cff21b
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
>
>> +
>> +/dts-v1/;
>> +#include "nuvoton-npcm750.dtsi"
>> +
>> +/ {
>> + model = "Nuvoton npcm750 Development Board (Device Tree)";
>> + compatible = "nuvoton,npcm750";
>> +
>> + chosen {
>> + stdout-path = &serial3;
>> + bootargs = "earlyprintk=serial,serial3,115200";
>> + };
>> +
>> + memory {
>> + reg = <0 0x40000000>;
>> + };
>> +
>> + cpus {
>> + enable-method = "nuvoton,npcm7xx-smp";
>> + };
>> +
>> + clk: clock-controller@...01000 {
>> + status = "okay";
>> + };
>> +
>> + apb {
>> + watchdog1: watchdog@...09000 {
>> + status = "okay";
>> + };
>
> You've already got the label for the node, is there are reason you
> don't use a phandle to set the status?
Addressed in v4.
>
> &watchdog1 {
> status = "okay";
> };
>
> Same with the serial nodes below.
>
>> +
>> + serial0: serial0@...01000 {
>> + status = "okay";
>> + };
>> +
>> + serial1: serial1@...02000 {
>> + status = "okay";
>> + };
>> +
>> + serial2: serial2@...03000 {
>> + status = "okay";
>> + };
>> +
>> + serial3: serial3@...04000 {
>> + status = "okay";
>> + };
>> + };
Powered by blists - more mailing lists