On Thu, 8 Oct 2026 20:02:34 +0200
Roman Khromenok <[email protected]> wrote:
> The module EEPROM decoder shows the identity and the digital
> diagnostics of a module, but not the signal status, which is
> usually the first thing to check when a link does not come up.
>
> Patches 1-2 report the SFF-8636 per-lane loss of signal,
> CDR loss of lock and Tx fault flags, as ethtool does since
> commit 045d8db ("sff-8636: report LOL / LOS / Tx Fault").
> The code is written for DPDK, not copied from ethtool.
>
> Patches 3-4 report the SFF-8472 Rx_LOS and TX_FAULT state
> from page A2h byte 110. ethtool does not show it, so it is
> split out and can be dropped independently of patches 1-2.
>
> The SFF-8636 flags are latched and cleared on read,
> so they report the events since the previous read;
> the SFF-8472 bits are the current state of the pins.
>
> The series depends on the module EEPROM decode API series and on
> the testpmd decode command, which are in next-net but not in main
> yet. It is based on next-net/for-main with patch 170851 applied,
> so the release notes entry no longer conflicts.
>
> Depends-on: series-39436 ("ethdev: add API to decode module EEPROM")
> Depends-on: series-39455 ("ethdev: fix SFF-8472 external Rx power
> calibration")
> Depends-on: series-39480 ("ethdev: fix SFF-8472 calibration overflow")
> Depends-on: patch-170851 ("app/testpmd: add command to decode module EEPROM")
Applied to next-net.
I wonder if the eeprom really belongs in its on library, really it is not
part of standard ethdev.
