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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Nov 2017 09:52:10 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     David Miller <davem@...emloft.net>
Cc:     jan.kundrat@...net.cz, netdev@...r.kernel.org,
        f.fainelli@...il.com, andrew@...n.ch
Subject: Re: [PATCH] sfp: Add support for DWDM SFP modules

On Fri, Nov 17, 2017 at 02:58:05PM +0900, David Miller wrote:
> From: Jan Kundrát <jan.kundrat@...net.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@...net.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