linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Emil Medve <Emilian.Medve@Freescale.com>
To: Scott Wood <scottwood@Freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
Date: Wed, 30 Jul 2014 23:35:09 -0500	[thread overview]
Message-ID: <53D9C77D.8070203@Freescale.com> (raw)
In-Reply-To: <1406773805.29414.302.camel@snotra.buserror.net>

Hello Scott,


On 07/30/2014 09:30 PM, Scott Wood wrote:
> On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 07/29/2014 02:58 PM, Scott Wood wrote:
>>> On Mon, 2014-07-28 at 06:51 +0000, Emil Medve wrote:
>>>> Hello Scott,
>>>>
>>>>
>>>> Scott Wood <scottwood <at> freescale.com> writes:
>>>>> On Wed, 2014-07-16 at 15:17 -0500, Shruti Kanetkar wrote:
>>>>>> +			mdio <at> fd000 {
>>>>>> +				/* For 10g interfaces */
>>>>>> +				phy_xaui_slot1: xaui-phy <at> slot1 {
>>>>>> +					status = "disabled";
>>>>>> +					compatible = "ethernet-phy-ieee802.3-c45";
>>>>>> +					reg = <0x7>; /* default switch setting on slot1 of AMC2PEX */
>>>>>> +				};
>>>>>
>>>>> Why xaui-phy and not ethernet-phy?
>>>>>
>>>>> As for the device_type discussion from v1, there is a generic binding
>>>>> that says device_type "should" be ethernet-phy.
>>>>
>>>> I have no strong feelings about this and we can use ethernet-phy, but:
>>>>
>>>> 1. The binding is old/stale (?) as it still uses device_type and the kernel
>>>> doesn't seem to use anymore the device_type for PHY(s)
>>>
>>> Yes.
>>>
>>>> 2. The binding asks "ethernet-phy" for the device_type property, not for the
>>>> name. As such TBI PHY(s) use (upstream) the tbi-phy@ node name
>>>
>>> It shows ethernet-phy as the name in the example.  ePAPR urges generic
>>> node names (this was also a recommendation for IEEE1275), and has
>>> ethernet-phy on the preferred list.  Is a xaui-phy not an ethernet phy?
>>
>> So you thinking somebody should cleanup all the sgmii-phy and tbi-phy
>> node names, huh?
> 
> No, I was just wondering why we're adding yet another name, and whether
> there's any value in it.

That's fair. We'll just use ethernet-phy

>> It seems that a number of tbi-phy instances slipped by you:
>>
>> 1be62c6 powerpc/mpc85xx: Add BSC9132 QDS Support
>> bf57aeb powerpc/85xx: add the P1020RDB-PD DTS support
>> 8a6be2b powerpc/85xx: Add TWR-P1025 board support
> 
> tbi-phy is existing practice.  xaui-phy isn't.
> 
>>>>>> +			mdio0: mdio <at> fc000 {
>>>>>> +			};
>>>>>
>>>>> Why is the empty node needed?
>>>>
>>>> For the label
>>>
>>> For mdio-parent-bus, or is there some other dts layer that makes this
>>> node non-empty?
>>
>> 'powerpc/corenet: Create the dts components for the DPAA FMan' -
>> http://patchwork.ozlabs.org/patch/370872
> 
> Why does this patch define the mdio0 label for mdio@e1120, but not
> define a label for any other node?

Only MDIO controllers that are pinned out have these labels. Only pinned
out MDIO(s) are capable of controlling external PHY(s) via these board
level MDIO buses

>>  and 'powerpc/corenet: Add DPAA
>> FMan support to the SoC device tree(s)' -
>> http://patchwork.ozlabs.org/patch/370868 add content to said node
> 
> This one adds content to some mdio nodes, none of which are mdio@fc000
> or &mdio0.

This patch adds the SoC level PHY(s), which in this case are just TBI
PHY(s): i.e. no FMan v2 10 Gb/s MDIO or FMan v3 standalone MDIO devices.
Also the labels become relevant only at board level to connect the MDIO
buses to their corresponding MDIO controllers


Cheers,

  reply	other threads:[~2014-07-31  4:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-16 20:17 [PATCH v2 1/7] dt: Introduce the FMan 10 Gb/s MDIO binding Shruti Kanetkar
2014-07-16 20:17 ` [PATCH v2 2/7] net/fsl_pq_mdio: Document supported compatibles Shruti Kanetkar
2014-07-16 20:17 ` [PATCH v2 3/7] powerpc/corenet: Create the dts components for the DPAA FMan Shruti Kanetkar
2014-07-21 22:13   ` Scott Wood
2014-07-16 20:17 ` [PATCH v2 4/7] powerpc/corenet: Add DPAA FMan support to the SoC device tree(s) Shruti Kanetkar
2014-07-16 20:17 ` [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board " Shruti Kanetkar
2014-07-21 22:45   ` Scott Wood
2014-07-28  6:51     ` Emil Medve
2014-07-29 19:58       ` Scott Wood
2014-07-30 21:52         ` Emil Medve
2014-07-31  2:30           ` Scott Wood
2014-07-31  4:35             ` Emil Medve [this message]
2014-07-31  5:28               ` Scott Wood
2014-07-31  5:48                 ` Emil Medve
2014-07-31 18:30                   ` Scott Wood
2014-07-31 18:49                     ` Emil Medve
2014-08-13  8:44                     ` Shaohui Xie
2014-07-16 20:17 ` [PATCH v2 6/7] powerpc/corenet: Enable muxing MDIO buses via GPIO Shruti Kanetkar
2014-07-16 20:17 ` [PATCH v2 7/7] powerpc/corenet: Enable muxing MDIO buses via FPGA Shruti Kanetkar
2014-07-25  3:11 ` [PATCH v2 1/7] dt: Introduce the FMan 10 Gb/s MDIO binding Shaohui Xie
2014-07-25 19:54   ` Scott Wood
2014-07-26  8:17     ` Emil Medve
2014-07-25 20:00   ` Emil Medve

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=53D9C77D.8070203@Freescale.com \
    --to=emilian.medve@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@Freescale.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;
as well as URLs for NNTP newsgroup(s).