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:   Tue, 30 Nov 2021 00:47:00 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>, Ido Schimmel <idosch@...sch.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>,
        "pali@...nel.org" <pali@...nel.org>,
        "vadimp@...dia.com" <vadimp@...dia.com>,
        "mlxsw@...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



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Monday, November 29, 2021 9:37 AM
> To: Ido Schimmel <idosch@...sch.org>
> Cc: netdev@...r.kernel.org; davem@...emloft.net; andrew@...n.ch;
> mkubecek@...e.cz; pali@...nel.org; Keller, Jacob E <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.

I also immediately thought of devlink here.

Thanks,
Jake