linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sergei.shtylyov@cogentembedded.com (Sergei Shtylyov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3+1 5/5] ARM: DT: STi: STiH416: Add DT node for MiPHY365x
Date: Sun, 20 Jul 2014 21:56:24 +0400	[thread overview]
Message-ID: <53CC02C8.4010507@cogentembedded.com> (raw)
In-Reply-To: <20140714075835.GJ2954@lee--X1>

Hello.

On 07/14/2014 11:58 AM, 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 at fe382000 {
>>> +			phy_port0: port at 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.

    Yeah, I don't see why you need them if you don't refer to them anywhere.

>> 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.

    Good point...

> [...]

>>> +		miphy365x_phy: miphy365x at 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 at fe382000 {
>>> +				#phy-cells = <1>;

>>     If these are PHY devices, they should be named "phy", not "port".

> Then what do you call the parent node?

    Oh, don't ask me, it wasn't my idea to have PHY subnodes. :-)

WBR, Sergei

  reply	other threads:[~2014-07-20 17:56 UTC|newest]

Thread overview: 26+ 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
2014-07-20 17:56         ` Sergei Shtylyov [this message]
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

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=53CC02C8.4010507@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=linux-arm-kernel@lists.infradead.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).