devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <florian@openwrt.org>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: netdev <netdev@vger.kernel.org>,
	"Sebastian Hesselbarth" <sebastian.hesselbarth@gmail.com>,
	"Gregory Clément" <gregory.clement@free-electrons.com>,
	"Ezequiel Garcia" <ezequiel.garcia@free-electrons.com>,
	"Lior Amsalem" <alior@marvell.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"grant.likely" <grant.likely@secretlab.ca>,
	afleming@freescale.com
Subject: Re: Fixed PHY Device Tree usage?
Date: Fri, 12 Jul 2013 13:05:59 +0100	[thread overview]
Message-ID: <CAGVrzcax7gWCbdDKLdDjQDV_fOsShh+VZ9ODKO2KUBPm-zQgpQ@mail.gmail.com> (raw)
In-Reply-To: <20130712135612.0f230c1d@skate>

Hello Thomas,

2013/7/12 Thomas Petazzoni <thomas.petazzoni@free-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

  reply	other threads:[~2013-07-12 12:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130709183312.6c4d052d@skate>
     [not found] ` <CAGVrzcZ7ZLSDy5sTUR_XuSAUH=5q8ddiXx5n1y680WwGrdFfTw@mail.gmail.com>
2013-07-09 18:02   ` Fixed PHY Device Tree usage? Florian Fainelli
2013-07-10 16:22     ` Thomas Petazzoni
2013-07-10 16:29       ` Florian Fainelli
2013-07-10 16:39         ` Thomas Petazzoni
2013-07-10 17:23           ` Florian Fainelli
2013-07-12 11:56             ` Thomas Petazzoni
2013-07-12 12:05               ` Florian Fainelli [this message]
2013-07-12 13:04                 ` Thomas Petazzoni
2013-07-12 22:44             ` Grant Likely
2013-07-12 23:29               ` Florian Fainelli
2013-07-13 17:02               ` Thomas Petazzoni

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=CAGVrzcax7gWCbdDKLdDjQDV_fOsShh+VZ9ODKO2KUBPm-zQgpQ@mail.gmail.com \
    --to=florian@openwrt.org \
    --cc=afleming@freescale.com \
    --cc=alior@marvell.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=grant.likely@secretlab.ca \
    --cc=gregory.clement@free-electrons.com \
    --cc=netdev@vger.kernel.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=thomas.petazzoni@free-electrons.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).