Re: [PATCH] optoe: driver to read/write SFP/QSFP EEPROMs

[Don Bollinger <don@thebollingers.org>]

On Fri, Jun 15, 2018 at 09:54:17AM +0200, Andrew Lunn wrote:
> > Actually this is better described by a third use case.  The target
> > switches are PHY-less (see various designs at
> > www.compute.org/wiki/Networking/SpecsAndDesigns). The AS5712 for example
> > says "The AS5712-54X is a PHY-Less design with the SFP+ and QSFP+
> > connections directly attaching to the Serdes interfaces of the Broadcom
> > BCM56854 720G Trident 2 switching silicon..."
> 
> We consider the SFP+ and QSFP+ as being the PHY. You need something to
> control that PHY. Either it is firmware running in the switch, or it
> is the Linux kernel, via PHYLINK.

Actually in the environment I'm working in (at least 3 different NOS
vendors, and 3 different switch vendors), the {Q}SFP devices are
controlled by a platform specific driver that pokes CPLD registers.  I'm
not sure where the actual control logic is, but it doesn't appear to use
any of the frameworks you are describing.

> 
> > The i2c bus is muxed from the CPU to all of the {Q}SFP devices, which
> > are set up as standard linux i2c devices
> > (/sys/bus/i2c/devices/i2c-xxxx).
> 
> Having a standard i2c bus driver is correct. This is what PHYLINK
> assumes. It knows about the different addresses the SFP uses on the
> i2c bus.

Great.  Then plugging optoe into it should be easy.

> 
> > There is no MDIO bus between the CPU and the {Q}SFP devices.
> 
> There is no physical MDIO bus for SFP devices. If the SFP module
> implements copper 1G, there is often MDIO tunnelled over i2c. PHYLINK
> knows how to do this, and will instantiate a normal Linux MDIO bus
> driver, and then you can use the Linux kernel copper PHY state
> machines as normal.
> 
> > And, there isn't actually 'a wish to expose' the EEPROM data to linux
> > (the kernel).  It turns out that none of the NOS partners I'm working
> > with use that data *in the kernel*.  It is all managed from user space.
> 
> Ah. O.K. We can stop here then.
> 
> If you are using Linux as a boot loader, i doubt you will find any
> network kernel developers who are willing to consider this driver. The

It isn't a boot loader.  It is the kernel that is running on the switch
when it is doing its switch thing.  The kernel hosts the drivers and the
switch SDK and all the apps that configure and manage the networking.

> kernel community as decided switchdev is how the Linux kernel supports

I'm sure switchdev works very well.  It is not being used in the
environment I am trying to support.  I've checked all 3 NOSs that have
adopted optoe, none of them have switchdev configured in their .config
file:

# CONFIG_NET_SWITCHDEV is not set

> switches. We are unlikely to add drivers for supporting user space
> drivers of switches.

That's not the request.  I'm offering an improved driver to access {Q}SFP
EEPROMs.  It can be easily called by your framework, so the sfp.c users
can also get improved access to the EEPROMs.

As designed it fits the need in the linux based community I'm
working with.  It is in production in two NOSs on three switches.  Less
complete variants of this driver are in production on all three NOSs
I've worked with, on dozens of platforms.  This is real code, that fits
a real need, and would like the benefits of being maintained as part of
the mainline kernel.

> 
> NACK.
> 
> 	Andrew
> 

Don