Thread (30 messages) 30 messages, 5 authors, 2021-03-29

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

flat view

From: Andrew Lunn <andrew@lunn.ch>
Date: 2021-02-27 16:25:55
Also in: lkml

quoted
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: [off-list ref]

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help