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] [thread-next>] [day] [month] [year] [list]

Message-ID: <008e01d73e0e$5d6a70c0$183f5240$@thebollingers.org>
Date:   Fri, 30 Apr 2021 15:15:44 -0700
From:   "Don Bollinger" <don@...bollingers.org>
To:     "'Andrew Lunn'" <andrew@...n.ch>
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>,
        <don@...bollingers.org>
Subject: RE: [PATCH ethtool-next 0/4] Extend module EEPROM API

> > There are routine functions to configure the devices that require
> > writing appropriate values to various registers.  Byte 26 allows
> > software control of low power mode, squelch and software reset.  Page
> > 10h is full of Lane and Data Path Control registers.
> 
> These all sounds like foot canons when in user space control. I would
expect
> the MAC and or SFP driver to make use of these features, no need to export
> them to user space, at least not in a raw format. I could however imagine
> ethtool commands to manipulate specific features, passing the request to
> the MAC to perform, so it knows what is going on.
> 
> > Beyond the spec, but allowed by the spec, there are vendor specific
> > capabilities like firmware download that require bulk write (up to 128
> > bytes per write).
> 
> This one is not so easy. Since it is vendor specific, we need to consider
how to
> actually make it vendor generic from Ethtool, or maybe devlink. Maybe code
> in the kernel which matches on the vendor string in the SFP EEPROM, and
> provides a standardized API towards ethtool, and does whatever magic is
> needed towards the SFP. But it gets messy when you don't have direct
> access to the SFP, there is a layer of firmware in the middle, which is
often
> the case.
> 
> 	 Andrew

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.

I'm asking for a generic interface that allows read/write access to
arbitrary registers.  Put the warnings in the documentation, limit access to
it, but make it available.

Don