linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Don Bollinger <don@thebollingers.org>
Cc: 'Jakub Kicinski' <kuba@kernel.org>,
	arndb@arndb.de, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, brandon_chuang@edge-core.com,
	wally_wang@accton.com, aken_liu@edge-core.com,
	gulv@microsoft.com, jolevequ@microsoft.com,
	xinxliu@microsoft.com, 'netdev' <netdev@vger.kernel.org>,
	'Moshe Shemesh' <moshe@nvidia.com>
Subject: Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS
Date: Fri, 12 Mar 2021 20:59:41 +0100	[thread overview]
Message-ID: <YEvILa9FK8qQs5QK@lunn.ch> (raw)
In-Reply-To: <018701d71772$7b0ba3f0$7122ebd0$@thebollingers.org>

> 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 access to the optoe managed file in 
> /sys/bus/i2c/devices/{num}-0050/eeprom.

And this python stack is all open source? So you should be able to
throw 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 working with out of tree code knows what gets merged
later is going to be different because of review comments. And KAPI
code is even more likely to be different. So nobody really expected
optoe to get merged as is.

> You're not going to like this, but ethtool -e and ethtool -m both
> return ' Ethernet0 Cannot get EEPROM data: Operation not supported',
> for every port managed by the big switch silicon.

You are still missing what i said. The existing IOCTL interface needs
a network interface name. But there is no reason why you cannot extend
the new netlink KAPI to take an alternative identifier, sfp42. That
maps directly to the SFP device, without using an interface name. Your
pile of python can directly use the netlink API, the ethtool command
does not need to make use of this form of identifier, and you don't
need to "screen scrape" ethtool.

It seems very unlikely optoe is going to get merged. The network
maintainers are against it, due to KAPI issues. I'm trying to point
out a path you can take to get code merged. But it is up to you if you
decided to follow it.

	Andrew

  reply	other threads:[~2021-03-12 20:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-15 19:38 [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS Don Bollinger
2021-02-26 22:34 ` Andrew Lunn
2021-02-27  2:46   ` Don Bollinger
2021-02-27 16:23     ` Andrew Lunn
2021-03-01 20:00     ` Don Bollinger
2021-03-01 20:45       ` Andrew Lunn
2021-03-05 19:07         ` Don Bollinger
2021-03-05 22:55           ` Jakub Kicinski
2021-03-06  2:30             ` Don Bollinger
2021-03-06  3:31               ` Andrew Lunn
2021-03-12 19:04                 ` Don Bollinger
2021-03-12 19:59                   ` Andrew Lunn [this message]
2021-03-13 21:35                     ` Don Bollinger
2021-03-15 17:39                       ` Jakub Kicinski
2021-03-15 18:09                         ` Don Bollinger
2021-03-17 18:15                           ` Andrew Lunn
2021-03-20 16:10                             ` Pali Rohár
2021-03-26 18:43                               ` Don Bollinger
2021-03-29 22:13                                 ` Pali Rohár
2021-03-23 20:32                             ` Don Bollinger
2021-03-23 22:29                               ` Andrew Lunn
2021-03-26 18:43                                 ` Don Bollinger
2021-03-26 19:46                                   ` Andrew Lunn
2021-03-26 20:16                                     ` Don Bollinger
2021-03-26 20:37                                       ` Andrew Lunn
2021-03-26 21:09                                         ` Don Bollinger
2021-03-26 21:54                                           ` Andrew Lunn
2021-03-26 22:30                                             ` Don Bollinger
2021-03-27 15:25                                               ` Andrew Lunn
2021-03-27 21:20                                                 ` Don Bollinger
2021-03-27 12:40                                           ` Greg KH
2021-03-23 14:12 ` Greg KH
2021-03-23 18:43   ` Don Bollinger
2021-03-23 18:59     ` 'Greg KH'
2021-03-23 19:08       ` Don Bollinger
2021-03-23 19:12         ` 'Greg KH'

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YEvILa9FK8qQs5QK@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=aken_liu@edge-core.com \
    --cc=arndb@arndb.de \
    --cc=brandon_chuang@edge-core.com \
    --cc=don@thebollingers.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gulv@microsoft.com \
    --cc=jolevequ@microsoft.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=moshe@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=wally_wang@accton.com \
    --cc=xinxliu@microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).