[PATCH net-next 0/5] Expose more port stats to ethtool

[PATCH net-next 0/5] Expose more port stats to ethtool

[Eric Joyner]

Newer hardware collects a lot more FEC statistics than older hardware; these
include FEC histograms and corrected/uncorrected word and bit totals. This
patchset adds plumbing to pass these through to ethtool along with another
link_down_count stat that is another port-level stat. That link_down_count was
already being sent to the driver; it just wasn't exposed outside of the driver.

Brett's patch is a small unrelated improvement to devcmd handling that's
still nice to have.

Brett Creeley (1):
  ionic: Small improvements in devcmd retry logic

Eric Joyner (4):
  ionic: Report "link_down_events_phy" in ethtool statistics
  ionic: Update ionic_if.h with new extra port stats structure
  ionic: Report rx_bits_phy stat to ethtool
  ionic: Add .get_fec_stats ethtool handler

 .../ethernet/pensando/ionic/ionic_ethtool.c   | 51 +++++++++++++++++++
 .../net/ethernet/pensando/ionic/ionic_if.h    | 13 +++--
 .../net/ethernet/pensando/ionic/ionic_main.c  |  7 ++-
 .../net/ethernet/pensando/ionic/ionic_stats.c | 18 ++++++-
 4 files changed, 84 insertions(+), 5 deletions(-)


base-commit: 09942ddedcb960f9e78fd817ec33f501d1040c5b
-- 
2.17.1

[PATCH net-next 1/5] ionic: Small improvements in devcmd retry logic

[Eric Joyner]

From: Brett Creeley <brett.creeley@amd.com>

If the timeout time is hit when the last attempt returned EAGAIN, the
driver returns -ETIMEDOUT. This causes the -EAGAIN result to be lost.
Fix this by returning -EAGAIN if the timeout time is hit and the
previous result matches.

Also, reduce the sleep between the write to done and doorbell
registers. The msleep(1000) was initially added in an arbitrary
manner. However, this long of a sleep is problematic because
it reduces the number of retries when -EAGAIN is returned, which
may result in the devmcd giving up early due to the timeout. Fix
this by reducing the sleep to msleep(50).

Signed-off-by: Brett Creeley <brett.creeley@amd.com>
Signed-off-by: Eric Joyner <eric.joyner@amd.com>
---
 drivers/net/ethernet/pensando/ionic/ionic_main.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/pensando/ionic/ionic_main.c b/drivers/net/ethernet/pensando/ionic/ionic_main.c
index 3c5200e2fdb7..92f2ec0bd5af 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_main.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_main.c
@@ -554,6 +554,11 @@ static int __ionic_dev_cmd_wait(struct ionic *ionic, unsigned long max_seconds,
 
 	if (!done && !time_before(jiffies, max_wait)) {
 		ionic_dev_cmd_clean(ionic);
+
+		/* allow caller to manage EAGAIN from previous attempt */
+		if (err == IONIC_RC_EAGAIN)
+			return -EAGAIN;
+
 		dev_warn(ionic->dev, "DEVCMD %s (%d) timeout after %ld secs\n",
 			 ionic_opcode_to_str(opcode), opcode, max_seconds);
 		return -ETIMEDOUT;
@@ -568,7 +573,7 @@ static int __ionic_dev_cmd_wait(struct ionic *ionic, unsigned long max_seconds,
 				ionic_error_to_str(err), err);
 
 			iowrite32(0, &idev->dev_cmd_regs->done);
-			msleep(1000);
+			msleep(50);
 			iowrite32(1, &idev->dev_cmd_regs->doorbell);
 			goto try_again;
 		}
-- 
2.17.1

Re: [PATCH net-next 1/5] ionic: Small improvements in devcmd retry logic

[Jakub Kicinski]

On Thu, 30 Apr 2026 20:15:51 -0700 Eric Joyner wrote:
> If the timeout time is hit when the last attempt returned EAGAIN, the
> driver returns -ETIMEDOUT. This causes the -EAGAIN result to be lost.
> Fix this by returning -EAGAIN if the timeout time is hit and the
> previous result matches.
> 
> Also, reduce the sleep between the write to done and doorbell
> registers. The msleep(1000) was initially added in an arbitrary
> manner. However, this long of a sleep is problematic because
> it reduces the number of retries when -EAGAIN is returned, which
> may result in the devmcd giving up early due to the timeout. Fix
> this by reducing the sleep to msleep(50).

It would be useful to explain the significance of the return value 
to the callers. Are you trying to return EAGAIN to user space?
Or some kernel-internal function catches this?

Re: [PATCH net-next 1/5] ionic: Small improvements in devcmd retry logic

[Eric Joyner]

On 5/1/2026 4:37 PM, Jakub Kicinski wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> On Thu, 30 Apr 2026 20:15:51 -0700 Eric Joyner wrote:
>> If the timeout time is hit when the last attempt returned EAGAIN, the
>> driver returns -ETIMEDOUT. This causes the -EAGAIN result to be lost.
>> Fix this by returning -EAGAIN if the timeout time is hit and the
>> previous result matches.
>>
>> Also, reduce the sleep between the write to done and doorbell
>> registers. The msleep(1000) was initially added in an arbitrary
>> manner. However, this long of a sleep is problematic because
>> it reduces the number of retries when -EAGAIN is returned, which
>> may result in the devmcd giving up early due to the timeout. Fix
>> this by reducing the sleep to msleep(50).
> 
> It would be useful to explain the significance of the return value
> to the callers. Are you trying to return EAGAIN to user space?
> Or some kernel-internal function catches this?

It looks like the -EAGAIN return value used here would have been used by
"[PATCH net 1/7] ionic: Allow the first devcmd to trigger deferred probe" [1];
this change got put in this series because we decided it was more of a net-next
change rather than a net change, but didn't realize these two were more
connected than what we saw at first glance.

1: https://lore.kernel.org/netdev/20260429210007.40015-2-eric.joyner@amd.com/

 - Eric

[PATCH net-next 2/5] ionic: Report "link_down_events_phy" in ethtool statistics

[Eric Joyner]

The number of times that link has gone down at the port level is tracked
by the firmware and sent to the driver via regular DMA writes to an
instance of struct ionic_port_status in the driver's memory.

This statistic was never reported, but it is useful for diagnostics, so
add it to the "ethtool -S` stats output, grouped with the other
port-level stats that are contained in struct ionic_port_stats.

Assisted-by: Claude:claude-4.6-sonnet
Signed-off-by: Eric Joyner <eric.joyner@amd.com>
---
 drivers/net/ethernet/pensando/ionic/ionic_stats.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/pensando/ionic/ionic_stats.c b/drivers/net/ethernet/pensando/ionic/ionic_stats.c
index 0107599a9dd4..8f39f687a39f 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_stats.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_stats.c
@@ -167,6 +167,7 @@ static const struct ionic_stat_desc ionic_rx_stats_desc[] = {
 #define IONIC_NUM_PORT_STATS ARRAY_SIZE(ionic_port_stats_desc)
 #define IONIC_NUM_TX_STATS ARRAY_SIZE(ionic_tx_stats_desc)
 #define IONIC_NUM_RX_STATS ARRAY_SIZE(ionic_rx_stats_desc)
+#define IONIC_NUM_EXTRA_PORT_STATS	1
 
 #define MAX_Q(lif)   ((lif)->netdev->real_num_tx_queues)
 
@@ -243,7 +244,7 @@ static u64 ionic_sw_stats_get_count(struct ionic_lif *lif)
 		rx_queues += 1;
 
 	total += IONIC_NUM_LIF_STATS;
-	total += IONIC_NUM_PORT_STATS;
+	total += IONIC_NUM_PORT_STATS + IONIC_NUM_EXTRA_PORT_STATS;
 
 	total += tx_queues * IONIC_NUM_TX_STATS;
 	total += rx_queues * IONIC_NUM_RX_STATS;
@@ -280,6 +281,7 @@ static void ionic_sw_stats_get_strings(struct ionic_lif *lif, u8 **buf)
 
 	for (i = 0; i < IONIC_NUM_PORT_STATS; i++)
 		ethtool_puts(buf, ionic_port_stats_desc[i].name);
+	ethtool_puts(buf, "link_down_events_phy");
 
 	for (q_num = 0; q_num < MAX_Q(lif); q_num++)
 		ionic_sw_stats_get_tx_strings(lif, buf, q_num);
@@ -341,6 +343,8 @@ static void ionic_sw_stats_get_values(struct ionic_lif *lif, u64 **buf)
 					     &ionic_port_stats_desc[i]);
 		(*buf)++;
 	}
+	**buf = le16_to_cpu(lif->ionic->idev.port_info->status.link_down_count);
+	(*buf)++;
 
 	for (q_num = 0; q_num < MAX_Q(lif); q_num++)
 		ionic_sw_stats_get_txq_values(lif, buf, q_num);
-- 
2.17.1

Re: [PATCH net-next 2/5] ionic: Report "link_down_events_phy" in ethtool statistics

[Jakub Kicinski]

On Thu, 30 Apr 2026 20:15:52 -0700 Eric Joyner wrote:
> The number of times that link has gone down at the port level is tracked
> by the firmware and sent to the driver via regular DMA writes to an
> instance of struct ionic_port_status in the driver's memory.
> 
> This statistic was never reported, but it is useful for diagnostics, so
> add it to the "ethtool -S` stats output, grouped with the other
> port-level stats that are contained in struct ionic_port_stats.

We have a standard stat for this:

struct ethtool_link_ext_stats {
	/* Custom Linux statistic for PHY level link down events.
	 * In a simpler world it should be equal to netdev->carrier_down_count
	 * unfortunately netdev also counts local reconfigurations which don't
	 * actually take the physical link down, not to mention NC-SI which,
	 * if present, keeps the link up regardless of host state.
	 * This statistic counts when PHY _actually_ went down, or lost link.
	 *
	 * Note that we need u64 for ethtool_stats_init() and comparisons
	 * to ETHTOOL_STAT_NOT_SET, but only u32 is exposed to the user.
	 */
	u64 link_down_events;
};


IOW the definition of this stat is - ignoring asymetric link faults
this counter should match between link partners.

Re: [PATCH net-next 2/5] ionic: Report "link_down_events_phy" in ethtool statistics

[Eric Joyner]

On 5/1/2026 4:39 PM, Jakub Kicinski wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> On Thu, 30 Apr 2026 20:15:52 -0700 Eric Joyner wrote:
>> The number of times that link has gone down at the port level is tracked
>> by the firmware and sent to the driver via regular DMA writes to an
>> instance of struct ionic_port_status in the driver's memory.
>>
>> This statistic was never reported, but it is useful for diagnostics, so
>> add it to the "ethtool -S` stats output, grouped with the other
>> port-level stats that are contained in struct ionic_port_stats.
> 
> We have a standard stat for this:
> 
> struct ethtool_link_ext_stats {
>         /* Custom Linux statistic for PHY level link down events.
>          * In a simpler world it should be equal to netdev->carrier_down_count
>          * unfortunately netdev also counts local reconfigurations which don't
>          * actually take the physical link down, not to mention NC-SI which,
>          * if present, keeps the link up regardless of host state.
>          * This statistic counts when PHY _actually_ went down, or lost link.
>          *
>          * Note that we need u64 for ethtool_stats_init() and comparisons
>          * to ETHTOOL_STAT_NOT_SET, but only u32 is exposed to the user.
>          */
>         u64 link_down_events;
> };
> 
> 
> IOW the definition of this stat is - ignoring asymetric link faults
> this counter should match between link partners.

So, this is a little awkward to talk about -- we are already filling out that
field with a stat that's calculated by the driver; there's a task that monitors
link transitions and increments it.

But, I'm not sure if that method exists because of older firmwares or cards not
tracking the link_down_event count for us. So, I didn't want to just overwrite
this stat with the value from firmware because then we'd lose the count on cards
running firmware that doesn't do that counting for us.

So that's one reason why I put the stat in the generic ethtool stats output, and
gave it the slightly different name "link_down_events_phy" to distinguish it
(this also matches Mellanox's name for consistency) from this stat in the struct
you posted. Though reading the doc comment you posted, this new stat really does
belong there.

- Eric

Re: [PATCH net-next 2/5] ionic: Report "link_down_events_phy" in ethtool statistics

[Jakub Kicinski]

On Tue, 5 May 2026 12:53:26 -0700 Eric Joyner wrote:
> > We have a standard stat for this:
> > 
> > struct ethtool_link_ext_stats {
> >         /* Custom Linux statistic for PHY level link down events.
> >          * In a simpler world it should be equal to netdev->carrier_down_count
> >          * unfortunately netdev also counts local reconfigurations which don't
> >          * actually take the physical link down, not to mention NC-SI which,
> >          * if present, keeps the link up regardless of host state.
> >          * This statistic counts when PHY _actually_ went down, or lost link.
> >          *
> >          * Note that we need u64 for ethtool_stats_init() and comparisons
> >          * to ETHTOOL_STAT_NOT_SET, but only u32 is exposed to the user.
> >          */
> >         u64 link_down_events;
> > };
> > 
> > 
> > IOW the definition of this stat is - ignoring asymetric link faults
> > this counter should match between link partners.  
> 
> So, this is a little awkward to talk about -- we are already filling out that
> field with a stat that's calculated by the driver; there's a task that monitors
> link transitions and increments it.
> 
> But, I'm not sure if that method exists because of older firmwares or cards not
> tracking the link_down_event count for us. So, I didn't want to just overwrite
> this stat with the value from firmware because then we'd lose the count on cards
> running firmware that doesn't do that counting for us.
> 
> So that's one reason why I put the stat in the generic ethtool stats output, and
> gave it the slightly different name "link_down_events_phy" to distinguish it
> (this also matches Mellanox's name for consistency) from this stat in the struct
> you posted. Though reading the doc comment you posted, this new stat really does
> belong there.

If the stat is currently filled in with something that does not work as
documented it should be fine to drop it. The counter is optional and
relatively recent. I think it's unlikely that any monitoring will have
a hard dependency on it.

Re: [PATCH net-next 2/5] ionic: Report "link_down_events_phy" in ethtool statistics

[Eric Joyner]

On 5/5/2026 4:21 PM, Jakub Kicinski wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> On Tue, 5 May 2026 12:53:26 -0700 Eric Joyner wrote:
>>> We have a standard stat for this:
>>>
>>> struct ethtool_link_ext_stats {
>>>         /* Custom Linux statistic for PHY level link down events.
>>>          * In a simpler world it should be equal to netdev->carrier_down_count
>>>          * unfortunately netdev also counts local reconfigurations which don't
>>>          * actually take the physical link down, not to mention NC-SI which,
>>>          * if present, keeps the link up regardless of host state.
>>>          * This statistic counts when PHY _actually_ went down, or lost link.
>>>          *
>>>          * Note that we need u64 for ethtool_stats_init() and comparisons
>>>          * to ETHTOOL_STAT_NOT_SET, but only u32 is exposed to the user.
>>>          */
>>>         u64 link_down_events;
>>> };
>>>
>>>
>>> IOW the definition of this stat is - ignoring asymetric link faults
>>> this counter should match between link partners.
>>
>> So, this is a little awkward to talk about -- we are already filling out that
>> field with a stat that's calculated by the driver; there's a task that monitors
>> link transitions and increments it.
>>
>> But, I'm not sure if that method exists because of older firmwares or cards not
>> tracking the link_down_event count for us. So, I didn't want to just overwrite
>> this stat with the value from firmware because then we'd lose the count on cards
>> running firmware that doesn't do that counting for us.
>>
>> So that's one reason why I put the stat in the generic ethtool stats output, and
>> gave it the slightly different name "link_down_events_phy" to distinguish it
>> (this also matches Mellanox's name for consistency) from this stat in the struct
>> you posted. Though reading the doc comment you posted, this new stat really does
>> belong there.
> 
> If the stat is currently filled in with something that does not work as
> documented it should be fine to drop it. The counter is optional and
> relatively recent. I think it's unlikely that any monitoring will have
> a hard dependency on it.

We did some testing internally, and it's safe to replace the link_down_events
stat with the FW generated stat instead of the one the driver calculates. It
gets populated and updated properly by the firmware on all of the hardware we
test on; I'll have that replaced in the v2.

- Eric

[PATCH net-next 3/5] ionic: Update ionic_if.h with new extra port stats structure

[Eric Joyner]

A new structure to report additional statistics from the firmware has
been added to struct ionic_port_info. It currently only contains FEC
related statistics, but new statistics collected by the firmware for
the port would go in it.

Signed-off-by: Eric Joyner <eric.joyner@amd.com>
---
 drivers/net/ethernet/pensando/ionic/ionic_if.h | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/pensando/ionic/ionic_if.h b/drivers/net/ethernet/pensando/ionic/ionic_if.h
index 23d6e2b4791e..52bcc9b11f6c 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_if.h
+++ b/drivers/net/ethernet/pensando/ionic/ionic_if.h
@@ -2855,6 +2855,14 @@ struct ionic_mgmt_port_stats {
 	__le64 frames_tx_pause;
 };
 
+struct ionic_port_extra_stats {
+	__le64 rsfec_correctable_blocks;
+	__le64 rsfec_uncorrectable_blocks;
+	__le64 fec_corrected_bits_total;
+	__le64 rx_bits_phy;
+	__le64 fec_codeword_error_bin[16];
+};
+
 enum ionic_pb_buffer_drop_stats {
 	IONIC_BUFFER_INTRINSIC_DROP = 0,
 	IONIC_BUFFER_DISCARDED,
@@ -2951,6 +2959,7 @@ union ionic_port_identity {
  * @sprom_page17:    Extended Transceiver sprom, page 17
  * @rsvd:            reserved byte(s)
  * @pb_stats:        uplink pb drop stats
+ * @extra_stats:     Extra port statistics data
  */
 struct ionic_port_info {
 	union ionic_port_config config;
@@ -2968,9 +2977,7 @@ struct ionic_port_info {
 		};
 	};
 	u8     rsvd[376];
-
-	/* pb_stats must start at 2k offset */
-	struct ionic_port_pb_stats  pb_stats;
+	struct ionic_port_extra_stats extra_stats;
 };
 
 /*
-- 
2.17.1

Re: [PATCH net-next 3/5] ionic: Update ionic_if.h with new extra port stats structure

[Jakub Kicinski]

On Thu, 30 Apr 2026 20:15:53 -0700 Eric Joyner wrote:
> @@ -2951,6 +2959,7 @@ union ionic_port_identity {
>   * @sprom_page17:    Extended Transceiver sprom, page 17
>   * @rsvd:            reserved byte(s)
>   * @pb_stats:        uplink pb drop stats

Looks like the removed field is left behind in the doc?

> + * @extra_stats:     Extra port statistics data
>   */
>  struct ionic_port_info {
>  	union ionic_port_config config;
> @@ -2968,9 +2977,7 @@ struct ionic_port_info {
>  		};
>  	};
>  	u8     rsvd[376];
> -
> -	/* pb_stats must start at 2k offset */
> -	struct ionic_port_pb_stats  pb_stats;
> +	struct ionic_port_extra_stats extra_stats;
>  };

[PATCH net-next 4/5] ionic: Report rx_bits_phy stat to ethtool

[Eric Joyner]

This stat contains the number of total bits that the PHY has received;
it's useful for BER calculations. Add it to the ethtool stats output.

Signed-off-by: Eric Joyner <eric.joyner@amd.com>
---
 .../net/ethernet/pensando/ionic/ionic_stats.c  | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/pensando/ionic/ionic_stats.c b/drivers/net/ethernet/pensando/ionic/ionic_stats.c
index 8f39f687a39f..f64f52083301 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_stats.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_stats.c
@@ -167,7 +167,7 @@ static const struct ionic_stat_desc ionic_rx_stats_desc[] = {
 #define IONIC_NUM_PORT_STATS ARRAY_SIZE(ionic_port_stats_desc)
 #define IONIC_NUM_TX_STATS ARRAY_SIZE(ionic_tx_stats_desc)
 #define IONIC_NUM_RX_STATS ARRAY_SIZE(ionic_rx_stats_desc)
-#define IONIC_NUM_EXTRA_PORT_STATS	1
+#define IONIC_NUM_EXTRA_PORT_STATS	2
 
 #define MAX_Q(lif)   ((lif)->netdev->real_num_tx_queues)
 
@@ -281,7 +281,9 @@ static void ionic_sw_stats_get_strings(struct ionic_lif *lif, u8 **buf)
 
 	for (i = 0; i < IONIC_NUM_PORT_STATS; i++)
 		ethtool_puts(buf, ionic_port_stats_desc[i].name);
+	/* extra port stats */
 	ethtool_puts(buf, "link_down_events_phy");
+	ethtool_puts(buf, "rx_bits_phy");
 
 	for (q_num = 0; q_num < MAX_Q(lif); q_num++)
 		ionic_sw_stats_get_tx_strings(lif, buf, q_num);
@@ -324,6 +326,17 @@ static void ionic_sw_stats_get_rxq_values(struct ionic_lif *lif, u64 **buf,
 	}
 }
 
+static void ionic_extra_port_stats_get_values(struct ionic_lif *lif, u64 **buf)
+{
+	struct ionic_port_info *port_info = lif->ionic->idev.port_info;
+
+	/* The # of stats added here == IONIC_NUM_EXTRA_PORT_STATS */
+	**buf = le16_to_cpu(port_info->status.link_down_count);
+	(*buf)++;
+	**buf = le64_to_cpu(port_info->extra_stats.rx_bits_phy);
+	(*buf)++;
+}
+
 static void ionic_sw_stats_get_values(struct ionic_lif *lif, u64 **buf)
 {
 	struct ionic_port_stats *port_stats;
@@ -343,8 +356,7 @@ static void ionic_sw_stats_get_values(struct ionic_lif *lif, u64 **buf)
 					     &ionic_port_stats_desc[i]);
 		(*buf)++;
 	}
-	**buf = le16_to_cpu(lif->ionic->idev.port_info->status.link_down_count);
-	(*buf)++;
+	ionic_extra_port_stats_get_values(lif, buf);
 
 	for (q_num = 0; q_num < MAX_Q(lif); q_num++)
 		ionic_sw_stats_get_txq_values(lif, buf, q_num);
-- 
2.17.1

[PATCH net-next 5/5] ionic: Add .get_fec_stats ethtool handler

[Eric Joyner]

Several FEC error statistics being collected can be reported in a
dedicated ethtool callback for FEC errors, so implement the handler that
does so. This includes 802.3ck FEC histogram data that some newer
hardware collects.

Assisted-by: Claude:claude-4.6-sonnet
Signed-off-by: Eric Joyner <eric.joyner@amd.com>
---
 .../ethernet/pensando/ionic/ionic_ethtool.c   | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c b/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
index 78a802eb159f..fe1f753b6115 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
@@ -418,6 +418,56 @@ static int ionic_get_fecparam(struct net_device *netdev,
 	return 0;
 }
 
+static const struct ethtool_fec_hist_range ionic_fec_ranges[] = {
+	{ 0, 0},
+	{ 1, 1},
+	{ 2, 2},
+	{ 3, 3},
+	{ 4, 4},
+	{ 5, 5},
+	{ 6, 6},
+	{ 7, 7},
+	{ 8, 8},
+	{ 9, 9},
+	{ 10, 10},
+	{ 11, 11},
+	{ 12, 12},
+	{ 13, 13},
+	{ 14, 14},
+	{ 15, 15},
+	{ 0, 0},
+};
+
+static void
+ionic_fill_fec_hist(const struct ionic_port_extra_stats *extra_stats,
+		    struct ethtool_fec_hist *hist)
+{
+	int i;
+
+	hist->ranges = ionic_fec_ranges;
+	for (i = 0; i < ETHTOOL_FEC_HIST_MAX - 1; i++)
+		hist->values[i].sum = extra_stats->fec_codeword_error_bin[i];
+}
+
+static void ionic_get_fec_stats(struct net_device *netdev,
+				struct ethtool_fec_stats *fec_stats,
+				struct ethtool_fec_hist *hist)
+{
+	struct ionic_port_extra_stats *extra_stats;
+	struct ionic_lif *lif = netdev_priv(netdev);
+
+	extra_stats = &lif->ionic->idev.port_info->extra_stats;
+
+	fec_stats->corrected_blocks.total =
+		le64_to_cpu(extra_stats->rsfec_correctable_blocks);
+	fec_stats->uncorrectable_blocks.total =
+		le64_to_cpu(extra_stats->rsfec_uncorrectable_blocks);
+	fec_stats->corrected_bits.total =
+		le64_to_cpu(extra_stats->fec_corrected_bits_total);
+
+	ionic_fill_fec_hist(extra_stats, hist);
+}
+
 static int ionic_set_fecparam(struct net_device *netdev,
 			      struct ethtool_fecparam *fec)
 {
@@ -1154,6 +1204,7 @@ static const struct ethtool_ops ionic_ethtool_ops = {
 	.get_module_eeprom_by_page	= ionic_get_module_eeprom_by_page,
 	.get_pauseparam		= ionic_get_pauseparam,
 	.set_pauseparam		= ionic_set_pauseparam,
+	.get_fec_stats		= ionic_get_fec_stats,
 	.get_fecparam		= ionic_get_fecparam,
 	.set_fecparam		= ionic_set_fecparam,
 	.get_ts_info		= ionic_get_ts_info,
-- 
2.17.1

Re: [PATCH net-next 5/5] ionic: Add .get_fec_stats ethtool handler

[Jakub Kicinski]

On Thu, 30 Apr 2026 20:15:55 -0700 Eric Joyner wrote:
> Several FEC error statistics being collected can be reported in a
> dedicated ethtool callback for FEC errors, so implement the handler that
> does so. This includes 802.3ck FEC histogram data that some newer
> hardware collects.

sparse says:

drivers/net/ethernet/pensando/ionic/ionic_ethtool.c:449:37: warning: incorrect type in assignment (different base types)
drivers/net/ethernet/pensando/ionic/ionic_ethtool.c:449:37:    expected unsigned long long [usertype] sum
drivers/net/ethernet/pensando/ionic/ionic_ethtool.c:449:37:    got restricted __le64 const

Re: [PATCH net-next 5/5] ionic: Add .get_fec_stats ethtool handler

[Eric Joyner]

On 5/1/2026 4:41 PM, Jakub Kicinski wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> On Thu, 30 Apr 2026 20:15:55 -0700 Eric Joyner wrote:
>> Several FEC error statistics being collected can be reported in a
>> dedicated ethtool callback for FEC errors, so implement the handler that
>> does so. This includes 802.3ck FEC histogram data that some newer
>> hardware collects.
> 
> sparse says:
> 
> drivers/net/ethernet/pensando/ionic/ionic_ethtool.c:449:37: warning: incorrect type in assignment (different base types)
> drivers/net/ethernet/pensando/ionic/ionic_ethtool.c:449:37:    expected unsigned long long [usertype] sum
> drivers/net/ethernet/pensando/ionic/ionic_ethtool.c:449:37:    got restricted __le64 const

Yeah, I'm missing a cpu_to_le64(); I'll add it in the next version of this patchset.

- Eric

Re: [PATCH net-next 5/5] ionic: Add .get_fec_stats ethtool handler

[Vadim Fedorenko]

On 01/05/2026 04:15, Eric Joyner wrote:
> Several FEC error statistics being collected can be reported in a
> dedicated ethtool callback for FEC errors, so implement the handler that
> does so. This includes 802.3ck FEC histogram data that some newer
> hardware collects.
> 
> Assisted-by: Claude:claude-4.6-sonnet
> Signed-off-by: Eric Joyner <eric.joyner@amd.com>
> ---
>   .../ethernet/pensando/ionic/ionic_ethtool.c   | 51 +++++++++++++++++++
>   1 file changed, 51 insertions(+)
> 
> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c b/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
> index 78a802eb159f..fe1f753b6115 100644
> --- a/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
> +++ b/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
> @@ -418,6 +418,56 @@ static int ionic_get_fecparam(struct net_device *netdev,
>   	return 0;
>   }
>   
> +static const struct ethtool_fec_hist_range ionic_fec_ranges[] = {
> +	{ 0, 0},
> +	{ 1, 1},
> +	{ 2, 2},
> +	{ 3, 3},
> +	{ 4, 4},
> +	{ 5, 5},
> +	{ 6, 6},
> +	{ 7, 7},
> +	{ 8, 8},
> +	{ 9, 9},
> +	{ 10, 10},
> +	{ 11, 11},
> +	{ 12, 12},
> +	{ 13, 13},
> +	{ 14, 14},
> +	{ 15, 15},
> +	{ 0, 0},
> +};
> +
> +static void
> +ionic_fill_fec_hist(const struct ionic_port_extra_stats *extra_stats,
> +		    struct ethtool_fec_hist *hist)
> +{
> +	int i;
> +
> +	hist->ranges = ionic_fec_ranges;
> +	for (i = 0; i < ETHTOOL_FEC_HIST_MAX - 1; i++)
> +		hist->values[i].sum = extra_stats->fec_codeword_error_bin[i];
> +}

ETHTOOL_FEC_HIST_MAX = 17, you defined 16 bins, but iterating over 15 of
them. Looks like bin {15, 15} will be lost in stats.

Re: [PATCH net-next 5/5] ionic: Add .get_fec_stats ethtool handler

[Eric Joyner]

On 5/5/2026 6:54 AM, Vadim Fedorenko wrote:
> [You don't often get email from vadim.fedorenko@linux.dev. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
> 
> 
> On 01/05/2026 04:15, Eric Joyner wrote:
>> Several FEC error statistics being collected can be reported in a
>> dedicated ethtool callback for FEC errors, so implement the handler that
>> does so. This includes 802.3ck FEC histogram data that some newer
>> hardware collects.
>>
>> Assisted-by: Claude:claude-4.6-sonnet
>> Signed-off-by: Eric Joyner <eric.joyner@amd.com>
>> ---
>>   .../ethernet/pensando/ionic/ionic_ethtool.c   | 51 +++++++++++++++++++
>>   1 file changed, 51 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c b/drivers/
>> net/ethernet/pensando/ionic/ionic_ethtool.c
>> index 78a802eb159f..fe1f753b6115 100644
>> --- a/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
>> @@ -418,6 +418,56 @@ static int ionic_get_fecparam(struct net_device *netdev,
>>       return 0;
>>   }
>>
>> +static const struct ethtool_fec_hist_range ionic_fec_ranges[] = {
>> +     { 0, 0},
>> +     { 1, 1},
>> +     { 2, 2},
>> +     { 3, 3},
>> +     { 4, 4},
>> +     { 5, 5},
>> +     { 6, 6},
>> +     { 7, 7},
>> +     { 8, 8},
>> +     { 9, 9},
>> +     { 10, 10},
>> +     { 11, 11},
>> +     { 12, 12},
>> +     { 13, 13},
>> +     { 14, 14},
>> +     { 15, 15},
>> +     { 0, 0},
>> +};
>> +
>> +static void
>> +ionic_fill_fec_hist(const struct ionic_port_extra_stats *extra_stats,
>> +                 struct ethtool_fec_hist *hist)
>> +{
>> +     int i;
>> +
>> +     hist->ranges = ionic_fec_ranges;
>> +     for (i = 0; i < ETHTOOL_FEC_HIST_MAX - 1; i++)
>> +             hist->values[i].sum = extra_stats->fec_codeword_error_bin[i];
>> +}
> 
> ETHTOOL_FEC_HIST_MAX = 17, you defined 16 bins, but iterating over 15 of
> them. Looks like bin {15, 15} will be lost in stats.
> 
> 

This looks correct to me -- (ETHTOOL_FEC_HIST_MAX - 1) = 16, so starting with
i=0, it'll iterate through the 16 bins and ignore the 17th end marker bin. Bin
15 does get included and gets its sum set.

- Eric