| Message ID | 5226d9535b31269e0388b781ef815ee2183ee3b9.1510745986.git.jan.kundrat@cesnet.cz |
|---|---|
| State | Deferred, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | sfp: Add support for DWDM SFP modules | expand |
From: Jan Kundrát <jan.kundrat@cesnet.cz> Date: Wed, 15 Nov 2017 12:39:33 +0100 > Without this patch, but with CONFIG_SFP enabled, my NIC won't detect > module unplugging, which is suboptimal. > > I'm using an OEM "Cisco compatible" DWDM fixed-frequency 100Ghz-grid SFP > module. It reports itself as a 0x0b 0x24. According to SFF-8024, byte 0 > value "0Bh" refers to a "DWDM-SFP/SFP+ (not using SFF-8472)". In > practice, there's a lot of shared properties here. > > Everything is apparently defined in a document called "DWDM SFP MSA > (Multi-source Agreement), Revision 1.0, 19th September 2005". I don't > have access to that ocument (yet). Its likely source, the > http://www.dwdmsfpmsa.org/ has been down for years. > > From the datasheets that I was able to find on random vendors' web, the > second byte can vary -- 0x27 is used, too. > > Tested on Clearfog Base with v4.14 and Russell King's SFP patches. > > Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Russell, Florian, Amdrew, can I get a review?
On Fri, Nov 17, 2017 at 02:58:05PM +0900, David Miller wrote: > From: Jan Kundrát <jan.kundrat@cesnet.cz> > Date: Wed, 15 Nov 2017 12:39:33 +0100 > > > Without this patch, but with CONFIG_SFP enabled, my NIC won't detect > > module unplugging, which is suboptimal. > > > > I'm using an OEM "Cisco compatible" DWDM fixed-frequency 100Ghz-grid SFP > > module. It reports itself as a 0x0b 0x24. According to SFF-8024, byte 0 > > value "0Bh" refers to a "DWDM-SFP/SFP+ (not using SFF-8472)". In > > practice, there's a lot of shared properties here. > > > > Everything is apparently defined in a document called "DWDM SFP MSA > > (Multi-source Agreement), Revision 1.0, 19th September 2005". I don't > > have access to that ocument (yet). Its likely source, the > > http://www.dwdmsfpmsa.org/ has been down for years. > > > > From the datasheets that I was able to find on random vendors' web, the > > second byte can vary -- 0x27 is used, too. > > > > Tested on Clearfog Base with v4.14 and Russell King's SFP patches. > > > > Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> > > Russell, Florian, Amdrew, can I get a review? Hi David, I've been discussing the topic with Jan off-list. There's nothing wrong per-se with the patch in that it will allow a DWDM module to be functional, but (eg) the data read by ethtool -m won't be correct. The DWDM module EEPROM format is not compatible with any of the ETH_MODULE_SFF_xxxx formats. I also need to validate that the fields we do read from the EEPROM contents in the sfp code are meaningful for DWDM. As Jan says, the DWDM MSA isn't available - from what I can tell, having looked on archive.org and extensive google searching, the MSA was never made public and dwdmsfpmsa.org has been down for years. When the site was operational, it looked like you had to be a member to have access - archive.org has all the legal agreements for that, but no specification. However, the module datasheets give some information about the EEPROM format, which has been useful. Also, this patch will conflict with Florian's SFF module patch (a soldered down version of SFP modules). I already have a stack of patches for phy, phylink and sfp that I need to send, including documentation patches which Florian has already found very useful and helpful. I had assumed that net-next was already closed, being almost a week into the merge window.
From: Russell King - ARM Linux <linux@armlinux.org.uk> Date: Fri, 17 Nov 2017 09:52:10 +0000 > I already have a stack of patches for phy, phylink and sfp that I > need to send, including documentation patches which Florian has > already found very useful and helpful. I had assumed that net-next > was already closed, being almost a week into the merge window. Yes it is. Thanks for the info, I'll mark this 'deferred' in patchwork. Please have this respun and posted once net-next is openned back up and the various issues have been sorted out. Thank you.
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c index e381811e5f11..c937ef40b72c 100644 --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c @@ -463,8 +463,12 @@ static int sfp_sm_mod_probe(struct sfp *sfp) vendor, part, rev, sn, date); /* We only support SFP modules, not the legacy GBIC modules. */ - if (sfp->id.base.phys_id != SFP_PHYS_ID_SFP || - sfp->id.base.phys_ext_id != SFP_PHYS_EXT_ID_SFP) { + if (sfp->id.base.phys_id == SFP_PHYS_ID_SFP && + sfp->id.base.phys_ext_id == SFP_PHYS_EXT_ID_SFP) { + /* a regular SFP module */ + } else if (sfp->id.base.phys_id == SFP_PHYS_ID_DWDM_SFP) { + /* DWDM SFP or a DWDM SFP+ -- let's treat it as a regular SFP */ + } else { dev_err(sfp->dev, "module is not SFP - phys id 0x%02x 0x%02x\n", sfp->id.base.phys_id, sfp->id.base.phys_ext_id); return -EINVAL; diff --git a/include/linux/sfp.h b/include/linux/sfp.h index 4a906f560817..21f53adc4434 100644 --- a/include/linux/sfp.h +++ b/include/linux/sfp.h @@ -223,6 +223,7 @@ enum { SFP_CC_EXT = 0x5f, SFP_PHYS_ID_SFP = 0x03, + SFP_PHYS_ID_DWDM_SFP = 0x0b, SFP_PHYS_EXT_ID_SFP = 0x04, SFP_CONNECTOR_UNSPEC = 0x00, /* codes 01-05 not supportable on SFP, but some modules have single SC */
Without this patch, but with CONFIG_SFP enabled, my NIC won't detect module unplugging, which is suboptimal. I'm using an OEM "Cisco compatible" DWDM fixed-frequency 100Ghz-grid SFP module. It reports itself as a 0x0b 0x24. According to SFF-8024, byte 0 value "0Bh" refers to a "DWDM-SFP/SFP+ (not using SFF-8472)". In practice, there's a lot of shared properties here. Everything is apparently defined in a document called "DWDM SFP MSA (Multi-source Agreement), Revision 1.0, 19th September 2005". I don't have access to that ocument (yet). Its likely source, the http://www.dwdmsfpmsa.org/ has been down for years. From the datasheets that I was able to find on random vendors' web, the second byte can vary -- 0x27 is used, too. Tested on Clearfog Base with v4.14 and Russell King's SFP patches. Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> --- drivers/net/phy/sfp.c | 8 ++++++-- include/linux/sfp.h | 1 + 2 files changed, 7 insertions(+), 2 deletions(-)