From: Florian Fainelli <f.fainelli@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>, netdev <netdev@vger.kernel.org>
Subject: Re: [RFC PATCH net-next 2/2] phy: fixed-phy: Allow DT description of an MDIO bus and PHYs.
Date: Fri, 11 Mar 2016 15:30:56 -0800 [thread overview]
Message-ID: <56E35530.6000009@gmail.com> (raw)
In-Reply-To: <1457737726-23907-3-git-send-email-andrew@lunn.ch>
On 11/03/16 15:08, Andrew Lunn wrote:
> Not all MACs are connected to PHYs. They can for example be connected
> to a switch. Using the fixed PHY properties with the MAC is possible,
> but requires support in the MAC. It is however simpler to make use of
> the phy-handle property to point to a PHY. To achieve this, the PHY
> must be in the device tree.
>
> Allow virtual MDIO busses to be represented in device tree, which
> contains virtual fixed-phys.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> .../devicetree/bindings/net/fixed-link.txt | 39 +++++++
> drivers/net/phy/fixed_phy.c | 122 ++++++++++++++++++++-
> 2 files changed, 157 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt
> index ec5d889fe3d8..2a22b92007fa 100644
> --- a/Documentation/devicetree/bindings/net/fixed-link.txt
> +++ b/Documentation/devicetree/bindings/net/fixed-link.txt
> @@ -52,3 +52,42 @@ ethernet@1 {
> };
> ...
> };
> +
> +Fixed link PHYs on an MDIO bus
> +------------------------------
> +
> +An alternative to using the fixed link properties in the MAC is to
> +define an MDIO bus with a number of fixed link phys on it.
> +
> +Required properties:
> +- compatible = ""linux,mdio-fixed-phy";
One too many " here.
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +
> +Child nodes represent PHYs on this mdio bus. Standard properties for
> +fixed links, 'speed', 'full-duplex', 'pause', 'asym-pause',
> +'link-gpios', as defined above are used. Additionally a 'reg' property
> +is required for the address of the PHY on the bus. This should be of
> +value 0 to 31.
This is a virtual bus, the only limitation is because we re-use to the
maximum permission extent the real MDIO bus code, and this is putting a
SW constraint on something that does not have one here.
> +
> +Example
> +-------
> +
> +mdio {
> + compatible = "linux,mdio-fixed-phy";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy0: phy@0 {
> + reg = <0>;
> + speed = <1000>;
> + pause;
> + link-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
> + };
> +
> + phy1: phy@8 {
> + reg = <8>;
> + speed = <100>;
> + full-duplex;
> + };
The 'fixed-link' property, although it suffers from one basic issue
which is that it is placed on the consumer of it (e.g: an Ethernet MAC
Device Tree node) while being a two-headed snake (you actually describe
a data-pipe with a fixed-link) is not quite perfect, but this does not
seem to look any better.
One thing that Thomas solved nicely was avoid the need for allocating an
address on the virtual MDIO bus, but this is coming back here, which
does not seem needed except for correctness wrt. how real MDIO buses.
--
Florian
next prev parent reply other threads:[~2016-03-11 23:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-11 23:08 [RFC PATCH net-next 0/2] DT MDIO bus of fixed phys Andrew Lunn
2016-03-11 23:08 ` [RFC PATCH net-next 1/2] of: of_mdio: Factor out fixed-link parsing Andrew Lunn
2016-03-11 23:08 ` [RFC PATCH net-next 2/2] phy: fixed-phy: Allow DT description of an MDIO bus and PHYs Andrew Lunn
2016-03-11 23:30 ` Florian Fainelli [this message]
2016-03-12 0:05 ` Andrew Lunn
2016-03-12 17:32 ` Andrew Lunn
2016-03-11 23:26 ` [RFC PATCH net-next 0/2] DT MDIO bus of fixed phys Florian Fainelli
2016-03-11 23:36 ` Andrew Lunn
2016-03-11 23:38 ` Florian Fainelli
2016-03-12 0:12 ` Andrew Lunn
2016-03-14 16:51 ` Florian Fainelli
2016-03-14 19:04 ` Andrew Lunn
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=56E35530.6000009@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=netdev@vger.kernel.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 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).