> > 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-ker...@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
> 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 o
> From: Vladyslav Tarasiuk
>
> In case netlink get_module_eeprom_by_page() callback is not implemented
> by the driver, try to call old get_module_info() and get_module_eeprom()
> pair. Recalculate parameters to get_module_eeprom() offset and len using
> page number and their sizes. Return error
> > 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
> > > I don't even see a need for this. The offset should be within one
> > > 1/2
> > page, of
> > > one bank. So offset >= 0 and <= 127. Length is also > 0 and
> > > <- 127. And offset+length is <= 127.
> >
> > I like the clean approach, but... How do you request low memory?
>
> Duh!
>
> I got
> Subject: Re: [RFC PATCH V4 net-next 1/5] ethtool: Allow network drivers to
> dump arbitrary EEPROM data
>
> > > +#define ETH_MODULE_EEPROM_PAGE_LEN 256
> >
> > Sorry to keep raising issues, but I think you want to make this
> > constant 128.
>
> Yes, i also think the KAPI should be limite
> From: Vladyslav Tarasiuk
>
> Define get_module_eeprom_by_page() ethtool callback and implement
> netlink infrastructure.
>
> get_module_eeprom_by_page() allows network drivers to dump a part of
> module's EEPROM specified by page and bank numbers along with offset and
> length. It is effective
On 3/16/2021 11:24 AM, Moshe Shemesh wrote:
> On 3/16/2021 12:31 AM, Don Bollinger wrote:
> > On Mon, 15 Mar 2021 10:12:39 +0700 Moshe Shemesh wrote:
> >> From: Vladyslav Tarasiuk
> >>
> >> Define get_module_eeprom_data_by_page() ethtool callback and
&
On Mon, 15 Mar 2021 10:12:39 +0700 Moshe Shemesh wrote:
> From: Vladyslav Tarasiuk
>
> In case netlink get_module_eeprom_data_by_page() callback is not
> implemented by the driver, try to call old get_module_info() and
> get_module_eeprom() pair. Recalculate parameters to
> get_module_eeprom() of
On Mon, 15 Mar 2021 10:12:39 +0700 Moshe Shemesh wrote:
> From: Vladyslav Tarasiuk
>
> Define get_module_eeprom_data_by_page() ethtool callback and
> implement netlink infrastructure.
>
> get_module_eeprom_data_by_page() allows network drivers to dump a
> part of module's EEPROM specified by pag
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
> > --- a/net/ethtool/eeprom.c
> > +++ b/net/ethtool/eeprom.c
> > @@ -26,6 +26,88 @@ struct eeprom_data_reply_data { #define
> > EEPROM_DATA_REPDATA(__reply_base) \
> > container_of(__reply_base, struct eeprom_data_reply_data, base)
> >
> > +static int fallback_set_params(struct eeprom_data_re
> > > +static int fallback_set_params(struct eeprom_data_req_info *request,
> > > +struct ethtool_modinfo *modinfo,
> > > +struct ethtool_eeprom *eeprom) {
> >
> > This is translating the new data structure into the old. Hence, I
> > assume we have i
On Thu, Mar 04, 2021 at 10:57AM-0800, Moshe Shemesh wrote:
> From: Vladyslav Tarasiuk
>
> In case netlink get_module_eeprom_data_by_page() callback is not
> implemented by the driver, try to call old get_module_info() and
> get_module_eeprom() pair. Recalculate parameters to
> get_module_eeprom()
On Thu, Mar 04, 2021 at 10:57AM-0800, Moshe Shemesh wrote:
> From: Vladyslav Tarasiuk
>
> Define get_module_eeprom_data_by_page() ethtool callback and
> implement netlink infrastructure.
>
> get_module_eeprom_data_by_page() allows network drivers to dump a
> part of module's EEPROM specified by
> net/ethtool/eeprom.c | 239 ++++++++++
> net/ethtool/netlink.c | 10 +
> net/ethtool/netlink.h | 2 +
> 10 files changed, 430 insertions(+), 30 deletions(-) create mode 100644
> net/ethtool/eeprom.c
>
> --
> 2.18.2
Don Bollinger
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
> >
On Thu, Jun 21, 2018 at 10:11:27AM +0200, Andrew Lunn wrote:
> > I'm trying to figure out how the netdev environment works on large
> > switches. I can't imagine that the kernel network stack is involved in
> > any part of the data plane.
>
> Hi Don
>
> It is involved in the slow path. I.e. pac
27 matches
Mail list logo
