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,
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
