[PATCH net-next 02/28] dt-bindings: net: fman: Add additional interface properties

[Sean Anderson]

At the moment, MEMACs are configured almost completely based on the
phy-connection-type. That is, if the phy interface is RGMII, it assumed
that RGMII is supported. For some interfaces, it is assumed that the
RCW/bootloader has set up the SerDes properly. The actual link state is
never reported.

To address these shortcomings, the driver will need additional
information. First, it needs to know how to access the PCS/PMAs (in
order to configure them and get the link status). The SGMII PCS/PMA is
the only currently-described PCS/PMA. Add the XFI and QSGMII PCS/PMAs as
well. The XFI (and 1GBase-KR) PCS/PMA is a c45 "phy" which sits on the
same MDIO bus as SGMII PCS/PMA. By default they will have conflicting
addresses, but they are also not enabled at the same time by default.
Therefore, we can let the default address for the XFI PCS/PMA be the
same as for SGMII. This will allow for backwards-compatibility.

QSGMII, however, cannot work with the current binding. This is because
the QSGMII PCS/PMAs are only present on one MAC's MDIO bus. At the
moment this is worked around by having every MAC write to the PCS/PMA
addresses (without checking if they are present). This only works if
each MAC has the same configuration, and only if we don't need to know
the status. Because the QSGMII PCS/PMA will typically be located on a
different MDIO bus than the MAC's SGMII PCS/PMA, there is no fallback
for the QSGMII PCS/PMA.

MEMACs (across all SoCs) support the following protocols:

- MII
- RGMII
- SGMII, 1000Base-X, and 1000Base-KX
- 2500Base-X (aka 2.5G SGMII)
- QSGMII
- 10GBase-R (aka XFI) and 10GBase-KR
- XAUI and HiGig

Each line documents a set of orthogonal protocols (e.g. XAUI is
supported if and only if HiGig is supported). Additionally,

- XAUI implies support for 10GBase-R
- 10GBase-R is supported if and only if RGMII is not supported
- 2500Base-X implies support for 1000Base-X
- MII implies support for RGMII

To switch between different protocols, we must reconfigure the SerDes.
This is done by using the standard phys property. We can also use it to
validate whether different protocols are supported (e.g. using
phy_validate). This will work for serial protocols, but not RGMII or
MII. Additionally, we still need to be compatible when there is no
SerDes.

While we can detect 10G support by examining the port speed (as set by
fsl,fman-10g-port), we cannot determine support for any of the other
protocols based on the existing binding. In fact, the binding works
against us in some respects, because pcsphy-handle is required even if
there is no possible PCS/PMA for that MAC. To allow for backwards-
compatibility, we use a boolean-style property for RGMII (instead of
presence/absence-style). When the property for RGMII is missing, we will
assume that it is supported. The exception is MII, since no existing
device trees use it (as far as I could tell).

Unfortunately, QSGMII support will be broken for old device trees. There
is nothing we can do about this because of the PCS/PMA situation (as
described above).

Signed-off-by: Sean Anderson <sean.anderson at seco.com>
---

 .../devicetree/bindings/net/fsl-fman.txt      | 49 +++++++++++++++++--
 1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt
index 801efc7d6818..25c7288e1db2 100644
--- a/Documentation/devicetree/bindings/net/fsl-fman.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fman.txt
@@ -322,10 +322,50 @@ PROPERTIES
 		Value type: <phandle>
 		Definition: A phandle for 1EEE1588 timer.
 
+- phys
+		Usage optional for "fsl,fman-memac" MACs
+		Value type: <prop-encoded-array>
+		Definition: A phandle for the SerDes lanes which should be
+		used. This property is required if a pcsphy-handle is
+		specified.
+
+- phy-names
+		Usage optional for "fsl,fman-memac" MACs
+		Value type: <stringlist>
+		Definition: Should be "serdes". Must be present if phys is.
+
 - pcsphy-handle
+		Usage optional for "fsl,fman-memac" MACs
+		Value type: <prop-encoded-array>
+		Definition: An array of phandles for PCS/PMA devices. Without a
+		pcs-names property (see below) this should contain a phandle
+		referencing the SGMII PCS/PMA. This property may be absent if
+		no serial interfaces are supported.
+
+- pcs-names
+		Usage optional for "fsl,fman-memac" MACs
+		Value type: <stringlist>
+		Definition: The type of each PCS/PMA, corresponding to
+		pcsphy-handle. Each value may be one of
+		- "sgmii"
+		- "qsgmii"
+		- "xfi"
+		If "xfi" is absent, it will default to the value of "sgmii". If
+		this property is absent, the first phandle in pcsphy-handle
+		will be assumed to be "sgmii".
+
+- rgmii
 		Usage required for "fsl,fman-memac" MACs
-		Value type: <phandle>
-		Definition: A phandle for pcsphy.
+		Value type: <u32>
+		Definition: This property should be 1 if RGMII is supported and
+		0 otherwise.
+
+- mii
+		Usage optional for "fsl,fman-memac" MACs
+		Value type: <empty>
+		Definition: This property should be present if MII is
+		supported. rgmii must be enabled for this property to be
+		effective.
 
 - tbi-handle
 		Usage required for "fsl,fman-dtsec" MACs
@@ -446,8 +486,9 @@ For internal PHY device on internal mdio bus, a PHY node should be created.
 See the definition of the PHY node in booting-without-of.txt for an
 example of how to define a PHY (Internal PHY has no interrupt line).
 - For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY.
-- For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS PHY,
-  PCS PHY addr must be '0'.
+- For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS PHY.
+  The PCS PHY address should correspond to the value of the appropriate
+  MDEV_PORT.
 
 EXAMPLE
 
-- 
2.35.1.1320.gc452695387.dirty