From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
devicetree@vger.kernel.org,
Mike Turquette <mturquette@linaro.org>,
Jason Cooper <jason@lakedaemon.net>,
Tawfik Bayouk <tawfik@marvell.com>, Andrew Lunn <andrew@lunn.ch>,
Seif Mazareeb <seif@marvell.com>,
Lior Amsalem <alior@marvell.com>,
linux-mtd@lists.infradead.org,
Gregory Clement <gregory.clement@free-electrons.com>,
linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH 4/6] ARM: mvebu: Add support for NAND controller in Armada 38x SoC
Date: Thu, 13 Mar 2014 00:39:09 +0300 [thread overview]
Message-ID: <5320D3FD.8010704@cogentembedded.com> (raw)
In-Reply-To: <20140312203007.GA7396@arch.cereza>
On 03/12/2014 11:30 PM, Ezequiel Garcia wrote:
>>> The Armada 38x SoC family has a NAND controller, compatible
>>> with the controller in Armada 370/375/XP SoCs. Add support for
>>> it in the devicetree file.
>>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>>> ---
>>> arch/arm/boot/dts/armada-38x.dtsi | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
>>> index 76cc27e..18d8f80 100644
>>> --- a/arch/arm/boot/dts/armada-38x.dtsi
>>> +++ b/arch/arm/boot/dts/armada-38x.dtsi
>>> @@ -345,6 +345,16 @@
>>> clocks = <&mainpll>;
>>> clock-output-names = "nand";
>>> };
>>> +
>>> + nand@d0000 {
>> ePAPR standard [1] tells us:
>> The name of a node should be somewhat generic, reflecting the function of
>> the device and not its precise programming model. If appropriate, the name
>> should be one of the following choices:
>> [...]
>> • flash
> I think 'nand' is generic enough, isn't it?
It is but not more generic than "flash". :-)
> In any case, it seems sane to distinguish a NAND flash from a NOR flash,
> from a SPI flash.
I don't know enough about the SPI flashes but this is only a node name, no
more, so I think we can afford to be really generic...
> FWIW, quite a few other SoCs have chosen 'nand' for the node name, including
> the other Armada variants. Was this a wrong choice?
I guess. There's a lot of wrong choices now all over the
arch/arm/boot/dts/ because people are probably not aware of the necessary
documentation such as http://devicetree.org/Device_Tree_Usage (pointing to
ePAPR and having a passage on the generic device names too).
WBR, Sergei
WARNING: multiple messages have this Message-ID (diff)
From: sergei.shtylyov@cogentembedded.com (Sergei Shtylyov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/6] ARM: mvebu: Add support for NAND controller in Armada 38x SoC
Date: Thu, 13 Mar 2014 00:39:09 +0300 [thread overview]
Message-ID: <5320D3FD.8010704@cogentembedded.com> (raw)
In-Reply-To: <20140312203007.GA7396@arch.cereza>
On 03/12/2014 11:30 PM, Ezequiel Garcia wrote:
>>> The Armada 38x SoC family has a NAND controller, compatible
>>> with the controller in Armada 370/375/XP SoCs. Add support for
>>> it in the devicetree file.
>>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>>> ---
>>> arch/arm/boot/dts/armada-38x.dtsi | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
>>> index 76cc27e..18d8f80 100644
>>> --- a/arch/arm/boot/dts/armada-38x.dtsi
>>> +++ b/arch/arm/boot/dts/armada-38x.dtsi
>>> @@ -345,6 +345,16 @@
>>> clocks = <&mainpll>;
>>> clock-output-names = "nand";
>>> };
>>> +
>>> + nand at d0000 {
>> ePAPR standard [1] tells us:
>> The name of a node should be somewhat generic, reflecting the function of
>> the device and not its precise programming model. If appropriate, the name
>> should be one of the following choices:
>> [...]
>> ? flash
> I think 'nand' is generic enough, isn't it?
It is but not more generic than "flash". :-)
> In any case, it seems sane to distinguish a NAND flash from a NOR flash,
> from a SPI flash.
I don't know enough about the SPI flashes but this is only a node name, no
more, so I think we can afford to be really generic...
> FWIW, quite a few other SoCs have chosen 'nand' for the node name, including
> the other Armada variants. Was this a wrong choice?
I guess. There's a lot of wrong choices now all over the
arch/arm/boot/dts/ because people are probably not aware of the necessary
documentation such as http://devicetree.org/Device_Tree_Usage (pointing to
ePAPR and having a passage on the generic device names too).
WBR, Sergei
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
To: Ezequiel Garcia
<ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Mike Turquette
<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
Thomas Petazzoni
<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
Lior Amsalem <alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
Tawfik Bayouk <tawfik-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>,
Seif Mazareeb <seif-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
Gregory Clement
<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
Sebastian Hesselbarth
<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 4/6] ARM: mvebu: Add support for NAND controller in Armada 38x SoC
Date: Thu, 13 Mar 2014 00:39:09 +0300 [thread overview]
Message-ID: <5320D3FD.8010704@cogentembedded.com> (raw)
In-Reply-To: <20140312203007.GA7396-nAQHv47ARr+vIlHkl8J1cg@public.gmane.org>
On 03/12/2014 11:30 PM, Ezequiel Garcia wrote:
>>> The Armada 38x SoC family has a NAND controller, compatible
>>> with the controller in Armada 370/375/XP SoCs. Add support for
>>> it in the devicetree file.
>>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>> ---
>>> arch/arm/boot/dts/armada-38x.dtsi | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
>>> index 76cc27e..18d8f80 100644
>>> --- a/arch/arm/boot/dts/armada-38x.dtsi
>>> +++ b/arch/arm/boot/dts/armada-38x.dtsi
>>> @@ -345,6 +345,16 @@
>>> clocks = <&mainpll>;
>>> clock-output-names = "nand";
>>> };
>>> +
>>> + nand@d0000 {
>> ePAPR standard [1] tells us:
>> The name of a node should be somewhat generic, reflecting the function of
>> the device and not its precise programming model. If appropriate, the name
>> should be one of the following choices:
>> [...]
>> • flash
> I think 'nand' is generic enough, isn't it?
It is but not more generic than "flash". :-)
> In any case, it seems sane to distinguish a NAND flash from a NOR flash,
> from a SPI flash.
I don't know enough about the SPI flashes but this is only a node name, no
more, so I think we can afford to be really generic...
> FWIW, quite a few other SoCs have chosen 'nand' for the node name, including
> the other Armada variants. Was this a wrong choice?
I guess. There's a lot of wrong choices now all over the
arch/arm/boot/dts/ because people are probably not aware of the necessary
documentation such as http://devicetree.org/Device_Tree_Usage (pointing to
ePAPR and having a passage on the generic device names too).
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-03-12 20:39 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-12 15:16 [PATCH 0/6] Armada 380 NAND support Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` [PATCH 1/6] clk: mvebu: Support Armada 380 SoC on the core divider clock Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` [PATCH 2/6] ARM: mvebu: Add a 2 GHz fixed-clock on Armada 38x SoCs Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` [PATCH 3/6] ARM: mvebu: Add the Core Divider clock to " Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` [PATCH 4/6] ARM: mvebu: Add support for NAND controller in Armada 38x SoC Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 21:17 ` Sergei Shtylyov
2014-03-12 21:17 ` Sergei Shtylyov
2014-03-12 21:17 ` Sergei Shtylyov
2014-03-12 20:30 ` Ezequiel Garcia
2014-03-12 20:30 ` Ezequiel Garcia
2014-03-12 20:30 ` Ezequiel Garcia
2014-03-12 21:39 ` Sergei Shtylyov [this message]
2014-03-12 21:39 ` Sergei Shtylyov
2014-03-12 21:39 ` Sergei Shtylyov
2014-03-12 21:29 ` Ezequiel Garcia
2014-03-12 21:29 ` Ezequiel Garcia
2014-03-12 21:29 ` Ezequiel Garcia
2014-03-12 15:16 ` [PATCH 5/6] ARM: mvebu: Enable NAND controller in Armada 385-DB Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` [PATCH 6/6] clk: mvebu: Update binding documentation for the core divider clock Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-12 15:16 ` Ezequiel Garcia
2014-03-13 19:19 ` [PATCH 0/6] Armada 380 NAND support Jason Cooper
2014-03-13 19:19 ` Jason Cooper
2014-03-13 19:19 ` Jason Cooper
2014-03-13 19:25 ` Ezequiel Garcia
2014-03-13 19:25 ` Ezequiel Garcia
2014-03-13 19:25 ` Ezequiel Garcia
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=5320D3FD.8010704@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=alior@marvell.com \
--cc=andrew@lunn.ch \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mturquette@linaro.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=seif@marvell.com \
--cc=tawfik@marvell.com \
--cc=thomas.petazzoni@free-electrons.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.