[PATCH] sfp: Add support for DWDM SFP modules

[PATCH] sfp: Add support for DWDM SFP modules

[Jan Kundrát]

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(-)

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 */
-- 
2.14.3

Re: [PATCH] sfp: Add support for DWDM SFP modules

[David Miller]

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?

Re: [PATCH] sfp: Add support for DWDM SFP modules

[Russell King - ARM Linux]

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.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] sfp: Add support for DWDM SFP modules

[David Miller]

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.