[PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[Thomas Petazzoni]

Hello,

This set of patches is a new attempt at fixing the operation of the
mvneta driver when built as a module. For the record, the previous
attempt, merged in commit e3a8786c10e75903f1269474e21fe8cb49c3a670
('net: mvneta: fix usage as a module on RGMII configurations') caused
problems for all RGMII configurations.

In fact, it turned out that the MAC to PHY connection on the Armada XP
GP, which was described as using RGMII-ID according to its Device
Tree, is in fact a QSGMII connection. And the RGMII and QSGMII
configurations have to be handled in a different way in the driver,
because the SERDES configuration is different in those two cases.

So, this patch series fixes that by:

 * Adding minimal handling of a "qsgmii" connection type in the PHY
   layer. Mainly to make sure that a "qsgmii" phy-mode in the Device
   Tree is recognized, and handed over to the driver as
   PHY_INTERFACE_QSGMII.

 * Changing the mvneta driver to properly configure the RGMIIEn and
   PCSEn bits in the GMAC_CTRL_2 register, and configure the SERDES
   register, in the three possible cases: RGMII, SGMII and QSGMII.

 * Updating the Device Tree of the Armada XP GP board to reflect the
   fact that it uses a QSGMII MAC/PHY connection.

PATCH 1 and 2 would be merged by David Miller, through the net tree,
while PATCH 3 would be merged by the mach-mvebu maintainers, through
their tree and arm-soc.

This set of patches has been tested on:

 * Armada XP GP (four QSGMII interfaces)
 * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
 * Armada 370 Mirabox (two RGMII interfaces)

I've tested both the driver built-in, and compiled as a module.

Since the last attempt at fixing this was quite a fiasco, I'd like
this new attempt to be tested more widely before being applied. I'll
try to do some testing on other Armada boards I have, but independent
testing from other persons would also be appreciated.

Note that these patches apply after reverting the previous attempt,
obviously.

Thanks,

Thomas

Thomas Petazzoni (3):
  net: phy: add minimal support for QSGMII PHY
  net: mvneta: properly configure the MAC <-> PHY connection in all
    situations
  ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces

 Documentation/devicetree/bindings/net/ethernet.txt |  2 +-
 arch/arm/boot/dts/armada-xp-gp.dts                 |  8 +--
 drivers/net/ethernet/marvell/mvneta.c              | 73 ++++++++++------------
 include/linux/phy.h                                |  3 +
 4 files changed, 42 insertions(+), 44 deletions(-)

-- 
1.8.3.2

[PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[Thomas Petazzoni]

Hello,

This set of patches is a new attempt at fixing the operation of the
mvneta driver when built as a module. For the record, the previous
attempt, merged in commit e3a8786c10e75903f1269474e21fe8cb49c3a670
('net: mvneta: fix usage as a module on RGMII configurations') caused
problems for all RGMII configurations.

In fact, it turned out that the MAC to PHY connection on the Armada XP
GP, which was described as using RGMII-ID according to its Device
Tree, is in fact a QSGMII connection. And the RGMII and QSGMII
configurations have to be handled in a different way in the driver,
because the SERDES configuration is different in those two cases.

So, this patch series fixes that by:

 * Adding minimal handling of a "qsgmii" connection type in the PHY
   layer. Mainly to make sure that a "qsgmii" phy-mode in the Device
   Tree is recognized, and handed over to the driver as
   PHY_INTERFACE_QSGMII.

 * Changing the mvneta driver to properly configure the RGMIIEn and
   PCSEn bits in the GMAC_CTRL_2 register, and configure the SERDES
   register, in the three possible cases: RGMII, SGMII and QSGMII.

 * Updating the Device Tree of the Armada XP GP board to reflect the
   fact that it uses a QSGMII MAC/PHY connection.

PATCH 1 and 2 would be merged by David Miller, through the net tree,
while PATCH 3 would be merged by the mach-mvebu maintainers, through
their tree and arm-soc.

This set of patches has been tested on:

 * Armada XP GP (four QSGMII interfaces)
 * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
 * Armada 370 Mirabox (two RGMII interfaces)

I've tested both the driver built-in, and compiled as a module.

Since the last attempt at fixing this was quite a fiasco, I'd like
this new attempt to be tested more widely before being applied. I'll
try to do some testing on other Armada boards I have, but independent
testing from other persons would also be appreciated.

Note that these patches apply after reverting the previous attempt,
obviously.

Thanks,

Thomas

Thomas Petazzoni (3):
  net: phy: add minimal support for QSGMII PHY
  net: mvneta: properly configure the MAC <-> PHY connection in all
    situations
  ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces

 Documentation/devicetree/bindings/net/ethernet.txt |  2 +-
 arch/arm/boot/dts/armada-xp-gp.dts                 |  8 +--
 drivers/net/ethernet/marvell/mvneta.c              | 73 ++++++++++------------
 include/linux/phy.h                                |  3 +
 4 files changed, 42 insertions(+), 44 deletions(-)

-- 
1.8.3.2

[PATCH 1/3] net: phy: add minimal support for QSGMII PHY

[Thomas Petazzoni]

This commit adds the necessary definitions for the PHY layer to
recognize "qsgmii" as a valid PHY interface. A QSMII interface, as
defined at
http://en.wikipedia.org/wiki/Media_Independent_Interface#Quad_Serial_Gigabit_Media_Independent_Interface,
is "is a method of combining four SGMII lines into a 5Gbit/s
interface. QSGMII, like SGMII, uses LVDS signalling for the TX and RX
data and a single LVDS clock signal. QSGMII uses significantly fewer
signal lines than four SGMII busses."

This type of MAC <-> PHY connection might require special handling on
the MAC driver side, so it should be possible to express this type of
MAC <-> PHY connection, for example in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree@vger.kernel.org
---
 Documentation/devicetree/bindings/net/ethernet.txt | 2 +-
 include/linux/phy.h                                | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
index 9ecd43d..3fc3605 100644
--- a/Documentation/devicetree/bindings/net/ethernet.txt
+++ b/Documentation/devicetree/bindings/net/ethernet.txt
@@ -10,7 +10,7 @@ The following properties are common to the Ethernet controllers:
 - max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
   the maximum frame size (there's contradiction in ePAPR).
 - phy-mode: string, operation mode of the PHY interface; supported values are
-  "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
+  "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
   "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a de-facto
   standard property;
 - phy-connection-type: the same as "phy-mode" property but described in ePAPR;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 24126c4..4d0221f 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -75,6 +75,7 @@ typedef enum {
 	PHY_INTERFACE_MODE_SMII,
 	PHY_INTERFACE_MODE_XGMII,
 	PHY_INTERFACE_MODE_MOCA,
+	PHY_INTERFACE_MODE_QSGMII,
 	PHY_INTERFACE_MODE_MAX,
 } phy_interface_t;
 
@@ -116,6 +117,8 @@ static inline const char *phy_modes(phy_interface_t interface)
 		return "xgmii";
 	case PHY_INTERFACE_MODE_MOCA:
 		return "moca";
+	case PHY_INTERFACE_MODE_QSGMII:
+		return "qsgmii";
 	default:
 		return "unknown";
 	}
-- 
1.8.3.2

[PATCH 1/3] net: phy: add minimal support for QSGMII PHY

[Thomas Petazzoni]

This commit adds the necessary definitions for the PHY layer to
recognize "qsgmii" as a valid PHY interface. A QSMII interface, as
defined at
http://en.wikipedia.org/wiki/Media_Independent_Interface#Quad_Serial_Gigabit_Media_Independent_Interface,
is "is a method of combining four SGMII lines into a 5Gbit/s
interface. QSGMII, like SGMII, uses LVDS signalling for the TX and RX
data and a single LVDS clock signal. QSGMII uses significantly fewer
signal lines than four SGMII busses."

This type of MAC <-> PHY connection might require special handling on
the MAC driver side, so it should be possible to express this type of
MAC <-> PHY connection, for example in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree at vger.kernel.org
---
 Documentation/devicetree/bindings/net/ethernet.txt | 2 +-
 include/linux/phy.h                                | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
index 9ecd43d..3fc3605 100644
--- a/Documentation/devicetree/bindings/net/ethernet.txt
+++ b/Documentation/devicetree/bindings/net/ethernet.txt
@@ -10,7 +10,7 @@ The following properties are common to the Ethernet controllers:
 - max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
   the maximum frame size (there's contradiction in ePAPR).
 - phy-mode: string, operation mode of the PHY interface; supported values are
-  "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
+  "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
   "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a de-facto
   standard property;
 - phy-connection-type: the same as "phy-mode" property but described in ePAPR;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 24126c4..4d0221f 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -75,6 +75,7 @@ typedef enum {
 	PHY_INTERFACE_MODE_SMII,
 	PHY_INTERFACE_MODE_XGMII,
 	PHY_INTERFACE_MODE_MOCA,
+	PHY_INTERFACE_MODE_QSGMII,
 	PHY_INTERFACE_MODE_MAX,
 } phy_interface_t;
 
@@ -116,6 +117,8 @@ static inline const char *phy_modes(phy_interface_t interface)
 		return "xgmii";
 	case PHY_INTERFACE_MODE_MOCA:
 		return "moca";
+	case PHY_INTERFACE_MODE_QSGMII:
+		return "qsgmii";
 	default:
 		return "unknown";
 	}
-- 
1.8.3.2

Re: [PATCH 1/3] net: phy: add minimal support for QSGMII PHY

[Florian Fainelli]

2014-04-15 6:50 GMT-07:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> This commit adds the necessary definitions for the PHY layer to
> recognize "qsgmii" as a valid PHY interface. A QSMII interface, as
> defined at
> http://en.wikipedia.org/wiki/Media_Independent_Interface#Quad_Serial_Gigabit_Media_Independent_Interface,
> is "is a method of combining four SGMII lines into a 5Gbit/s
> interface. QSGMII, like SGMII, uses LVDS signalling for the TX and RX
> data and a single LVDS clock signal. QSGMII uses significantly fewer
> signal lines than four SGMII busses."
>
> This type of MAC <-> PHY connection might require special handling on
> the MAC driver side, so it should be possible to express this type of
> MAC <-> PHY connection, for example in the Device Tree.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

> Cc: devicetree@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/net/ethernet.txt | 2 +-
>  include/linux/phy.h                                | 3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
> index 9ecd43d..3fc3605 100644
> --- a/Documentation/devicetree/bindings/net/ethernet.txt
> +++ b/Documentation/devicetree/bindings/net/ethernet.txt
> @@ -10,7 +10,7 @@ The following properties are common to the Ethernet controllers:
>  - max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
>    the maximum frame size (there's contradiction in ePAPR).
>  - phy-mode: string, operation mode of the PHY interface; supported values are
> -  "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
> +  "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
>    "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a de-facto
>    standard property;
>  - phy-connection-type: the same as "phy-mode" property but described in ePAPR;
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 24126c4..4d0221f 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -75,6 +75,7 @@ typedef enum {
>         PHY_INTERFACE_MODE_SMII,
>         PHY_INTERFACE_MODE_XGMII,
>         PHY_INTERFACE_MODE_MOCA,
> +       PHY_INTERFACE_MODE_QSGMII,
>         PHY_INTERFACE_MODE_MAX,
>  } phy_interface_t;
>
> @@ -116,6 +117,8 @@ static inline const char *phy_modes(phy_interface_t interface)
>                 return "xgmii";
>         case PHY_INTERFACE_MODE_MOCA:
>                 return "moca";
> +       case PHY_INTERFACE_MODE_QSGMII:
> +               return "qsgmii";
>         default:
>                 return "unknown";
>         }
> --
> 1.8.3.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Florian

[PATCH 1/3] net: phy: add minimal support for QSGMII PHY

[Florian Fainelli]

2014-04-15 6:50 GMT-07:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> This commit adds the necessary definitions for the PHY layer to
> recognize "qsgmii" as a valid PHY interface. A QSMII interface, as
> defined at
> http://en.wikipedia.org/wiki/Media_Independent_Interface#Quad_Serial_Gigabit_Media_Independent_Interface,
> is "is a method of combining four SGMII lines into a 5Gbit/s
> interface. QSGMII, like SGMII, uses LVDS signalling for the TX and RX
> data and a single LVDS clock signal. QSGMII uses significantly fewer
> signal lines than four SGMII busses."
>
> This type of MAC <-> PHY connection might require special handling on
> the MAC driver side, so it should be possible to express this type of
> MAC <-> PHY connection, for example in the Device Tree.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

> Cc: devicetree at vger.kernel.org
> ---
>  Documentation/devicetree/bindings/net/ethernet.txt | 2 +-
>  include/linux/phy.h                                | 3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
> index 9ecd43d..3fc3605 100644
> --- a/Documentation/devicetree/bindings/net/ethernet.txt
> +++ b/Documentation/devicetree/bindings/net/ethernet.txt
> @@ -10,7 +10,7 @@ The following properties are common to the Ethernet controllers:
>  - max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
>    the maximum frame size (there's contradiction in ePAPR).
>  - phy-mode: string, operation mode of the PHY interface; supported values are
> -  "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
> +  "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
>    "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a de-facto
>    standard property;
>  - phy-connection-type: the same as "phy-mode" property but described in ePAPR;
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 24126c4..4d0221f 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -75,6 +75,7 @@ typedef enum {
>         PHY_INTERFACE_MODE_SMII,
>         PHY_INTERFACE_MODE_XGMII,
>         PHY_INTERFACE_MODE_MOCA,
> +       PHY_INTERFACE_MODE_QSGMII,
>         PHY_INTERFACE_MODE_MAX,
>  } phy_interface_t;
>
> @@ -116,6 +117,8 @@ static inline const char *phy_modes(phy_interface_t interface)
>                 return "xgmii";
>         case PHY_INTERFACE_MODE_MOCA:
>                 return "moca";
> +       case PHY_INTERFACE_MODE_QSGMII:
> +               return "qsgmii";
>         default:
>                 return "unknown";
>         }
> --
> 1.8.3.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Florian

[PATCH 2/3] net: mvneta: properly configure the MAC <-> PHY connection in all situations

[Thomas Petazzoni]

Commit 5445eaf309ff ('mvneta: Try to fix mvneta when compiled as
module') fixed the mvneta driver to make it work properly when loaded
as a module in SGMII configuration, which was tested successful by the
author on the Armada XP OpenBlocks AX3, which uses SGMII.

However, some other platforms, namely the Armada XP GP don't use
SGMII, but a QSGMII connection between the MAC and the PHY, and this
case was not supported by the mvneta driver, which was relying on
configuration put in place by the bootloader. While this works when
the mvneta driver is built-in (because clocks are not gated), it
breaks when mvneta is built as a module, because the clock is gated
(all configuration is lost) and then re-enabled when the mvneta driver
is loaded.

In order to support all of RGMII, SGMII and QSGMII, this commit
reworks how the PHY interface configuration is done, and simplifies
it: it removes the mvneta_port_sgmii_config() and
mvneta_gmac_rgmii_set() functions, which were strange because
mvneta_gmac_rgmii_set() was called in all cases, even for SGMII
configurations. Also, the mvneta_gmac_rgmii_set() function was taking
a boolean as argument, which was always true.

Instead, all the PHY interface configuration logic is moved into the
mvneta_port_power_up() function, in a much simpler 'switch' construct,
with four cases:

 - QSGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
   the SERDES is configured in QSGMII. Technically speaking,
   configuring the SERDES of the first port would be sufficient, but
   it is simpler to do it on all ports.

 - SGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
   the SERDES is configured as SGMII.

 - RGMII: the RGMIIEn bit in GMAC_CTRL_2 is set. The PCSEn bit is kept
   cleared, and no SERDES configuration is done, because RGMII is not
   using SERDES lanes.

 - other: an error is returned. For this reason, the
   mvneta_port_power_up() now returns an int instead of nothing, and
   the return value is checked by mvneta_probe().

This has been successfully tested on:

 * Armada XP DB, which has two RGMII and two SGMII connections
 * Armada XP GP, which uses QSGMII for its four interfaces
 * Armada 370 Mirabox, which has two RGMII connections

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 73 ++++++++++++++++-------------------
 1 file changed, 34 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index b248bcb..14786c8 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -89,8 +89,9 @@
 #define      MVNETA_TX_IN_PRGRS                  BIT(1)
 #define      MVNETA_TX_FIFO_EMPTY                BIT(8)
 #define MVNETA_RX_MIN_FRAME_SIZE                 0x247c
-#define MVNETA_SGMII_SERDES_CFG			 0x24A0
+#define MVNETA_SERDES_CFG			 0x24A0
 #define      MVNETA_SGMII_SERDES_PROTO		 0x0cc7
+#define      MVNETA_QSGMII_SERDES_PROTO		 0x0667
 #define MVNETA_TYPE_PRIO                         0x24bc
 #define      MVNETA_FORCE_UNI                    BIT(21)
 #define MVNETA_TXQ_CMD_1                         0x24e4
@@ -711,35 +712,6 @@ static void mvneta_rxq_bm_disable(struct mvneta_port *pp,
 	mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val);
 }
 
-
-
-/* Sets the RGMII Enable bit (RGMIIEn) in port MAC control register */
-static void mvneta_gmac_rgmii_set(struct mvneta_port *pp, int enable)
-{
-	u32  val;
-
-	val = mvreg_read(pp, MVNETA_GMAC_CTRL_2);
-
-	if (enable)
-		val |= MVNETA_GMAC2_PORT_RGMII;
-	else
-		val &= ~MVNETA_GMAC2_PORT_RGMII;
-
-	mvreg_write(pp, MVNETA_GMAC_CTRL_2, val);
-}
-
-/* Config SGMII port */
-static void mvneta_port_sgmii_config(struct mvneta_port *pp)
-{
-	u32 val;
-
-	val = mvreg_read(pp, MVNETA_GMAC_CTRL_2);
-	val |= MVNETA_GMAC2_PCS_ENABLE;
-	mvreg_write(pp, MVNETA_GMAC_CTRL_2, val);
-
-	mvreg_write(pp, MVNETA_SGMII_SERDES_CFG, MVNETA_SGMII_SERDES_PROTO);
-}
-
 /* Start the Ethernet port RX and TX activity */
 static void mvneta_port_up(struct mvneta_port *pp)
 {
@@ -2749,26 +2721,44 @@ static void mvneta_conf_mbus_windows(struct mvneta_port *pp,
 }
 
 /* Power up the port */
-static void mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
+static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
 {
-	u32 val;
+	u32 ctrl;
 
 	/* MAC Cause register should be cleared */
 	mvreg_write(pp, MVNETA_UNIT_INTR_CAUSE, 0);
 
-	if (phy_mode == PHY_INTERFACE_MODE_SGMII)
-		mvneta_port_sgmii_config(pp);
+	ctrl = mvreg_read(pp, MVNETA_GMAC_CTRL_2);
 
-	mvneta_gmac_rgmii_set(pp, 1);
+	/* Even though it might look weird, when we're configured in
+	 * SGMII or QSGMII mode, the RGMII bit needs to be set.
+	 */
+	switch(phy_mode) {
+	case PHY_INTERFACE_MODE_QSGMII:
+		mvreg_write(pp, MVNETA_SERDES_CFG, MVNETA_QSGMII_SERDES_PROTO);
+		ctrl |= MVNETA_GMAC2_PCS_ENABLE | MVNETA_GMAC2_PORT_RGMII;
+		break;
+	case PHY_INTERFACE_MODE_SGMII:
+		mvreg_write(pp, MVNETA_SERDES_CFG, MVNETA_SGMII_SERDES_PROTO);
+		ctrl |= MVNETA_GMAC2_PCS_ENABLE | MVNETA_GMAC2_PORT_RGMII;
+		break;
+	case PHY_INTERFACE_MODE_RGMII:
+	case PHY_INTERFACE_MODE_RGMII_ID:
+		ctrl |= MVNETA_GMAC2_PORT_RGMII;
+		break;
+	default:
+		return -EINVAL;
+	}
 
 	/* Cancel Port Reset */
-	val = mvreg_read(pp, MVNETA_GMAC_CTRL_2);
-	val &= ~MVNETA_GMAC2_PORT_RESET;
-	mvreg_write(pp, MVNETA_GMAC_CTRL_2, val);
+	ctrl &= ~MVNETA_GMAC2_PORT_RESET;
+	mvreg_write(pp, MVNETA_GMAC_CTRL_2, ctrl);
 
 	while ((mvreg_read(pp, MVNETA_GMAC_CTRL_2) &
 		MVNETA_GMAC2_PORT_RESET) != 0)
 		continue;
+
+	return 0;
 }
 
 /* Device initialization routine */
@@ -2879,7 +2869,12 @@ static int mvneta_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "can't init eth hal\n");
 		goto err_free_stats;
 	}
-	mvneta_port_power_up(pp, phy_mode);
+
+	err = mvneta_port_power_up(pp, phy_mode);
+	if (err < 0) {
+		dev_err(&pdev->dev, "can't power up port\n");
+		goto err_deinit;
+	}
 
 	dram_target_info = mv_mbus_dram_info();
 	if (dram_target_info)
-- 
1.8.3.2

[PATCH 2/3] net: mvneta: properly configure the MAC <-> PHY connection in all situations

[Thomas Petazzoni]

Commit 5445eaf309ff ('mvneta: Try to fix mvneta when compiled as
module') fixed the mvneta driver to make it work properly when loaded
as a module in SGMII configuration, which was tested successful by the
author on the Armada XP OpenBlocks AX3, which uses SGMII.

However, some other platforms, namely the Armada XP GP don't use
SGMII, but a QSGMII connection between the MAC and the PHY, and this
case was not supported by the mvneta driver, which was relying on
configuration put in place by the bootloader. While this works when
the mvneta driver is built-in (because clocks are not gated), it
breaks when mvneta is built as a module, because the clock is gated
(all configuration is lost) and then re-enabled when the mvneta driver
is loaded.

In order to support all of RGMII, SGMII and QSGMII, this commit
reworks how the PHY interface configuration is done, and simplifies
it: it removes the mvneta_port_sgmii_config() and
mvneta_gmac_rgmii_set() functions, which were strange because
mvneta_gmac_rgmii_set() was called in all cases, even for SGMII
configurations. Also, the mvneta_gmac_rgmii_set() function was taking
a boolean as argument, which was always true.

Instead, all the PHY interface configuration logic is moved into the
mvneta_port_power_up() function, in a much simpler 'switch' construct,
with four cases:

 - QSGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
   the SERDES is configured in QSGMII. Technically speaking,
   configuring the SERDES of the first port would be sufficient, but
   it is simpler to do it on all ports.

 - SGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
   the SERDES is configured as SGMII.

 - RGMII: the RGMIIEn bit in GMAC_CTRL_2 is set. The PCSEn bit is kept
   cleared, and no SERDES configuration is done, because RGMII is not
   using SERDES lanes.

 - other: an error is returned. For this reason, the
   mvneta_port_power_up() now returns an int instead of nothing, and
   the return value is checked by mvneta_probe().

This has been successfully tested on:

 * Armada XP DB, which has two RGMII and two SGMII connections
 * Armada XP GP, which uses QSGMII for its four interfaces
 * Armada 370 Mirabox, which has two RGMII connections

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 73 ++++++++++++++++-------------------
 1 file changed, 34 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index b248bcb..14786c8 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -89,8 +89,9 @@
 #define      MVNETA_TX_IN_PRGRS                  BIT(1)
 #define      MVNETA_TX_FIFO_EMPTY                BIT(8)
 #define MVNETA_RX_MIN_FRAME_SIZE                 0x247c
-#define MVNETA_SGMII_SERDES_CFG			 0x24A0
+#define MVNETA_SERDES_CFG			 0x24A0
 #define      MVNETA_SGMII_SERDES_PROTO		 0x0cc7
+#define      MVNETA_QSGMII_SERDES_PROTO		 0x0667
 #define MVNETA_TYPE_PRIO                         0x24bc
 #define      MVNETA_FORCE_UNI                    BIT(21)
 #define MVNETA_TXQ_CMD_1                         0x24e4
@@ -711,35 +712,6 @@ static void mvneta_rxq_bm_disable(struct mvneta_port *pp,
 	mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val);
 }
 
-
-
-/* Sets the RGMII Enable bit (RGMIIEn) in port MAC control register */
-static void mvneta_gmac_rgmii_set(struct mvneta_port *pp, int enable)
-{
-	u32  val;
-
-	val = mvreg_read(pp, MVNETA_GMAC_CTRL_2);
-
-	if (enable)
-		val |= MVNETA_GMAC2_PORT_RGMII;
-	else
-		val &= ~MVNETA_GMAC2_PORT_RGMII;
-
-	mvreg_write(pp, MVNETA_GMAC_CTRL_2, val);
-}
-
-/* Config SGMII port */
-static void mvneta_port_sgmii_config(struct mvneta_port *pp)
-{
-	u32 val;
-
-	val = mvreg_read(pp, MVNETA_GMAC_CTRL_2);
-	val |= MVNETA_GMAC2_PCS_ENABLE;
-	mvreg_write(pp, MVNETA_GMAC_CTRL_2, val);
-
-	mvreg_write(pp, MVNETA_SGMII_SERDES_CFG, MVNETA_SGMII_SERDES_PROTO);
-}
-
 /* Start the Ethernet port RX and TX activity */
 static void mvneta_port_up(struct mvneta_port *pp)
 {
@@ -2749,26 +2721,44 @@ static void mvneta_conf_mbus_windows(struct mvneta_port *pp,
 }
 
 /* Power up the port */
-static void mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
+static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
 {
-	u32 val;
+	u32 ctrl;
 
 	/* MAC Cause register should be cleared */
 	mvreg_write(pp, MVNETA_UNIT_INTR_CAUSE, 0);
 
-	if (phy_mode == PHY_INTERFACE_MODE_SGMII)
-		mvneta_port_sgmii_config(pp);
+	ctrl = mvreg_read(pp, MVNETA_GMAC_CTRL_2);
 
-	mvneta_gmac_rgmii_set(pp, 1);
+	/* Even though it might look weird, when we're configured in
+	 * SGMII or QSGMII mode, the RGMII bit needs to be set.
+	 */
+	switch(phy_mode) {
+	case PHY_INTERFACE_MODE_QSGMII:
+		mvreg_write(pp, MVNETA_SERDES_CFG, MVNETA_QSGMII_SERDES_PROTO);
+		ctrl |= MVNETA_GMAC2_PCS_ENABLE | MVNETA_GMAC2_PORT_RGMII;
+		break;
+	case PHY_INTERFACE_MODE_SGMII:
+		mvreg_write(pp, MVNETA_SERDES_CFG, MVNETA_SGMII_SERDES_PROTO);
+		ctrl |= MVNETA_GMAC2_PCS_ENABLE | MVNETA_GMAC2_PORT_RGMII;
+		break;
+	case PHY_INTERFACE_MODE_RGMII:
+	case PHY_INTERFACE_MODE_RGMII_ID:
+		ctrl |= MVNETA_GMAC2_PORT_RGMII;
+		break;
+	default:
+		return -EINVAL;
+	}
 
 	/* Cancel Port Reset */
-	val = mvreg_read(pp, MVNETA_GMAC_CTRL_2);
-	val &= ~MVNETA_GMAC2_PORT_RESET;
-	mvreg_write(pp, MVNETA_GMAC_CTRL_2, val);
+	ctrl &= ~MVNETA_GMAC2_PORT_RESET;
+	mvreg_write(pp, MVNETA_GMAC_CTRL_2, ctrl);
 
 	while ((mvreg_read(pp, MVNETA_GMAC_CTRL_2) &
 		MVNETA_GMAC2_PORT_RESET) != 0)
 		continue;
+
+	return 0;
 }
 
 /* Device initialization routine */
@@ -2879,7 +2869,12 @@ static int mvneta_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "can't init eth hal\n");
 		goto err_free_stats;
 	}
-	mvneta_port_power_up(pp, phy_mode);
+
+	err = mvneta_port_power_up(pp, phy_mode);
+	if (err < 0) {
+		dev_err(&pdev->dev, "can't power up port\n");
+		goto err_deinit;
+	}
 
 	dram_target_info = mv_mbus_dram_info();
 	if (dram_target_info)
-- 
1.8.3.2

[PATCH 3/3] ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces

[Thomas Petazzoni]

The Armada XP GP isn't using rgmii-id connections between the MAC and
PHY, but instead a single QSGMII connection, which is a quad-SGMII
connection: a double pair of differential lines that are multiplexed
to convey the traffic of four network interfaces between a MAC and a
PHY.

Until now, the Armada XP GP was relying on the bootloader setting the
correct values in various configuration registers. With this change,
the mvneta driver can be used as a module on this platform.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-gp.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 61bda68..c921f3b 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -146,22 +146,22 @@
 			ethernet@70000 {
 				status = "okay";
 				phy = <&phy0>;
-				phy-mode = "rgmii-id";
+				phy-mode = "qsgmii";
 			};
 			ethernet@74000 {
 				status = "okay";
 				phy = <&phy1>;
-				phy-mode = "rgmii-id";
+				phy-mode = "qsgmii";
 			};
 			ethernet@30000 {
 				status = "okay";
 				phy = <&phy2>;
-				phy-mode = "rgmii-id";
+				phy-mode = "qsgmii";
 			};
 			ethernet@34000 {
 				status = "okay";
 				phy = <&phy3>;
-				phy-mode = "rgmii-id";
+				phy-mode = "qsgmii";
 			};
 
 			/* Front-side USB slot */
-- 
1.8.3.2

[PATCH 3/3] ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces

[Thomas Petazzoni]

The Armada XP GP isn't using rgmii-id connections between the MAC and
PHY, but instead a single QSGMII connection, which is a quad-SGMII
connection: a double pair of differential lines that are multiplexed
to convey the traffic of four network interfaces between a MAC and a
PHY.

Until now, the Armada XP GP was relying on the bootloader setting the
correct values in various configuration registers. With this change,
the mvneta driver can be used as a module on this platform.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-gp.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 61bda68..c921f3b 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -146,22 +146,22 @@
 			ethernet at 70000 {
 				status = "okay";
 				phy = <&phy0>;
-				phy-mode = "rgmii-id";
+				phy-mode = "qsgmii";
 			};
 			ethernet at 74000 {
 				status = "okay";
 				phy = <&phy1>;
-				phy-mode = "rgmii-id";
+				phy-mode = "qsgmii";
 			};
 			ethernet at 30000 {
 				status = "okay";
 				phy = <&phy2>;
-				phy-mode = "rgmii-id";
+				phy-mode = "qsgmii";
 			};
 			ethernet at 34000 {
 				status = "okay";
 				phy = <&phy3>;
-				phy-mode = "rgmii-id";
+				phy-mode = "qsgmii";
 			};
 
 			/* Front-side USB slot */
-- 
1.8.3.2

Re: [PATCH 3/3] ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces

[Jason Cooper]

On Tue, Apr 15, 2014 at 03:50:21PM +0200, Thomas Petazzoni wrote:
> The Armada XP GP isn't using rgmii-id connections between the MAC and
> PHY, but instead a single QSGMII connection, which is a quad-SGMII
> connection: a double pair of differential lines that are multiplexed
> to convey the traffic of four network interfaces between a MAC and a
> PHY.
> 
> Until now, the Armada XP GP was relying on the bootloader setting the
> correct values in various configuration registers. With this change,
> the mvneta driver can be used as a module on this platform.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  arch/arm/boot/dts/armada-xp-gp.dts | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Applied to mvebu/dt-fixes with Willy and Arnaud's Tested-by's

thx,

Jason.

[PATCH 3/3] ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces

[Jason Cooper]

On Tue, Apr 15, 2014 at 03:50:21PM +0200, Thomas Petazzoni wrote:
> The Armada XP GP isn't using rgmii-id connections between the MAC and
> PHY, but instead a single QSGMII connection, which is a quad-SGMII
> connection: a double pair of differential lines that are multiplexed
> to convey the traffic of four network interfaces between a MAC and a
> PHY.
> 
> Until now, the Armada XP GP was relying on the bootloader setting the
> correct values in various configuration registers. With this change,
> the mvneta driver can be used as a module on this platform.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  arch/arm/boot/dts/armada-xp-gp.dts | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Applied to mvebu/dt-fixes with Willy and Arnaud's Tested-by's

thx,

Jason.

Re: [PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[Arnaud Ebalard]

Hi Thomas,

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

> This set of patches has been tested on:
>
>  * Armada XP GP (four QSGMII interfaces)
>  * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
>  * Armada 370 Mirabox (two RGMII interfaces)
>
> I've tested both the driver built-in, and compiled as a module.
>
> Since the last attempt at fixing this was quite a fiasco, I'd like
> this new attempt to be tested more widely before being applied. I'll
> try to do some testing on other Armada boards I have, but independent
> testing from other persons would also be appreciated.
>
> Note that these patches apply after reverting the previous attempt,
> obviously.

I just tested the set w/ the driver built-on on top of current
3.15.0-rc1 w/ e3a8786c10e7 reverted on a RN102 (A370, 2xRGMII), a
RN104  (A370, 2xRGMII) and a RN2120 (AXP, 2xRGMII). The interface(s)
work(s) as expected, i.e. everything is in order. You can add my

Tested-by: Arnaud Ebalard <arno@natisbad.org>

Thanks for your work!

Cheers,

a+

[PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[Arnaud Ebalard]

Hi Thomas,

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

> This set of patches has been tested on:
>
>  * Armada XP GP (four QSGMII interfaces)
>  * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
>  * Armada 370 Mirabox (two RGMII interfaces)
>
> I've tested both the driver built-in, and compiled as a module.
>
> Since the last attempt at fixing this was quite a fiasco, I'd like
> this new attempt to be tested more widely before being applied. I'll
> try to do some testing on other Armada boards I have, but independent
> testing from other persons would also be appreciated.
>
> Note that these patches apply after reverting the previous attempt,
> obviously.

I just tested the set w/ the driver built-on on top of current
3.15.0-rc1 w/ e3a8786c10e7 reverted on a RN102 (A370, 2xRGMII), a
RN104  (A370, 2xRGMII) and a RN2120 (AXP, 2xRGMII). The interface(s)
work(s) as expected, i.e. everything is in order. You can add my

Tested-by: Arnaud Ebalard <arno@natisbad.org>

Thanks for your work!

Cheers,

a+

Re: [PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[Willy Tarreau]

Hi Thomas,

On Tue, Apr 15, 2014 at 03:50:18PM +0200, Thomas Petazzoni wrote:
(...)
> This set of patches has been tested on:
> 
>  * Armada XP GP (four QSGMII interfaces)
>  * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
>  * Armada 370 Mirabox (two RGMII interfaces)
> 
> I've tested both the driver built-in, and compiled as a module.
> 
> Since the last attempt at fixing this was quite a fiasco, I'd like
> this new attempt to be tested more widely before being applied. I'll
> try to do some testing on other Armada boards I have, but independent
> testing from other persons would also be appreciated.
> 
> Note that these patches apply after reverting the previous attempt,
> obviously.

Just tried on the AX3 using 3.14 with the last fix reverted, and it
works fine here as well both built-in and as a module. Feel free to
add my :

  Tested-by: Willy Tarreau <w@1wt.eu>

Great work!
Willy

[PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[Willy Tarreau]

Hi Thomas,

On Tue, Apr 15, 2014 at 03:50:18PM +0200, Thomas Petazzoni wrote:
(...)
> This set of patches has been tested on:
> 
>  * Armada XP GP (four QSGMII interfaces)
>  * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
>  * Armada 370 Mirabox (two RGMII interfaces)
> 
> I've tested both the driver built-in, and compiled as a module.
> 
> Since the last attempt at fixing this was quite a fiasco, I'd like
> this new attempt to be tested more widely before being applied. I'll
> try to do some testing on other Armada boards I have, but independent
> testing from other persons would also be appreciated.
> 
> Note that these patches apply after reverting the previous attempt,
> obviously.

Just tried on the AX3 using 3.14 with the last fix reverted, and it
works fine here as well both built-in and as a module. Feel free to
add my :

  Tested-by: Willy Tarreau <w@1wt.eu>

Great work!
Willy

Re: [PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[David Miller]

From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Tue, 15 Apr 2014 15:50:18 +0200

> PATCH 1 and 2 would be merged by David Miller, through the net tree,
> while PATCH 3 would be merged by the mach-mvebu maintainers, through
> their tree and arm-soc.

Patches 1 and 2 applied, thanks.

[PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[David Miller]

From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Tue, 15 Apr 2014 15:50:18 +0200

> PATCH 1 and 2 would be merged by David Miller, through the net tree,
> while PATCH 3 would be merged by the mach-mvebu maintainers, through
> their tree and arm-soc.

Patches 1 and 2 applied, thanks.

Re: [PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[Thomas Petazzoni]

Jason,

Would it be possible to get PATCH 3/3 merged into 3.15-rc in the not
too distant future? David Miller has already sent PATCH 1/3 and PATCH
2/3, and they are part of the just released -rc2. However, the Device
Tree fix for Armada XP GP QSGMII usage is missing.

Thanks!

Thomas

On Tue, 15 Apr 2014 15:50:18 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> This set of patches is a new attempt at fixing the operation of the
> mvneta driver when built as a module. For the record, the previous
> attempt, merged in commit e3a8786c10e75903f1269474e21fe8cb49c3a670
> ('net: mvneta: fix usage as a module on RGMII configurations') caused
> problems for all RGMII configurations.
> 
> In fact, it turned out that the MAC to PHY connection on the Armada XP
> GP, which was described as using RGMII-ID according to its Device
> Tree, is in fact a QSGMII connection. And the RGMII and QSGMII
> configurations have to be handled in a different way in the driver,
> because the SERDES configuration is different in those two cases.
> 
> So, this patch series fixes that by:
> 
>  * Adding minimal handling of a "qsgmii" connection type in the PHY
>    layer. Mainly to make sure that a "qsgmii" phy-mode in the Device
>    Tree is recognized, and handed over to the driver as
>    PHY_INTERFACE_QSGMII.
> 
>  * Changing the mvneta driver to properly configure the RGMIIEn and
>    PCSEn bits in the GMAC_CTRL_2 register, and configure the SERDES
>    register, in the three possible cases: RGMII, SGMII and QSGMII.
> 
>  * Updating the Device Tree of the Armada XP GP board to reflect the
>    fact that it uses a QSGMII MAC/PHY connection.
> 
> PATCH 1 and 2 would be merged by David Miller, through the net tree,
> while PATCH 3 would be merged by the mach-mvebu maintainers, through
> their tree and arm-soc.
> 
> This set of patches has been tested on:
> 
>  * Armada XP GP (four QSGMII interfaces)
>  * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
>  * Armada 370 Mirabox (two RGMII interfaces)
> 
> I've tested both the driver built-in, and compiled as a module.
> 
> Since the last attempt at fixing this was quite a fiasco, I'd like
> this new attempt to be tested more widely before being applied. I'll
> try to do some testing on other Armada boards I have, but independent
> testing from other persons would also be appreciated.
> 
> Note that these patches apply after reverting the previous attempt,
> obviously.
> 
> Thanks,
> 
> Thomas
> 
> Thomas Petazzoni (3):
>   net: phy: add minimal support for QSGMII PHY
>   net: mvneta: properly configure the MAC <-> PHY connection in all
>     situations
>   ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces
> 
>  Documentation/devicetree/bindings/net/ethernet.txt |  2 +-
>  arch/arm/boot/dts/armada-xp-gp.dts                 |  8 +--
>  drivers/net/ethernet/marvell/mvneta.c              | 73 ++++++++++------------
>  include/linux/phy.h                                |  3 +
>  4 files changed, 42 insertions(+), 44 deletions(-)
> 



-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[Thomas Petazzoni]

Jason,

Would it be possible to get PATCH 3/3 merged into 3.15-rc in the not
too distant future? David Miller has already sent PATCH 1/3 and PATCH
2/3, and they are part of the just released -rc2. However, the Device
Tree fix for Armada XP GP QSGMII usage is missing.

Thanks!

Thomas

On Tue, 15 Apr 2014 15:50:18 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> This set of patches is a new attempt at fixing the operation of the
> mvneta driver when built as a module. For the record, the previous
> attempt, merged in commit e3a8786c10e75903f1269474e21fe8cb49c3a670
> ('net: mvneta: fix usage as a module on RGMII configurations') caused
> problems for all RGMII configurations.
> 
> In fact, it turned out that the MAC to PHY connection on the Armada XP
> GP, which was described as using RGMII-ID according to its Device
> Tree, is in fact a QSGMII connection. And the RGMII and QSGMII
> configurations have to be handled in a different way in the driver,
> because the SERDES configuration is different in those two cases.
> 
> So, this patch series fixes that by:
> 
>  * Adding minimal handling of a "qsgmii" connection type in the PHY
>    layer. Mainly to make sure that a "qsgmii" phy-mode in the Device
>    Tree is recognized, and handed over to the driver as
>    PHY_INTERFACE_QSGMII.
> 
>  * Changing the mvneta driver to properly configure the RGMIIEn and
>    PCSEn bits in the GMAC_CTRL_2 register, and configure the SERDES
>    register, in the three possible cases: RGMII, SGMII and QSGMII.
> 
>  * Updating the Device Tree of the Armada XP GP board to reflect the
>    fact that it uses a QSGMII MAC/PHY connection.
> 
> PATCH 1 and 2 would be merged by David Miller, through the net tree,
> while PATCH 3 would be merged by the mach-mvebu maintainers, through
> their tree and arm-soc.
> 
> This set of patches has been tested on:
> 
>  * Armada XP GP (four QSGMII interfaces)
>  * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
>  * Armada 370 Mirabox (two RGMII interfaces)
> 
> I've tested both the driver built-in, and compiled as a module.
> 
> Since the last attempt at fixing this was quite a fiasco, I'd like
> this new attempt to be tested more widely before being applied. I'll
> try to do some testing on other Armada boards I have, but independent
> testing from other persons would also be appreciated.
> 
> Note that these patches apply after reverting the previous attempt,
> obviously.
> 
> Thanks,
> 
> Thomas
> 
> Thomas Petazzoni (3):
>   net: phy: add minimal support for QSGMII PHY
>   net: mvneta: properly configure the MAC <-> PHY connection in all
>     situations
>   ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces
> 
>  Documentation/devicetree/bindings/net/ethernet.txt |  2 +-
>  arch/arm/boot/dts/armada-xp-gp.dts                 |  8 +--
>  drivers/net/ethernet/marvell/mvneta.c              | 73 ++++++++++------------
>  include/linux/phy.h                                |  3 +
>  4 files changed, 42 insertions(+), 44 deletions(-)
> 



-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[Jason Cooper]

On Mon, Apr 21, 2014 at 08:28:40PM +0200, Thomas Petazzoni wrote:
> Jason,
> 
> Would it be possible to get PATCH 3/3 merged into 3.15-rc in the not
> too distant future? David Miller has already sent PATCH 1/3 and PATCH
> 2/3, and they are part of the just released -rc2. However, the Device
> Tree fix for Armada XP GP QSGMII usage is missing.

oops, looks like I missed that one.  I'll queue it up.

thx,

Jason.

[PATCH 0/3] net: mvneta: fix usage as a module, and support QSGMII properly

[Jason Cooper]

On Mon, Apr 21, 2014 at 08:28:40PM +0200, Thomas Petazzoni wrote:
> Jason,
> 
> Would it be possible to get PATCH 3/3 merged into 3.15-rc in the not
> too distant future? David Miller has already sent PATCH 1/3 and PATCH
> 2/3, and they are part of the just released -rc2. However, the Device
> Tree fix for Armada XP GP QSGMII usage is missing.

oops, looks like I missed that one.  I'll queue it up.

thx,

Jason.