[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADiuDATAsP7cvxmV9d8=P0j=75XRxvX3jm32d6PQ_Wqv8NR_6Q@mail.gmail.com>
Date: Mon, 6 Feb 2023 20:06:31 +0100
From: Christian Svensson <christian@....nu>
To: mkubecek@...e.cz
Cc: netdev@...r.kernel.org, Viktor Ekmark <viktor@...ark.se>
Subject: ethtool's eeprom_parse fails to determine plug type due to short read
Hi,
I am currently running a system with an Intel E810 ("ice") card as
well as 2x QSFP28 transceivers made by ColorChip.
The behavior I am observing for these modules is that they return
zeroed data unless the read length is greater than 8.
$ sudo ethtool -m ens1f1 hex on length 8
Offset Values
------ ------
0x0000: 00 00 00 00 00 00 00 00
$ sudo ethtool -m ens1f1 hex on length 9
Offset Values
------ ------
0x0000: 11 07 02 00 00 00 00 00 00
eeprom_parse uses a 1-byte read to determine the type of module. This
obviously fails in this case and the function resorts to printing an
hex dump - which ironically contains the correct EEPROM data.
I can see three options to handle this case:
1) Continue using 1-byte read, let ethtool be broken for these types
of modules (the current state)
2) Switch to using e.g. a 16 byte read. Might break other modules?
3) Use a 1-byte read, and if it returns zero as the type byte, retry
with e.g. a 16 byte read to see if that works better.
Thoughts?
Regards,
Powered by blists - more mailing lists