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]

Message-ID: <20211129093724.3b76ebff@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 29 Nov 2021 09:37:24 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, andrew@...n.ch,
        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 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.