From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Florian Fainelli <florian@openwrt.org>
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@secretlab.ca, afleming@freescale.com
Subject: Re: Fixed PHY Device Tree usage?
Date: Wed, 10 Jul 2013 18:39:51 +0200 [thread overview]
Message-ID: <20130710183951.09a0bcea@skate> (raw)
In-Reply-To: <CAGVrzcbt302tTM3pprnhJz7YykUzcW=XSMCr_W=m1zWiVBX8kw@mail.gmail.com>
Dear Florian Fainelli,
On Wed, 10 Jul 2013 17:29:44 +0100, Florian Fainelli wrote:
> > Should we have something like:
> >
> > mdio-fixed {
> > compatible = "generic,mdio-fixed";
> > phy0: ethernet-phy@0 {
> > ... all the properties you listed ...
> > ... maybe the "id" property is not needed
> > because of the phandle ...
>
> In the "fixed-phy" terminology "id" is unfortunately ambiguous, the
> driver internally uses "phy_id" which is nothing more than a PHY
> address, but it also supports being assigned an "id" as in
> Identification register 2 & 3. I was refering to the identification
> register by "id".
Hum, but your "id" property contained a string, so I'm not sure how it
would fit in Identification register 2 and 3. Am I missing something
obvious here? Maybe you wanted to have:
id = <0xdeadbeef>;
which would make the "emulated" PHY return 0xdeadbeef as its PHY ID
when reading those identification registers.
> > };
> >
> > phy1: ethernet-phy@1 {
> > ... all the properties you listed ...
> > ... maybe the "id" property is not needed
> > because of the phandle ...
> > };
> > };
> >
> > soc {
> > ethernet@0 {
> > phy = <&phy0>;
> > ...
> > };
> >
> > ethernet@1 {
> > phy = <&phy1>;
> > ...
> > };
> > };
> >
> > or do you have in mind another representation?
>
> Not really this is more or less what I had in mind. I am wondering
> whether we should really declare the "mdio-fixed" node, or if we
> should not rather make the following:
>
> - declare all PHY nodes in the system as sub nodes of their belonging
> real hardware MDIO bus node
> - flag specific PHY nodes as "fixed" with a "fixed-link" boolean for instance
> - if we see that flag, make that specific PHY node bind to the
> fixed-phy driver instead
So the fixed PHY driver is going to travel through *all* nodes of the
DT, and whenever some random node has a "fixed" property, it's going to
say it corresponds to a fixed PHY? That doesn't seem like a good idea.
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?
> What do you think? I suspect someone might rightfully say that the
> "fixed-mdio" is not a real piece of hardware and is just a software
> concept. A PHY in the real world may very well have a fixed link
> speed/duplex/pause settings on the other end.
I agree that the mdio-fixed idea is clearly moving away from the
hardware representation. But see my question above: we need a way of
letting the fixed PHY driver know which DT nodes it should have a look
at. And just saying "those nodes will have property 'foo' is not
sufficient".
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-07-10 16:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-09 16:33 Fixed PHY Device Tree usage? Thomas Petazzoni
2013-07-09 16:44 ` Florian Fainelli
2013-07-09 18:02 ` Florian Fainelli
2013-07-10 16:22 ` Thomas Petazzoni
2013-07-10 16:29 ` Florian Fainelli
2013-07-10 16:39 ` Thomas Petazzoni [this message]
2013-07-10 17:23 ` Florian Fainelli
2013-07-12 11:56 ` Thomas Petazzoni
2013-07-12 12:05 ` Florian Fainelli
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=20130710183951.09a0bcea@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=afleming@freescale.com \
--cc=alior@marvell.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=florian@openwrt.org \
--cc=grant.likely@secretlab.ca \
--cc=gregory.clement@free-electrons.com \
--cc=netdev@vger.kernel.org \
--cc=sebastian.hesselbarth@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.