netdev - Re: [RFC PATCH net-next 0/4] ethtool: Add ability to flash and query transceiver modules' firmware

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]

Date:   Mon, 29 Nov 2021 17:09:23 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Ido Schimmel <idosch@...sch.org>, netdev@...r.kernel.org,
        davem@...emloft.net, mkubecek@...e.cz, pali@...nel.org,
        jacob.e.keller@...el.com, vadimp@...dia.com, mlxsw@...dia.com,
        Ido Schimmel <idosch@...dia.com>
Subject: Re: [RFC PATCH net-next 0/4] ethtool: Add ability to flash and
 query transceiver modules' firmware

On Tue, 30 Nov 2021 00:50:41 +0100 Andrew Lunn wrote:
> On Mon, Nov 29, 2021 at 09:37:24AM -0800, Jakub Kicinski wrote:
> > On Sat, 27 Nov 2021 19:45:26 +0200 Ido Schimmel wrote:  
> > > This patchset extends the ethtool netlink API to allow user space to
> > > both flash transceiver modules' firmware and query the firmware
> > > information (e.g., version, state).
> > > 
> > > The main use case is CMIS compliant modules such as QSFP-DD. The CMIS
> > > standard specifies the interfaces used for both operations. See section
> > > 7.3.1 in revision 5.0 of the standard [1].
> > > 
> > > Despite the immediate use case being CMIS compliant modules, the user
> > > interface is kept generic enough to accommodate future use cases, if
> > > these arise.
> > > 
> > > The purpose of this RFC is to solicit feedback on both the proposed user
> > > interface and the device driver API which are described in detail in
> > > patches #1 and #3. The netdevsim patches are for RFC purposes only. The
> > > plan is to implement the CMIS functionality in common code (under lib/)
> > > so that it can be shared by MAC drivers that will pass function pointers
> > > to it in order to read and write from their modules EEPROM.
> > > 
> > > ethtool(8) patches can be found here [2].  
> > 
> > Immediate question I have is why not devlink. We purposefully moved 
> > FW flashing to devlink because I may take long, so doing it under
> > rtnl_lock is really bad. Other advantages exist (like flashing
> > non-Ethernet ports). Ethtool netlink already existed at the time.
> > 
> > I think device flashing may also benefit from the infra you're adding.  
> 
> The idea of asynchronous operations without holding RTNL is not that
> new. The cable test code does it, but clearly cable testing is likely
> network specific, unlike FW flashing.

Right, I missed this is async. Presumably since there is a plan for 
a common module the chance of bugs sneaking in will be somewhat lower,
but still flashing FW is flashing FW, would be great if we could align
with device FW flashing as done via devlink.