quoted

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c

b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c

quoted

index 3597cb81a7ccb..781b22198ca86 100644

--- a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c

@@ -359,7 +359,8 @@ static bool enetc_port_has_pcs(struct enetc_pf *pf)
 	return (pf->if_mode == PHY_INTERFACE_MODE_SGMII ||
 		pf->if_mode == PHY_INTERFACE_MODE_1000BASEX ||
 		pf->if_mode == PHY_INTERFACE_MODE_2500BASEX ||
-		pf->if_mode == PHY_INTERFACE_MODE_USXGMII);
+		pf->if_mode == PHY_INTERFACE_MODE_USXGMII ||
+		pf->if_mode == PHY_INTERFACE_MODE_10GBASER);
 }

[Severity: High]
Will adding PHY_INTERFACE_MODE_10GBASER here cause the ENETC v4 probe
to fail?

If enetc_port_has_pcs() returns true for 10gbase-r, enetc_mdiobus_create()
will call enetc_imdio_create(), which does this check:

enetc_imdio_create() {
    ...
	if (!pf->ops->create_pcs) {
		dev_err(dev, "Creating PCS is not supported\n");
		return -EOPNOTSUPP;
	}
    ...
}

Since enetc4_pf_ops doesn't appear to implement .create_pcs, will device
initialization now fail entirely with -EOPNOTSUPP when configured with
the newly supported 10GBASER mode?

This is preparation for the upcoming support of 10GBASE-R mode.
10GBASE-R is not currently supported, so the probe failure is expected.