diff mbox series

[04/15] phy: mvebu-cp110-comphy: Add RXAUI support

Message ID 20190401165131.23370-5-miquel.raynal@bootlin.com (mailing list archive)
State New, archived
Headers show
Series Enhance CP110 COMPHY support | expand

Commit Message

Miquel Raynal April 1, 2019, 4:51 p.m. UTC 
Add support for RXAUI mode by adding an entry in the COMPHY modes list.

There is nothing more to handle besides avoiding to return an error to
the caller: someone using a DT updated with the right 'phys' property
with an old firmware would get an error when initializing the lanes in
RXAUI mode, while it could have already been initialized by eg. the
bootloader. It would prevent the interface to work with no reason.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

Comments

Maxime Chevallier April 2, 2019, 8:43 a.m. UTC | #1 
Hi Miquel,

On Mon,  1 Apr 2019 18:51:20 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:

>Add support for RXAUI mode by adding an entry in the COMPHY modes list.
>
>There is nothing more to handle besides avoiding to return an error to
>the caller: someone using a DT updated with the right 'phys' property
>with an old firmware would get an error when initializing the lanes in
>RXAUI mode, while it could have already been initialized by eg. the
>bootloader. It would prevent the interface to work with no reason.

However, this would mask-away errors that could occur when we have a
correct firmware and DT.

Maybe we should simply return the error, this mode isn't supported in
PPv2 yet so I don't expect this to break any existing setups.

Maxime
Miquel Raynal April 2, 2019, 12:24 p.m. UTC | #2 
Hi Maxime,

Maxime Chevallier <maxime.chevallier@bootlin.com> wrote on Tue, 2 Apr
2019 10:43:49 +0200:

> Hi Miquel,
> 
> On Mon,  1 Apr 2019 18:51:20 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> 
> >Add support for RXAUI mode by adding an entry in the COMPHY modes list.
> >
> >There is nothing more to handle besides avoiding to return an error to
> >the caller: someone using a DT updated with the right 'phys' property
> >with an old firmware would get an error when initializing the lanes in
> >RXAUI mode, while it could have already been initialized by eg. the
> >bootloader. It would prevent the interface to work with no reason.  
> 
> However, this would mask-away errors that could occur when we have a
> correct firmware and DT.
> 
> Maybe we should simply return the error, this mode isn't supported in
> PPv2 yet so I don't expect this to break any existing setups.

I am fine with this approach too. I think this is acceptable for RXAUI
but not for the other SATA/USB3/PCIe modes which already work because
of U-Boot configuration (while RXAUI seems to not be configured
anyway).


Thanks,
Miquèl
diff mbox series

Patch

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index b6890d3c34a3..393dfcc59a33 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -148,6 +148,7 @@ 
 
 #define COMPHY_FW_MODE_SGMII		0x2 /* SGMII 1G */
 #define COMPHY_FW_MODE_HS_SGMII		0x3 /* SGMII 2.5G */
+#define COMPHY_FW_MODE_RXAUI		0x7
 #define COMPHY_FW_MODE_SFI		0x9 /* XFI: 0x8 (is treated like SFI) */
 
 struct mvebu_comphy_conf {
@@ -179,18 +180,22 @@  static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	/* lane 2 */
 	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
+	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1, COMPHY_FW_MODE_SFI),
 	/* lane 3 */
 	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
+	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	/* lane 4 */
 	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
 	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2, COMPHY_FW_MODE_SFI),
+	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_2500BASEX, -1, COMPHY_FW_MODE_HS_SGMII),
 	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_10GKR, -1, COMPHY_FW_MODE_SFI),
 	/* lane 5 */
+	MVEBU_COMPHY_CONF(5, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 };
@@ -586,6 +591,7 @@  static int mvebu_comphy_power_on(struct phy *phy)
 {
 	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
 	struct mvebu_comphy_priv *priv = lane->priv;
+	bool hide_error = false; /* Handle new DT & old firmware */
 	u32 fw_param = 0;
 	int fw_mode;
 	int ret;
@@ -600,6 +606,8 @@  static int mvebu_comphy_power_on(struct phy *phy)
 	case PHY_MODE_ETHERNET:
 		dev_dbg(priv->dev, "set lane %d to Ethernet mode\n", lane->id);
 		switch (lane->submode) {
+		case PHY_INTERFACE_MODE_RXAUI:
+			hide_error = true;
 		case PHY_INTERFACE_MODE_SGMII:
 		case PHY_INTERFACE_MODE_2500BASEX:
 		case PHY_INTERFACE_MODE_10GKR:
@@ -618,8 +626,8 @@  static int mvebu_comphy_power_on(struct phy *phy)
 
 	ret = mvebu_comphy_smc(COMPHY_SIP_POWER_ON, priv->cp_phys, lane->id,
 			       fw_param);
-	if (!ret)
-		return ret;
+	if (!ret || hide_error)
+		return 0;
 
 try_legacy:
 	/* Fallback to Linux's implementation */