From: Lee Jones <lee.jones@linaro.org>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kishon@ti.com, kernel@stlinux.com
Subject: Re: [PATCH v3+1 5/5] ARM: DT: STi: STiH416: Add DT node for MiPHY365x
Date: Mon, 14 Jul 2014 08:58:35 +0100 [thread overview]
Message-ID: <20140714075835.GJ2954@lee--X1> (raw)
In-Reply-To: <53C0819E.4000202@cogentembedded.com>
On Sat, 12 Jul 2014, Sergei Shtylyov wrote:
> Hello.
>
> On 07/11/2014 03:54 PM, Lee Jones wrote:
>
> >The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> >devices. It has 2 ports which it can use for either; both SATA, both
> >PCIe or one of each in any configuration.
>
> >Acked-by: Mark Rutland <mark.rutland@arm.com>
> >Acked-by: Alexandre Torgue <alexandre.torgue@st.com>
> >Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> >diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
> >index 4e2df66..c3c2ac6 100644
> >--- a/arch/arm/boot/dts/stih416-b2020.dts
> >+++ b/arch/arm/boot/dts/stih416-b2020.dts
> >@@ -12,4 +12,16 @@
> > / {
> > model = "STiH416 B2020";
> > compatible = "st,stih416-b2020", "st,stih416";
> >+
> >+ soc {
> >+ miphy365x_phy: miphy365x@fe382000 {
> >+ phy_port0: port@fe382000 {
>
> I don't understand why are you creating the duplicate labels;
> doesn't 'dtc' complain about them?
I've never seen dtc complain about this:
DTC arch/arm/boot/dts/dra72-evm.dtb
DTC arch/arm/boot/dts/stih407-b2120.dtb
DTC arch/arm/boot/dts/stih415-b2000.dtb
DTC arch/arm/boot/dts/stih415-b2020.dtb
DTC arch/arm/boot/dts/stih416-b2000.dtb
DTC arch/arm/boot/dts/stih416-b2020.dtb
DTC arch/arm/boot/dts/stih416-b2020e.dtb
DTC arch/arm/boot/dts/armada-375-db.dtb
Probably because they're not actually 'duplicate' per say. Rather
they are the same node split into different files. I can remove the
labels if required though.
> You could instead refer to them
> as:
>
> &miphy365x_phy {
> };
I dislike this formatting. I find it convolutes the hierarchical
structure and makes DTS (and some DTSI) files hard to read i.e hides
parenthood etc.
[...]
> >+ miphy365x_phy: miphy365x@fe382000 {
>
> The ePAPR standard [1] says:
>
> The name of a node should be somewhat generic, reflecting the
> function of the device and not its precise programming model.
Good point. Will change to 'phy'.
> >+ compatible = "st,miphy365x-phy";
> >+ st,syscfg = <&syscfg_rear>;
> >+ #address-cells = <1>;
> >+ #size-cells = <1>;
> >+ ranges;
> >+
> >+ phy_port0: port@fe382000 {
> >+ #phy-cells = <1>;
>
> If these are PHY devices, they should be named "phy", not "port".
Then what do you call the parent node?
I see it as:
phy {
port {
};
};
Or
phy {
channel {
};
};
What does Kishon think?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-07-14 7:58 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-09 11:41 [PATCH v3 0/5] phy: miphy365x: Introduce support for MiPHY365x Lee Jones
2014-07-09 11:41 ` [PATCH v3 1/5] phy: miphy365x: Add Device Tree bindings for the MiPHY365x Lee Jones
2014-07-09 14:30 ` Gabriel Fernandez
2014-07-09 16:37 ` Lee Jones
2014-07-10 9:09 ` [PATCH v3+1 " Lee Jones
2014-07-09 11:41 ` [PATCH v3 2/5] phy: miphy365x: Add MiPHY365x header file for DT x Driver defines Lee Jones
2014-07-11 9:07 ` Gabriel Fernandez
2014-07-11 9:33 ` Lee Jones
2014-07-09 11:41 ` [PATCH v3 3/5] phy: miphy365x: Provide support for the MiPHY356x Generic PHY Lee Jones
2014-07-11 9:07 ` Gabriel Fernandez
2014-07-09 11:41 ` [PATCH v3 4/5] phy: miphy365x: Represent each PHY channel as a DT subnode Lee Jones
2014-07-09 11:41 ` [PATCH v3 5/5] ARM: DT: STi: STiH416: Add DT node for MiPHY365x Lee Jones
2014-07-11 11:54 ` [PATCH v3+1 " Lee Jones
2014-07-12 0:30 ` Sergei Shtylyov
2014-07-14 7:58 ` Lee Jones [this message]
2014-07-20 17:56 ` Sergei Shtylyov
2014-07-22 9:02 ` [STLinux Kernel] " Maxime Coquelin
2014-07-09 14:52 ` [PATCH v3 0/5] phy: miphy365x: Introduce support " Kishon Vijay Abraham I
2014-07-10 15:35 ` [STLinux Kernel] " Peter Griffin
2014-07-11 10:31 ` Lee Jones
2014-07-11 11:05 ` Peter Griffin
2014-07-11 11:13 ` Kishon Vijay Abraham I
2014-07-11 11:34 ` Lee Jones
2014-07-11 11:30 ` Lee Jones
2014-07-11 11:33 ` Maxime Coquelin
2014-07-11 11:38 ` Lee Jones
[not found] ` <20140721062805.GA8781@uda0393678>
2014-07-21 7:39 ` Lee Jones
2014-07-22 7:23 ` Kishon Vijay Abraham I
2014-07-22 7:28 ` [STLinux Kernel] " Maxime Coquelin
2014-07-23 7:58 ` Maxime Coquelin
2014-07-23 8:24 ` Kishon Vijay Abraham I
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=20140714075835.GJ2954@lee--X1 \
--to=lee.jones@linaro.org \
--cc=kernel@stlinux.com \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sergei.shtylyov@cogentembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox