linux-kernel - Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS

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:   Sat, 27 Feb 2021 17:23:32 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Don Bollinger <don@...bollingers.org>
Cc:     arndb@...db.de, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, brandon_chuang@...e-core.com,
        wally_wang@...ton.com, aken_liu@...e-core.com, gulv@...rosoft.com,
        jolevequ@...rosoft.com, xinxliu@...rosoft.com,
        'netdev' <netdev@...r.kernel.org>
Subject: Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS
 EEPROMS

> > I assume you have seen the work NVIDIA submitted last week? This idea of
> > linear pages is really restrictive and we are moving away from it.
> 
> No, I haven't seen it.  I can't seem to locate anything in the past month on
> LMKL from NVIDIA.  Please point me to it.

[RFC PATCH net-next 0/5] ethtool: Extend module EEPROM dump
Message-Id: <1614181274-28482-1-git-send-email-moshe@...dia.com>

b4 should be able to fetch it for you, using that message id.

Clearly, we don't want two different kernel APIs for doing the same
thing. This new KAPI is still in its early days. You can contribute to
it, and make it work for your use case. If i understand correctly, you
are using Linux as a bootloader, and running the complete switch
driver in userspace, not making use of the Linux network stack. This
is not something the netdev community likes, but if you work within
the networking KAPI, rather than adding parallel KAPI, we can probably
work together. I think the biggest problem you have is identifiers.
Since you don't have the SFP associated to a netdev, the current IOCTL
interface which us the netdev name as an identifier does not work. But
the new code is netlink based. The identifier is just an attribute in
the message. See if you can use an alternative attribute which
directly identifies the SFP, not the netdev. It is O.K. to instantiate
an SFP device and then not make use of it in PHYLINK. So this should
work.

     Andrew