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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 11 Jun 2018 14:01:04 -0700
From:   Don Bollinger <don@...bollingers.org>
To:     Tom Lendacky <thomas.lendacky@....com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, brandon_chuang@...e-core.com,
        wally_wang@...ton.com, roy_lee@...e-core.com,
        rick_burchett@...e-core.com, quentin.chang@...ntatw.com,
        steven.noble@...switch.com, jeffrey.townsend@...switch.com,
        scotte@...ulusnetworks.com, roopa@...ulusnetworks.com,
        David Ahern <dsa@...ulusnetworks.com>,
        luke.williams@...onical.com, Guohan Lu <gulv@...rosoft.com>,
        Xin Liu <xinxliu@...rosoft.com>, steve.joiner@...isar.com
Subject: Re: [PATCH] optoe: driver to read/write SFP/QSFP EEPROMs

On Mon, Jun 11, 2018 at 01:33:07PM -0500, Tom Lendacky wrote:
> On 6/10/2018 11:25 PM, Don Bollinger wrote:
> > optoe is an i2c based driver that supports read/write access to all
> > the pages (tables) of MSA standard SFP and similar devices (conforming
> > to the SFF-8472 spec) and MSA standard QSFP and similar devices
> > (conforming to the SFF-8436 spec).
> > 
> > These devices provide identification, operational status and control
> > registers via an EEPROM model. These devices support one or 3 fixed
> > pages (128 bytes) of data, and one page that is selected via a page
> > register on the first fixed page.  Thus the driver's main task is
> > to map these pages onto a simple linear address space for user space
> > management applications.  See the driver code for a detailed layout.
> > 
> > EEPROM data is accessible via a bin_attribute file called 'eeprom',
> > e.g. /sys/bus/i2c/devices/24-0050/eeprom.
> > 
> > Signed-off-by: Don Bollinger <don@...bollingers.org>
> > ---
> > 
> > Why should this driver be in the Linux kernel?  SFP and QSFP devices plug
> > into switches to convert electrical to optical signals and drive the
> > optical signal over fiber optic cables.  They provide status and control
> > registers through an i2c interface similar to to other EEPROMS.  However,
> > they have a paging mechanism that is unique, which requires a different
> > driver from (for example) at24.  Various drivers have been developed for
> > this purpose, none of them support both SFP and QSFP, provide both read
> > and write access, and access all 256 architected pages.  optoe does all
> > of these.
> > 
> > optoe has been adopted and is shipping to customers  as a base module,
> > available to all platforms (switches) and used by multiple vendors and
> > platforms on both ONL (Open Network Linux) and SONiC (Microsoft's
> > 'Software for Open Networking in the Cloud').
> > 
> > This patch has been built on the latest staging-testing kernel.  It has
> > built and tested with SFP and QSFP devices on an ARM platform with a 4.9
> > kernel, and an x86 switch with a 3.16 kernel.  This patch should install
> > and build clean on any kernel from 3.16 up to the latest (as of 6/10/2018).
> > 
> > 
> >  Documentation/misc-devices/optoe.txt |   56 ++
> >  drivers/misc/eeprom/Kconfig          |   18 +
> >  drivers/misc/eeprom/Makefile         |    1 +
> >  drivers/misc/eeprom/optoe.c          | 1141 ++++++++++++++++++++++++++++++++++
> >  4 files changed, 1216 insertions(+)
> >  create mode 100644 Documentation/misc-devices/optoe.txt
> >  create mode 100644 drivers/misc/eeprom/optoe.c
> > 
> 
> There's an SFP driver under drivers/net/phy.  Can that driver be extended
> to provide this support?  Adding Russel King who developed sfp.c, as well
> at the netdev mailing list.
> 
> Thanks,
> Tom

I don't think that would work very well.  It's software, anything is
possible, but...

sfp.c appears to be working with mdio, gpio and 'sfp_bus', in addition
to i2c.  optoe only access the EEPROM, and only via i2c.  The linux
standard i2c interfaces are the only dependencies for optoe.

Also, sfp.c does not support QSFP (best I can tell), and it does not
support additional pages beyond the 256 bytes at i2c address 0x50 and
0x51.

Best I can tell, sfp.c supports SFP devices on NIC cards.  Those cards
have a very different hardware architecture from the network switches
that optoe is targeting.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ