> > What I have works. Your consumers get quirk handling, mine don't need
it.
> > No compromise.
>
> Hi Don
>
> All this discussion is now a mute point. GregKH has spoken.
Ack. I actually checked in with Greg a couple of days ago and got that
answer. I just thought the discussion was going in
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Friday, March 26, 2021 2:54 PM
> To: Don Bollinger
> Cc: 'Jakub Kicinski' ; ar...@arndb.de;
> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> brandon_chu...@edge-
On Fri, Mar 26, 2021 at 01:37PM -0700, Andrew Lunn wrote:
> On Fri, Mar 26, 2021 at 01:16:14PM -0700, Don Bollinger wrote:
> > > > In my community, the SFP/QSFP/CMIS devices (32 to 128 of them per
> > > > switch) often cost more than the switch itself. Consumer
> > In my community, the SFP/QSFP/CMIS devices (32 to 128 of them per
> > switch) often cost more than the switch itself. Consumers (both
> > vendors and
> > customers) extensively test these devices to ensure correct and
> > reliable operation. Then they buy them literally by the millions.
> > Q
> > > Our experience is that a number of SFPs are broken, they don't
> > > follow the standard. Some you cannot perform more than 16 bytes
> > > reads without them locking up. Others will perform a 16 byte read,
> > > but only give you one
> > useful
> > > byte of data. So you have to read enough o
> Hello Don!
>
> I have read whole discussion and your EEPROM patch proposal. But for me it
> looks like some kernel glue code for some old legacy / proprietary access
> method which does not have any usage outside of that old code.
I don't know if 'kernel glue code' is good or bad. It is a driv
> > I have offered, in every response, to collaborate with the simple
> > integration to use optoe as the default upstream driver to access the
> > module EEPROMs. optoe would be superior to the existing default
> > routines in sfp.c
>
> Actually, i'm not sure they would be. Since the KAPI issues
On Tue, Mar 23, 2021 at 12:00AM -0700, Greg KH wrote:
> On Tue, Mar 23, 2021 at 11:43:55AM -0700, Don Bollinger wrote:
> > On Tue, Mar 23, 2021 at 7:12AM-0700, Greg KH wrote:
> > > On Mon, Feb 15, 2021 at 11:38:21AM -0800, Don Bollinger wrote:
> > > > optoe is an
On Tue, Mar 23, 2021 at 7:12AM-0700, Greg KH wrote:
> On Mon, Feb 15, 2021 at 11:38:21AM -0800, 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 th
On Mon, 15 Mar 2021 10:40 -0800 Jakub Kicinski wrote:
> On Sat, 13 Mar 2021 13:35:56 -0800 Don Bollinger wrote:
> > > away parts of the bottom end and replace it with a different KAPI,
> > > and nobody will notice? In fact, this is probably how it was
> > > desi
> > This interface is implemented in python scripts provided by the switch
> > platform vendor. Those scripts encode the mapping of CPLD i2c muxes
> > to i2c buses to port numbers, specific to each switch.
> >
> > At the bottom of that python stack, all EEPROM access goes through
> > open/seek/rea
On Fri, 5 Mar 2021 19:32 -0800 Andrew Lunn wrote:
> > I am proposing acceptance of a commonly used implementation for
> > accessing SFPs because the one used by the netdev/netlink community
> > does not fit the architecture of the white box NOS/switch community.
>
> Please could you expand on this
On Fri, 5 Mar 2021 2:55 PM -0800 Jakub Kicinski wrote:
> On Fri, 5 Mar 2021 11:07:08 -0800 Don Bollinger wrote:
> > Acknowledging your objections, I nonetheless request that optoe be
> > accepted into upstream as an eeprom driver in drivers/misc/eeprom. It
> > is a legi
On Mon, Mar 1, 2021 at 12:46 PM-0800, Andrew Lunn wrote:
> > To be more specific, optoe is only replacing the functionality of
> > drivers/net/phy/sfp.c, the functions of sfp_i2c_read() and
sfp_i2c_write().
> > These are the routines at the very bottom of the ethtool stack that
> > actually execute
On Fri, Feb 26, 2021 at 6:46 PM -0800, Don Bollinger wrote:
> On Fri, Feb 26, 2021 at 2:35 PM -0800, Andrew Lunn wrote:
> > On Mon, Feb 15, 2021 at 11:38:21AM -0800, Don Bollinger wrote:
> > > optoe is an i2c based driver that supports read/write access to all
> > >
On Fri, Feb 26, 2021 at 2:35 PM -0800, Andrew Lunn wrote:
> On Mon, Feb 15, 2021 at 11:38:21AM -0800, 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
> >
le to user space and kernel consumers via the
nvmem interface.
optoe devices can be configured via device tree or the 'new_device'
paradigm.
See Documentation/misc-devices/optoe.rst for details on configuring
optoe and accessing the EEPROM.
Signed-off-by: Don Bollinger
---
Ch
le to user space and kernel consumers via the
nvmem interface.
optoe devices can be configured via device tree or the 'new_device'
paradigm.
See Documentation/misc-devices/optoe.rst for details on configuring
optoe and accessing the EEPROM.
Signed-off-by: Don Bollinger
---
Documentat
On Thu, Jun 14, 2018 at 09:46:36AM +0200, Arnd Bergmann wrote:
> On Thu, Jun 14, 2018 at 2:40 AM, Don Bollinger wrote:
> > On Mon, Jun 11, 2018 at 03:43:02PM +0200, Arnd Bergmann wrote:
> >> On Mon, Jun 11, 2018 at 6:25 AM, Don Bollinger
> >> wrote:
>
> >&g
On Mon, Jun 11, 2018 at 03:43:02PM +0200, Arnd Bergmann wrote:
> On Mon, Jun 11, 2018 at 6:25 AM, 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 t
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 s
On Sun, Jun 10, 2018 at 09:56:00PM -0700, Randy Dunlap wrote:
> Hi,
>
> On 06/10/2018 09:25 PM, Don Bollinger wrote:
> > diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig
> > index 68a1ac929917..9a08e12756ee 100644
> > --- a/drivers/misc/eeprom/Kco
ement 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
---
Why should this driver be in the Linux kernel? SFP and QSFP devices plug
into swit
23 matches
Mail list logo
