| Message ID | 20200810220645.19326-3-marek.behun@nic.cz |
|---|---|
| State | RFC |
| Delegated to: | David Miller |
| Headers | show |
| Series | Support for RollBall 10G copper SFP modules | expand |
On Tue, Aug 11, 2020 at 12:06:43AM +0200, Marek Behún wrote: > This adds support for multigig copper SFP modules from RollBall/Hilink. > These modules have a specific way to access clause 45 registers of the > internal PHY. > > We also need to wait at least 25 seconds after deasserting TX disable > before accessing the PHY. The code waits for 30 seconds just to be sure. I wonder why it takes so long - the 88x3310 boots very quickly. > +static int sfp_i2c_mii_probe(struct sfp *sfp) > +{ > + struct mii_bus *i2c_mii; > + int ret; > + > + if (sfp->rollball_mii) > + i2c_mii = mdio_i2c_rollball_alloc(sfp->dev, sfp->i2c); > + else > + i2c_mii = mdio_i2c_alloc(sfp->dev, sfp->i2c); > + I think I'd prefer to find a way to teach the existing mdio_i2c code about different protocols rather than having a load of different buses that we have to select between. Maybe we can do that via the PHY address, or maybe we should have a call into mdio_i2c that tells it which protocol should be used? The reason I don't like this approach is it seems to me to be very heavy handed... using a sledge hammer to crack a nut. > + rollball = (!memcmp(id.base.vendor_name, "OEM ", 16) && > + (!memcmp(id.base.vendor_pn, "SFP-10G-T ", 16) || > + !memcmp(id.base.vendor_pn, "RTSFP-10 ", 16) || > + !memcmp(id.base.vendor_pn, "RTSFP-2.5G ", 16))); > + if (rollball) { > + /* TODO: try to write this to EEPROM */ > + id.base.extended_cc = SFF8024_ECC_10GBASE_T_SFI; Should we really be "fixing" vendors EEPROMs for them?
On Tue, 11 Aug 2020 16:15:53 +0100 Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > + if (rollball) { > > + /* TODO: try to write this to EEPROM */ > > + id.base.extended_cc = SFF8024_ECC_10GBASE_T_SFI; > > Should we really be "fixing" vendors EEPROMs for them? > Are you reffering to the TODO comment or the id.base.extended_cc assignment? If the comment, well, your code does it for cotsworks modules, but I am actually indifferent. If the assignment - either this needs to be done or the sfp_probe_for_phy and sfp_may_have_phy functions have to be changed so that they check for rollball module by vendor ID. Marek
On Wed, Aug 12, 2020 at 03:33:26PM +0200, Marek Behún wrote: > On Tue, 11 Aug 2020 16:15:53 +0100 > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > > > + if (rollball) { > > > + /* TODO: try to write this to EEPROM */ > > > + id.base.extended_cc = SFF8024_ECC_10GBASE_T_SFI; > > > > Should we really be "fixing" vendors EEPROMs for them? > > > > Are you reffering to the TODO comment or the id.base.extended_cc > assignment? > If the comment, well, your code does it for cotsworks modules, but I am > actually indifferent. No, that's Chris' code, and there's quite a bit of history there: It appears Cotsworks programmed things like the serial number into the EEPROM and did not update the checksums. After quite some time, it seems Cotsworks have seen sense, and have fixed their production line to properly program the EEPROM, but that leaves a whole bunch of modules with bad checksums. I'm more than happy that we should continue issuing the warning, but Chris has decided to fix them up. I'm not particularly happy with that idea, but I didn't get the chance to express it before David picked up the patch. So, it's now in mainline. Fixing the checksum for a module that is known to suffer bad checksums is one thing - it's a single byte write, and as the checksum is wrong, it's likely other systems that know about the issue will ignore it. However, changing the module description to be "correct" is a completely different level - there are many modules that do not report "correct" data, and, if we start fixing these up, it's likely that fixups that other SFP cage implementations have could stop working since they may not recognise the module. Remember, things like the extended CC codes are dependent on the SFF spec revisions, so if we start changing the extended CC code in byte 36, should we also change the SFF8472 compliance code as well (to be > rev 11.9)? Since SFF8472 rev 11.9 changed the definition of this byte.
On Wed, 12 Aug 2020 15:33:04 +0100 Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > On Wed, Aug 12, 2020 at 03:33:26PM +0200, Marek Behún wrote: > > On Tue, 11 Aug 2020 16:15:53 +0100 > > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > > > > > + if (rollball) { > > > > + /* TODO: try to write this to EEPROM */ > > > > + id.base.extended_cc = > > > > SFF8024_ECC_10GBASE_T_SFI; > > > > > > Should we really be "fixing" vendors EEPROMs for them? > > > > > > > Are you reffering to the TODO comment or the id.base.extended_cc > > assignment? > > If the comment, well, your code does it for cotsworks modules, but > > I am actually indifferent. > > No, that's Chris' code, and there's quite a bit of history there: > It appears Cotsworks programmed things like the serial number into > the EEPROM and did not update the checksums. After quite some time, > it seems Cotsworks have seen sense, and have fixed their production > line to properly program the EEPROM, but that leaves a whole bunch > of modules with bad checksums. > > I'm more than happy that we should continue issuing the warning, but > Chris has decided to fix them up. I'm not particularly happy with > that idea, but I didn't get the chance to express it before David > picked up the patch. So, it's now in mainline. > > Fixing the checksum for a module that is known to suffer bad checksums > is one thing - it's a single byte write, and as the checksum is wrong, > it's likely other systems that know about the issue will ignore it. > > However, changing the module description to be "correct" is a > completely different level - there are many modules that do not > report "correct" data, and, if we start fixing these up, it's likely > that fixups that other SFP cage implementations have could stop > working since they may not recognise the module. > > Remember, things like the extended CC codes are dependent on the SFF > spec revisions, so if we start changing the extended CC code in byte > 36, should we also change the SFF8472 compliance code as well (to > be > rev 11.9)? Since SFF8472 rev 11.9 changed the definition of this > byte. > Thank you Russell for this explanation.
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c index a62fa2e5ae4e6..fe72282e96c7d 100644 --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c @@ -167,6 +167,7 @@ static const enum gpiod_flags gpio_flags[] = { #define T_WAIT msecs_to_jiffies(50) #define T_START_UP msecs_to_jiffies(300) #define T_START_UP_BAD_GPON msecs_to_jiffies(60000) +#define T_START_UP_LONG_PHY msecs_to_jiffies(30000) /* t_reset is the time required to assert the TX_DISABLE signal to reset * an indicated TX_FAULT. @@ -243,6 +244,7 @@ struct sfp { struct sfp_eeprom_id id; unsigned int module_power_mW; unsigned int module_t_start_up; + bool rollball_mii; #if IS_ENABLED(CONFIG_HWMON) struct sfp_diag diag; @@ -394,9 +396,6 @@ static int sfp_i2c_write(struct sfp *sfp, bool a2, u8 dev_addr, void *buf, static int sfp_i2c_configure(struct sfp *sfp, struct i2c_adapter *i2c) { - struct mii_bus *i2c_mii; - int ret; - if (!i2c_check_functionality(i2c, I2C_FUNC_I2C)) return -EINVAL; @@ -404,7 +403,19 @@ static int sfp_i2c_configure(struct sfp *sfp, struct i2c_adapter *i2c) sfp->read = sfp_i2c_read; sfp->write = sfp_i2c_write; - i2c_mii = mdio_i2c_alloc(sfp->dev, i2c); + return 0; +} + +static int sfp_i2c_mii_probe(struct sfp *sfp) +{ + struct mii_bus *i2c_mii; + int ret; + + if (sfp->rollball_mii) + i2c_mii = mdio_i2c_rollball_alloc(sfp->dev, sfp->i2c); + else + i2c_mii = mdio_i2c_alloc(sfp->dev, sfp->i2c); + if (IS_ERR(i2c_mii)) return PTR_ERR(i2c_mii); @@ -422,6 +433,14 @@ static int sfp_i2c_configure(struct sfp *sfp, struct i2c_adapter *i2c) return 0; } +static void sfp_i2c_mii_remove(struct sfp *sfp) +{ + if (sfp->i2c_mii) { + mdiobus_unregister(sfp->i2c_mii); + mdiobus_free(sfp->i2c_mii); + } +} + /* Interface */ static int sfp_read(struct sfp *sfp, bool a2, u8 addr, void *buf, size_t len) { @@ -1419,6 +1438,7 @@ static void sfp_sm_phy_detach(struct sfp *sfp) phy_device_remove(sfp->mod_phy); phy_device_free(sfp->mod_phy); sfp->mod_phy = NULL; + sfp_i2c_mii_remove(sfp); } static int sfp_sm_probe_phy(struct sfp *sfp, bool is_c45) @@ -1426,10 +1446,17 @@ static int sfp_sm_probe_phy(struct sfp *sfp, bool is_c45) struct phy_device *phy; int err; + err = sfp_i2c_mii_probe(sfp); + if (err) + return err; + phy = get_phy_device(sfp->i2c_mii, SFP_PHY_ADDR, is_c45); - if (phy == ERR_PTR(-ENODEV)) + if (phy == ERR_PTR(-ENODEV)) { + sfp_i2c_mii_remove(sfp); return PTR_ERR(phy); + } if (IS_ERR(phy)) { + sfp_i2c_mii_remove(sfp); dev_err(sfp->dev, "mdiobus scan returned %ld\n", PTR_ERR(phy)); return PTR_ERR(phy); } @@ -1437,6 +1464,7 @@ static int sfp_sm_probe_phy(struct sfp *sfp, bool is_c45) err = phy_device_register(phy); if (err) { phy_device_free(phy); + sfp_i2c_mii_remove(sfp); dev_err(sfp->dev, "phy_device_register failed: %d\n", err); return err; } @@ -1445,6 +1473,7 @@ static int sfp_sm_probe_phy(struct sfp *sfp, bool is_c45) if (err) { phy_device_remove(phy); phy_device_free(phy); + sfp_i2c_mii_remove(sfp); dev_err(sfp->dev, "sfp_add_phy failed: %d\n", err); return err; } @@ -1665,6 +1694,7 @@ static int sfp_sm_mod_probe(struct sfp *sfp, bool report) struct sfp_eeprom_id id; bool cotsworks_sfbg; bool cotsworks; + bool rollball; u8 check; int ret; @@ -1730,7 +1760,17 @@ static int sfp_sm_mod_probe(struct sfp *sfp, bool report) } } + rollball = (!memcmp(id.base.vendor_name, "OEM ", 16) && + (!memcmp(id.base.vendor_pn, "SFP-10G-T ", 16) || + !memcmp(id.base.vendor_pn, "RTSFP-10 ", 16) || + !memcmp(id.base.vendor_pn, "RTSFP-2.5G ", 16))); + if (rollball) { + /* TODO: try to write this to EEPROM */ + id.base.extended_cc = SFF8024_ECC_10GBASE_T_SFI; + } + sfp->id = id; + sfp->rollball_mii = rollball; dev_info(sfp->dev, "module %.*s %.*s rev %.*s sn %.*s dc %.*s\n", (int)sizeof(id.base.vendor_name), id.base.vendor_name, @@ -1760,6 +1800,8 @@ static int sfp_sm_mod_probe(struct sfp *sfp, bool report) if (!memcmp(id.base.vendor_name, "ALCATELLUCENT ", 16) && !memcmp(id.base.vendor_pn, "3FE46541AA ", 16)) sfp->module_t_start_up = T_START_UP_BAD_GPON; + else if (rollball) + sfp->module_t_start_up = T_START_UP_LONG_PHY; else sfp->module_t_start_up = T_START_UP; @@ -2264,10 +2306,7 @@ static void sfp_cleanup(void *data) cancel_delayed_work_sync(&sfp->poll); cancel_delayed_work_sync(&sfp->timeout); - if (sfp->i2c_mii) { - mdiobus_unregister(sfp->i2c_mii); - mdiobus_free(sfp->i2c_mii); - } + sfp_i2c_mii_remove(sfp); if (sfp->i2c) i2c_put_adapter(sfp->i2c); kfree(sfp);
This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 25 seconds after deasserting TX disable before accessing the PHY. The code waits for 30 seconds just to be sure. Signed-off-by: Marek Behún <marek.behun@nic.cz> --- drivers/net/phy/sfp.c | 57 ++++++++++++++++++++++++++++++++++++------- 1 file changed, 48 insertions(+), 9 deletions(-)