[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGVrzcax7gWCbdDKLdDjQDV_fOsShh+VZ9ODKO2KUBPm-zQgpQ@mail.gmail.com>
Date: Fri, 12 Jul 2013 13:05:59 +0100
From: Florian Fainelli <florian@...nwrt.org>
To: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc: netdev <netdev@...r.kernel.org>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Gregory Clément
<gregory.clement@...e-electrons.com>,
Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
Lior Amsalem <alior@...vell.com>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
"grant.likely" <grant.likely@...retlab.ca>, afleming@...escale.com
Subject: Re: Fixed PHY Device Tree usage?
Hello Thomas,
2013/7/12 Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>:
>> Why not? Since we are already have to scan the entire MDIO bus we are
>> attached to, when we encounter such a PHY node with the special
>> "fixed" properties, we just call fixed_phy_add() with the right
>> parameters and voila. Which is also the reason why I was suggesting to
>> put the "fixed" PHY nodes as sub-nodes of the real MDIO node such that
>> we have this logic only in one place.
>
> I'm still not sure to understand you here. Scanning the *entire* DT
> tree and consider all nodes having a property named "fixed" as fixed
> PHYs is definitely not acceptable. So I suppose you have a different
> idea, but I'm still not getting it. Where in the DT would the fixed PHY
> driver start looking for fixed PHYs ?
I am talking about scanning the MDIO bus DT nodes, not the entire DT.
That job is already done by of_mdiobus_probe() to register PHY
devices, so having a central point where the knowledge of how to treat
PHY deivces could be here I guess.
>
>> > So that's really what I was asking: how is the fixed PHY driver going
>> > to know which DT nodes to look at. Is it a platform_driver, where the
>> > corresponding DT node has sub-nodes? Is it something else? Or a
>> > specific compatible string?
>>
>> Without DT at play here, the usual way to register a fixed PHY is:
>>
>> 1) make your arch code or whatever runs before the fixed MDIO bus
>> probing to call fixed_phy_add() with the expected parameters
>> 2) when your ethernet driver probes its PHY devices, format the phy
>> name to be bound to the fixed bus with the expected address by then
>> the fixed MDIO bus would have already been probed and would find the
>> fixed PHY nodes because of the first step
>> 3) call of_phy_connect() from your driver to attach to the fixed PHY
>
> Right, but that's still doesn't answer the question of how the fixed
> PHY driver discovers from the DT which PHYs to instantiate.
>
> For example, we would probably have something:
>
> phys {
> phy0: phy@0 {
> ... PHY properties ...
> };
> phy1: phy@1 {
> ... PHY properties ...
> };
> };
>
> soc {
> ethernet@0 {
> compatible = "...";
> ...
> phy = <&phy0>;
> };
> ethernet@1 {
> compatible = "...";
> ...
> phy = <&phy1>;
> };
> };
>
> How will the fixed PHY driver know that it should instantiate
> phy@0 and phy@1 as PHY devices?
Well either we go with some specific compatible property like
"ethernet-phy-fixed" for instance, or we simply add a boolean property
to the node, so a fixed PHY would either look like this:
phy {
compatible = "linux,ethernet-phy-fixed";
speed = <1000>;
duplex = <1>;
pause;
asym-pause;
};
or respectively, something like this:
phy {
fixed;
speed = <1000>;
duplex = <1>;
pause;
asym-pause;
};
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists