netdev - Re: [PATCH ethtool-next 0/4] Extend module EEPROM API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 4 May 2021 14:59:29 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Don Bollinger <don@...bollingers.org>
Cc:     'Moshe Shemesh' <moshe@...dia.com>,
        'Michal Kubecek' <mkubecek@...e.cz>,
        'Jakub Kicinski' <kuba@...nel.org>, netdev@...r.kernel.org,
        'Vladyslav Tarasiuk' <vladyslavt@...dia.com>
Subject: Re: [PATCH ethtool-next 0/4] Extend module EEPROM API

> Here we go again...  It is my experience that there are far more
> capabilities in these devices than will ever be captured in ethtool.  Module
> vendors can provide additional value to their customers by putting
> innovative features into their modules, and providing software applications
> to take advantage of those features.  These features don't necessarily
> impact the network stack.  They may be used to draw additional diagnostic
> data from the devices, or to enable management features like flashing
> colored lights built into custom modules.  I've written code to do these and
> more things which are unique to one vendor, and valued by their customers.

Sorry, but not going to happen. Ethernet PHYs can have lots of
addition registers on stop of what 802.3 specifies. Vendors do add
additional functionality. And we do support some of it, like
configuring downshift, energy detect power down, cable diagnostics in
a generic manor. And we are open to adding more such features. People
can contribute code which multiple vendors might implement. We then
have well documented APIs which are the same across different vendors.

For LEDs you should be using the Linux LED class drivers. The Ethernet
PHYs are slowly moving that way. Very slowly :-(

Both MAC and Ethernet PHY drivers have tunables. I would suggest using
this concept, but applied to SFPs. This is how most of the additional
PHY features are supported. But first you need to add an SFP driver
framework, which matches on the fields in the EEPROM to load the
driver specific to an SFP. That then gives you a place to add such
code.

	Andrew