On Friday 26 March 2021 11:43:10 Don Bollinger wrote:
> > 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.
>
> > 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
> 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.
But i'm sure there are some on the side lines, eating popcorn, maybe
learning from the discussion.
Would you think it is O.K. to add a
On Fri, Mar 26, 2021 at 02:09:36PM -0700, Don Bollinger wrote:
> > You keep missing the point. I always refer to the KAPI. The driver we can
> > rework and rework, throw away and reimplement, as much as we want.
> > The KAPI cannot be changed, it is ABI. It is pretty much frozen the day
> the
> > c
core.com; wally_w...@accton.com;
> aken_...@edge-core.com; g...@microsoft.com; jolev...@microsoft.com;
> xinx...@microsoft.com; 'netdev' ; 'Moshe
> Shemesh'
> Subject: Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS
> EEPROMS
>
> > The onl
> The only thing wrong I can see is that it doesn't use the kernel network
> stack. Here's where "you keep missing the point". The kernel network stack
> is not being used in these systems. Implementing EEPROM access through
> ethtool is of course possible, but it is a lot of work with no benefi
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. Consumers (both
> > > > vendors and
> > > > c
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. Consumers (both
> > > vendors and
> > > customers) extensively test these devices to ensure correct and
> > >
> > 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
> 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. Quirks lead to
>
> > > 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
> > 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 of the EEPROM a b
> > 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:08:32PM -0700, Don Bollinger wrote:
> 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 B
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 i2c based driver that supports read
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 i2c based driver that supports read/write access to all
> > > the pages (tables) of MSA standard
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 the SFF-8472 spec), MSA sta
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 the SFF-8472 spec), MSA standard QSFP and similar devices (conforming
> to the SFF-8636
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.
Your code does not contain any quirks which are needed to read different
E
> 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 are pretty
mu
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
> > > designed. Anybody
> >
> > Actually everyo
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 designed. Anybody
>
> Actually everyone who touches this code would notice, each implementation
> would
> > 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
> 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/read/close a
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
> 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. I've given suggests as to how the new
netlink KAPI could b
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 legitimate driver, with a legiti
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
> legitimate driver, with a legitimate user community, which deserves the
> benefits of being man
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
> 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 the i2c calls to get the data. The existing routines are very
>
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
> > > the pages (tables) of MSA standa
> > I assume you have seen the work NVIDIA submitted last week? This idea of
> > linear pages is really restrictive and we are moving away from it.
>
> No, I haven't seen it. I can't seem to locate anything in the past month on
> LMKL from NVIDIA. Please point me to it.
[RFC PATCH net-next 0/5]
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
> > to the SFF-8472 spec), MS
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 the SFF-8472 spec), MSA standard QSFP and similar devices (conforming
> to the SFF-8636
35 matches
Mail list logo
