From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 3/4] of: provide a binding for fixed link PHYs
Date: Wed, 5 Mar 2014 10:24:14 +0100 [thread overview]
Message-ID: <20140305102414.111f856e@skate> (raw)
In-Reply-To: <CAGVrzcbHwxtgUfC4+u_3wszcmEYpz8Y7gu13xJy6TbT6fgR1sg@mail.gmail.com>
Dear Florian Fainelli,
On Tue, 4 Mar 2014 12:58:41 -0800, Florian Fainelli wrote:
> What I like about this new binding is that we could place the
> 'fixed-link' related properties in e.g: a SPI slave node, and have the
> Ethernet MAC be pointed at it by a phandle to tell it: look this is
> your PHY, it might not be one you could address on a MDIO bus, so I
> have been providing additional properties to help you with the link
> configuration.
>
> One thing that needs to be addressed in this patch is how to deal with
> the existing 5-digit fixed-link, something that sounds fairly easy and
> which would not require changing the callers of of_phy_connect_fixed()
> is to do the following:
I am not sure to understand "would not require changing the callers of
of_phy_connect_fixed()". This function is precisely introduced by the
patch set, so how would we need to "change the callers" ? Maybe you're
making a confusion with the existing of_phy_connect_fixed_link(), which
is used by network drivers to create a PHY using the old-style
fixed-link = <5 digits> binding ?
> - of_phy_is_fixed_link() needs to look for *all* required compatible
> properties of the new binding to give an accurate verdict on the
> nature of the PHY (to avoid false positives as mentioned in PATCH 4),
Hum?
The false positive problem only exists if you want to automatically
instantiate the fixed PHYs, as I proposed in a patch as a reply to my
series. And checking for *all* required properties does not make the
problem better: you could very well have other nodes in the tree that
have a "fixed-link" and a "speed" property, for example.
> and it also needs to look for the 5-digit fixed-link property and
> ensure the property is 5-digits long if existing
I don't understand how this could work. The of_phy_is_fixed_link()
function is meant to take as argument a Device Tree node that describes
a fixed PHY, using the new proposed DT binding for fixed PHYs.
The old 'fixed-link' binding has the fixed-link property as part of the
Ethernet node itself.
So I don't really see how a sane function could check both.
> - of_phy_register_fixed_link() needs to also parse the old 5-digit
> fixed-link property, most likely just copy-pasting what
> arch/powerpc/sysdev/fsl_soc.c::of_add_fixed_phys does with the
> property endian-swapping (as this code is for PowerPC)
>
> Then we can deal with how to make that semi-automatic for the new
> binding users to make it smoother to use a regular or "fixed PHY"
> device.
I still don't understand. With the old binding, the "fixed-link"
property is within some random Ethernet node, and there is no way for
us to find out whether a given node having a "fixed-link" property
corresponds to a fixed PHY, or something completely unrelated.
So to conclude, I'm sorry, but I didn't understand at all what you
meant to say here, so I'm completely puzzled about what your
suggestions are.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Lior Amsalem <alior@marvell.com>,
Gregory Clement <gregory.clement@free-electrons.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Christian Gmeiner <christian.gmeiner@gmail.com>,
Grant Likely <grant.likely@linaro.org>
Subject: Re: [PATCHv3 3/4] of: provide a binding for fixed link PHYs
Date: Wed, 5 Mar 2014 10:24:14 +0100 [thread overview]
Message-ID: <20140305102414.111f856e@skate> (raw)
In-Reply-To: <CAGVrzcbHwxtgUfC4+u_3wszcmEYpz8Y7gu13xJy6TbT6fgR1sg@mail.gmail.com>
Dear Florian Fainelli,
On Tue, 4 Mar 2014 12:58:41 -0800, Florian Fainelli wrote:
> What I like about this new binding is that we could place the
> 'fixed-link' related properties in e.g: a SPI slave node, and have the
> Ethernet MAC be pointed at it by a phandle to tell it: look this is
> your PHY, it might not be one you could address on a MDIO bus, so I
> have been providing additional properties to help you with the link
> configuration.
>
> One thing that needs to be addressed in this patch is how to deal with
> the existing 5-digit fixed-link, something that sounds fairly easy and
> which would not require changing the callers of of_phy_connect_fixed()
> is to do the following:
I am not sure to understand "would not require changing the callers of
of_phy_connect_fixed()". This function is precisely introduced by the
patch set, so how would we need to "change the callers" ? Maybe you're
making a confusion with the existing of_phy_connect_fixed_link(), which
is used by network drivers to create a PHY using the old-style
fixed-link = <5 digits> binding ?
> - of_phy_is_fixed_link() needs to look for *all* required compatible
> properties of the new binding to give an accurate verdict on the
> nature of the PHY (to avoid false positives as mentioned in PATCH 4),
Hum?
The false positive problem only exists if you want to automatically
instantiate the fixed PHYs, as I proposed in a patch as a reply to my
series. And checking for *all* required properties does not make the
problem better: you could very well have other nodes in the tree that
have a "fixed-link" and a "speed" property, for example.
> and it also needs to look for the 5-digit fixed-link property and
> ensure the property is 5-digits long if existing
I don't understand how this could work. The of_phy_is_fixed_link()
function is meant to take as argument a Device Tree node that describes
a fixed PHY, using the new proposed DT binding for fixed PHYs.
The old 'fixed-link' binding has the fixed-link property as part of the
Ethernet node itself.
So I don't really see how a sane function could check both.
> - of_phy_register_fixed_link() needs to also parse the old 5-digit
> fixed-link property, most likely just copy-pasting what
> arch/powerpc/sysdev/fsl_soc.c::of_add_fixed_phys does with the
> property endian-swapping (as this code is for PowerPC)
>
> Then we can deal with how to make that semi-automatic for the new
> binding users to make it smoother to use a regular or "fixed PHY"
> device.
I still don't understand. With the old binding, the "fixed-link"
property is within some random Ethernet node, and there is no way for
us to find out whether a given node having a "fixed-link" property
corresponds to a fixed PHY, or something completely unrelated.
So to conclude, I'm sorry, but I didn't understand at all what you
meant to say here, so I'm completely puzzled about what your
suggestions are.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-03-05 9:24 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 10:58 [PATCHv3 0/4] Add DT support for fixed PHYs Thomas Petazzoni
2014-03-04 10:58 ` Thomas Petazzoni
2014-03-04 10:58 ` [PATCHv3 1/4] net: phy: decouple PHY id and PHY address in fixed PHY driver Thomas Petazzoni
2014-03-04 10:58 ` Thomas Petazzoni
2014-03-04 18:43 ` Florian Fainelli
2014-03-04 18:43 ` Florian Fainelli
2014-03-04 19:04 ` Thomas Petazzoni
2014-03-04 19:04 ` Thomas Petazzoni
2014-03-08 4:09 ` Grant Likely
2014-03-08 4:09 ` Grant Likely
2014-03-04 10:58 ` [PATCHv3 2/4] net: phy: extend fixed driver with fixed_phy_register() Thomas Petazzoni
2014-03-04 10:58 ` Thomas Petazzoni
2014-03-04 18:44 ` Florian Fainelli
2014-03-04 18:44 ` Florian Fainelli
2014-03-08 4:21 ` Grant Likely
2014-03-08 4:21 ` Grant Likely
2014-03-04 10:58 ` [PATCHv3 3/4] of: provide a binding for fixed link PHYs Thomas Petazzoni
2014-03-04 10:58 ` Thomas Petazzoni
2014-03-04 20:58 ` Florian Fainelli
2014-03-04 20:58 ` Florian Fainelli
2014-03-05 9:24 ` Thomas Petazzoni [this message]
2014-03-05 9:24 ` Thomas Petazzoni
2014-03-05 17:33 ` Florian Fainelli
2014-03-05 17:33 ` Florian Fainelli
2014-03-08 5:50 ` Grant Likely
2014-03-08 5:50 ` Grant Likely
2014-05-15 13:39 ` Thomas Petazzoni
2014-05-15 13:39 ` Thomas Petazzoni
2014-05-15 16:54 ` Florian Fainelli
2014-05-15 16:54 ` Florian Fainelli
2014-03-04 10:58 ` [PATCHv3 4/4] net: mvneta: add support for fixed links Thomas Petazzoni
2014-03-04 10:58 ` Thomas Petazzoni
2014-03-04 11:30 ` Thomas Petazzoni
2014-03-04 11:30 ` Thomas Petazzoni
2014-03-08 5:56 ` Grant Likely
2014-03-08 5:56 ` Grant Likely
2014-03-04 18:09 ` [PATCHv3 0/4] Add DT support for fixed PHYs Sergei Shtylyov
2014-03-04 18:09 ` Sergei Shtylyov
[not found] <1393930704-24374-1-git-send-email-thomas.petazzoni@ free-electrons.com>
[not found] ` <1393930704-24374-2-git-send-email-thomas.petazzoni@ free-electrons.com>
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=20140305102414.111f856e@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.