[PATCH v2 net-next 0/3] change some statistics to 64-bit

[PATCH v2 net-next 0/3] change some statistics to 64-bit

[Wei Fang]

The port MAC counters of ENETC are 64-bit registers and the statistics
of ethtool are also u64 type, so add enetc_port_rd64() helper function
to read 64-bit statistics from these registers, and also change the
statistics of ring to unsigned long type to be consistent with the
statistics type in struct net_device_stats.

---
v1 link: https://lore.kernel.org/imx/20250620102140.2020008-1-wei.fang@nxp.com/
v2 changes:
1. Improve the commit message of patch 1
2. Collect Reviewed-by tags
---

Wei Fang (3):
  net: enetc: change the statistics of ring to unsigned long type
  net: enetc: separate 64-bit counters from enetc_port_counters
  net: enetc: read 64-bit statistics from port MAC counters

 drivers/net/ethernet/freescale/enetc/enetc.h  | 22 ++---
 .../ethernet/freescale/enetc/enetc_ethtool.c  | 99 +++++++++++--------
 .../net/ethernet/freescale/enetc/enetc_hw.h   |  1 +
 3 files changed, 68 insertions(+), 54 deletions(-)

-- 
2.34.1

[PATCH v2 net-next 1/3] net: enetc: change the statistics of ring to unsigned long type

[Wei Fang]

The statistics of the ring are all unsigned int type, so the statistics
will overflow quickly under heavy traffic. In addition, the statistics
of struct net_device_stats are obtained from struct enetc_ring_stats,
but the statistics of net_device_stats are unsigned long type. So it is
better to keep the statistics types consistent in these two structures.
Considering these two factors, and the fact that both LS1028A and i.MX95
are arm64 architecture, the statistics of enetc_ring_stats are changed
to unsigned long type. Note that unsigned int and unsigned long are the
same thing on some systems, and on such systems there is no overflow
advantage of one over the other.

Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
 drivers/net/ethernet/freescale/enetc/enetc.h | 22 ++++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc.h b/drivers/net/ethernet/freescale/enetc/enetc.h
index 872d2cbd088b..62e8ee4d2f04 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc.h
@@ -96,17 +96,17 @@ struct enetc_rx_swbd {
 #define ENETC_TXBDS_MAX_NEEDED(x)	ENETC_TXBDS_NEEDED((x) + 1)
 
 struct enetc_ring_stats {
-	unsigned int packets;
-	unsigned int bytes;
-	unsigned int rx_alloc_errs;
-	unsigned int xdp_drops;
-	unsigned int xdp_tx;
-	unsigned int xdp_tx_drops;
-	unsigned int xdp_redirect;
-	unsigned int xdp_redirect_failures;
-	unsigned int recycles;
-	unsigned int recycle_failures;
-	unsigned int win_drop;
+	unsigned long packets;
+	unsigned long bytes;
+	unsigned long rx_alloc_errs;
+	unsigned long xdp_drops;
+	unsigned long xdp_tx;
+	unsigned long xdp_tx_drops;
+	unsigned long xdp_redirect;
+	unsigned long xdp_redirect_failures;
+	unsigned long recycles;
+	unsigned long recycle_failures;
+	unsigned long win_drop;
 };
 
 struct enetc_xdp_data {
-- 
2.34.1

Re: [PATCH v2 net-next 1/3] net: enetc: change the statistics of ring to unsigned long type

[Frank Li]

On Tue, Jun 24, 2025 at 06:15:46PM +0800, Wei Fang wrote:
> The statistics of the ring are all unsigned int type, so the statistics
> will overflow quickly under heavy traffic. In addition, the statistics
> of struct net_device_stats are obtained from struct enetc_ring_stats,
> but the statistics of net_device_stats are unsigned long type. So it is
> better to keep the statistics types consistent in these two structures.
> Considering these two factors, and the fact that both LS1028A and i.MX95
> are arm64 architecture, the statistics of enetc_ring_stats are changed
> to unsigned long type. Note that unsigned int and unsigned long are the
> same thing on some systems, and on such systems there is no overflow
> advantage of one over the other.
>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>

Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
>  drivers/net/ethernet/freescale/enetc/enetc.h | 22 ++++++++++----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc.h b/drivers/net/ethernet/freescale/enetc/enetc.h
> index 872d2cbd088b..62e8ee4d2f04 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc.h
> +++ b/drivers/net/ethernet/freescale/enetc/enetc.h
> @@ -96,17 +96,17 @@ struct enetc_rx_swbd {
>  #define ENETC_TXBDS_MAX_NEEDED(x)	ENETC_TXBDS_NEEDED((x) + 1)
>
>  struct enetc_ring_stats {
> -	unsigned int packets;
> -	unsigned int bytes;
> -	unsigned int rx_alloc_errs;
> -	unsigned int xdp_drops;
> -	unsigned int xdp_tx;
> -	unsigned int xdp_tx_drops;
> -	unsigned int xdp_redirect;
> -	unsigned int xdp_redirect_failures;
> -	unsigned int recycles;
> -	unsigned int recycle_failures;
> -	unsigned int win_drop;
> +	unsigned long packets;
> +	unsigned long bytes;
> +	unsigned long rx_alloc_errs;
> +	unsigned long xdp_drops;
> +	unsigned long xdp_tx;
> +	unsigned long xdp_tx_drops;
> +	unsigned long xdp_redirect;
> +	unsigned long xdp_redirect_failures;
> +	unsigned long recycles;
> +	unsigned long recycle_failures;
> +	unsigned long win_drop;
>  };
>
>  struct enetc_xdp_data {
> --
> 2.34.1
>

Re: [PATCH v2 net-next 1/3] net: enetc: change the statistics of ring to unsigned long type

[Simon Horman]

On Tue, Jun 24, 2025 at 06:15:46PM +0800, Wei Fang wrote:
> The statistics of the ring are all unsigned int type, so the statistics
> will overflow quickly under heavy traffic. In addition, the statistics
> of struct net_device_stats are obtained from struct enetc_ring_stats,
> but the statistics of net_device_stats are unsigned long type. So it is
> better to keep the statistics types consistent in these two structures.
> Considering these two factors, and the fact that both LS1028A and i.MX95
> are arm64 architecture, the statistics of enetc_ring_stats are changed
> to unsigned long type. Note that unsigned int and unsigned long are the
> same thing on some systems, and on such systems there is no overflow
> advantage of one over the other.
> 
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH v2 net-next 2/3] net: enetc: separate 64-bit counters from enetc_port_counters

[Wei Fang]

Some counters in enetc_port_counters are 32-bit registers, and some are
64-bit registers. But in the current driver, they are all read through
enetc_port_rd(), which can only read a 32-bit value. Therefore, separate
64-bit counters (enetc_pm_counters) from enetc_port_counters and use
enetc_port_rd64() to read the 64-bit statistics.

Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
 .../net/ethernet/freescale/enetc/enetc_ethtool.c  | 15 ++++++++++++++-
 drivers/net/ethernet/freescale/enetc/enetc_hw.h   |  1 +
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
index 2e5cef646741..2c9aa94c8e3d 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
@@ -142,7 +142,7 @@ static const struct {
 static const struct {
 	int reg;
 	char name[ETH_GSTRING_LEN] __nonstring;
-} enetc_port_counters[] = {
+} enetc_pm_counters[] = {
 	{ ENETC_PM_REOCT(0),	"MAC rx ethernet octets" },
 	{ ENETC_PM_RALN(0),	"MAC rx alignment errors" },
 	{ ENETC_PM_RXPF(0),	"MAC rx valid pause frames" },
@@ -194,6 +194,12 @@ static const struct {
 	{ ENETC_PM_TSCOL(0),	"MAC tx single collisions" },
 	{ ENETC_PM_TLCOL(0),	"MAC tx late collisions" },
 	{ ENETC_PM_TECOL(0),	"MAC tx excessive collisions" },
+};
+
+static const struct {
+	int reg;
+	char name[ETH_GSTRING_LEN] __nonstring;
+} enetc_port_counters[] = {
 	{ ENETC_UFDMF,		"SI MAC nomatch u-cast discards" },
 	{ ENETC_MFDMF,		"SI MAC nomatch m-cast discards" },
 	{ ENETC_PBFDSIR,	"SI MAC nomatch b-cast discards" },
@@ -240,6 +246,7 @@ static int enetc_get_sset_count(struct net_device *ndev, int sset)
 		return len;
 
 	len += ARRAY_SIZE(enetc_port_counters);
+	len += ARRAY_SIZE(enetc_pm_counters);
 
 	return len;
 }
@@ -266,6 +273,9 @@ static void enetc_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
 		for (i = 0; i < ARRAY_SIZE(enetc_port_counters); i++)
 			ethtool_cpy(&data, enetc_port_counters[i].name);
 
+		for (i = 0; i < ARRAY_SIZE(enetc_pm_counters); i++)
+			ethtool_cpy(&data, enetc_pm_counters[i].name);
+
 		break;
 	}
 }
@@ -302,6 +312,9 @@ static void enetc_get_ethtool_stats(struct net_device *ndev,
 
 	for (i = 0; i < ARRAY_SIZE(enetc_port_counters); i++)
 		data[o++] = enetc_port_rd(hw, enetc_port_counters[i].reg);
+
+	for (i = 0; i < ARRAY_SIZE(enetc_pm_counters); i++)
+		data[o++] = enetc_port_rd64(hw, enetc_pm_counters[i].reg);
 }
 
 static void enetc_pause_stats(struct enetc_hw *hw, int mac,
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
index cb26f185f52f..d4bbb07199c5 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
@@ -536,6 +536,7 @@ static inline u64 _enetc_rd_reg64_wa(void __iomem *reg)
 /* port register accessors - PF only */
 #define enetc_port_rd(hw, off)		enetc_rd_reg((hw)->port + (off))
 #define enetc_port_wr(hw, off, val)	enetc_wr_reg((hw)->port + (off), val)
+#define enetc_port_rd64(hw, off)	_enetc_rd_reg64_wa((hw)->port + (off))
 #define enetc_port_rd_mdio(hw, off)	_enetc_rd_mdio_reg_wa((hw)->port + (off))
 #define enetc_port_wr_mdio(hw, off, val)	_enetc_wr_mdio_reg_wa(\
 							(hw)->port + (off), val)
-- 
2.34.1

Re: [PATCH v2 net-next 2/3] net: enetc: separate 64-bit counters from enetc_port_counters

[Frank Li]

On Tue, Jun 24, 2025 at 06:15:47PM +0800, Wei Fang wrote:
> Some counters in enetc_port_counters are 32-bit registers, and some are
> 64-bit registers. But in the current driver, they are all read through
> enetc_port_rd(), which can only read a 32-bit value. Therefore, separate
> 64-bit counters (enetc_pm_counters) from enetc_port_counters and use
> enetc_port_rd64() to read the 64-bit statistics.
>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>

Reviewed-by: Frank Li <Frank.Li@nxp.com>

> ---
>  .../net/ethernet/freescale/enetc/enetc_ethtool.c  | 15 ++++++++++++++-
>  drivers/net/ethernet/freescale/enetc/enetc_hw.h   |  1 +
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
> index 2e5cef646741..2c9aa94c8e3d 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
> @@ -142,7 +142,7 @@ static const struct {
>  static const struct {
>  	int reg;
>  	char name[ETH_GSTRING_LEN] __nonstring;
> -} enetc_port_counters[] = {
> +} enetc_pm_counters[] = {
>  	{ ENETC_PM_REOCT(0),	"MAC rx ethernet octets" },
>  	{ ENETC_PM_RALN(0),	"MAC rx alignment errors" },
>  	{ ENETC_PM_RXPF(0),	"MAC rx valid pause frames" },
> @@ -194,6 +194,12 @@ static const struct {
>  	{ ENETC_PM_TSCOL(0),	"MAC tx single collisions" },
>  	{ ENETC_PM_TLCOL(0),	"MAC tx late collisions" },
>  	{ ENETC_PM_TECOL(0),	"MAC tx excessive collisions" },
> +};
> +
> +static const struct {
> +	int reg;
> +	char name[ETH_GSTRING_LEN] __nonstring;
> +} enetc_port_counters[] = {
>  	{ ENETC_UFDMF,		"SI MAC nomatch u-cast discards" },
>  	{ ENETC_MFDMF,		"SI MAC nomatch m-cast discards" },
>  	{ ENETC_PBFDSIR,	"SI MAC nomatch b-cast discards" },
> @@ -240,6 +246,7 @@ static int enetc_get_sset_count(struct net_device *ndev, int sset)
>  		return len;
>
>  	len += ARRAY_SIZE(enetc_port_counters);
> +	len += ARRAY_SIZE(enetc_pm_counters);
>
>  	return len;
>  }
> @@ -266,6 +273,9 @@ static void enetc_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
>  		for (i = 0; i < ARRAY_SIZE(enetc_port_counters); i++)
>  			ethtool_cpy(&data, enetc_port_counters[i].name);
>
> +		for (i = 0; i < ARRAY_SIZE(enetc_pm_counters); i++)
> +			ethtool_cpy(&data, enetc_pm_counters[i].name);
> +
>  		break;
>  	}
>  }
> @@ -302,6 +312,9 @@ static void enetc_get_ethtool_stats(struct net_device *ndev,
>
>  	for (i = 0; i < ARRAY_SIZE(enetc_port_counters); i++)
>  		data[o++] = enetc_port_rd(hw, enetc_port_counters[i].reg);
> +
> +	for (i = 0; i < ARRAY_SIZE(enetc_pm_counters); i++)
> +		data[o++] = enetc_port_rd64(hw, enetc_pm_counters[i].reg);
>  }
>
>  static void enetc_pause_stats(struct enetc_hw *hw, int mac,
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> index cb26f185f52f..d4bbb07199c5 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> @@ -536,6 +536,7 @@ static inline u64 _enetc_rd_reg64_wa(void __iomem *reg)
>  /* port register accessors - PF only */
>  #define enetc_port_rd(hw, off)		enetc_rd_reg((hw)->port + (off))
>  #define enetc_port_wr(hw, off, val)	enetc_wr_reg((hw)->port + (off), val)
> +#define enetc_port_rd64(hw, off)	_enetc_rd_reg64_wa((hw)->port + (off))
>  #define enetc_port_rd_mdio(hw, off)	_enetc_rd_mdio_reg_wa((hw)->port + (off))
>  #define enetc_port_wr_mdio(hw, off, val)	_enetc_wr_mdio_reg_wa(\
>  							(hw)->port + (off), val)
> --
> 2.34.1
>

Re: [PATCH v2 net-next 2/3] net: enetc: separate 64-bit counters from enetc_port_counters

[Simon Horman]

On Tue, Jun 24, 2025 at 06:15:47PM +0800, Wei Fang wrote:
> Some counters in enetc_port_counters are 32-bit registers, and some are
> 64-bit registers. But in the current driver, they are all read through
> enetc_port_rd(), which can only read a 32-bit value. Therefore, separate
> 64-bit counters (enetc_pm_counters) from enetc_port_counters and use
> enetc_port_rd64() to read the 64-bit statistics.
> 
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH v2 net-next 3/3] net: enetc: read 64-bit statistics from port MAC counters

[Wei Fang]

The counters of port MAC are all 64-bit registers, and the statistics of
ethtool are u64 type, so replace enetc_port_rd() with enetc_port_rd64()
to read 64-bit statistics.

Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
 .../ethernet/freescale/enetc/enetc_ethtool.c  | 84 +++++++++----------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
index 2c9aa94c8e3d..961e76cd8489 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
@@ -320,8 +320,8 @@ static void enetc_get_ethtool_stats(struct net_device *ndev,
 static void enetc_pause_stats(struct enetc_hw *hw, int mac,
 			      struct ethtool_pause_stats *pause_stats)
 {
-	pause_stats->tx_pause_frames = enetc_port_rd(hw, ENETC_PM_TXPF(mac));
-	pause_stats->rx_pause_frames = enetc_port_rd(hw, ENETC_PM_RXPF(mac));
+	pause_stats->tx_pause_frames = enetc_port_rd64(hw, ENETC_PM_TXPF(mac));
+	pause_stats->rx_pause_frames = enetc_port_rd64(hw, ENETC_PM_RXPF(mac));
 }
 
 static void enetc_get_pause_stats(struct net_device *ndev,
@@ -348,31 +348,31 @@ static void enetc_get_pause_stats(struct net_device *ndev,
 static void enetc_mac_stats(struct enetc_hw *hw, int mac,
 			    struct ethtool_eth_mac_stats *s)
 {
-	s->FramesTransmittedOK = enetc_port_rd(hw, ENETC_PM_TFRM(mac));
-	s->SingleCollisionFrames = enetc_port_rd(hw, ENETC_PM_TSCOL(mac));
-	s->MultipleCollisionFrames = enetc_port_rd(hw, ENETC_PM_TMCOL(mac));
-	s->FramesReceivedOK = enetc_port_rd(hw, ENETC_PM_RFRM(mac));
-	s->FrameCheckSequenceErrors = enetc_port_rd(hw, ENETC_PM_RFCS(mac));
-	s->AlignmentErrors = enetc_port_rd(hw, ENETC_PM_RALN(mac));
-	s->OctetsTransmittedOK = enetc_port_rd(hw, ENETC_PM_TEOCT(mac));
-	s->FramesWithDeferredXmissions = enetc_port_rd(hw, ENETC_PM_TDFR(mac));
-	s->LateCollisions = enetc_port_rd(hw, ENETC_PM_TLCOL(mac));
-	s->FramesAbortedDueToXSColls = enetc_port_rd(hw, ENETC_PM_TECOL(mac));
-	s->FramesLostDueToIntMACXmitError = enetc_port_rd(hw, ENETC_PM_TERR(mac));
-	s->CarrierSenseErrors = enetc_port_rd(hw, ENETC_PM_TCRSE(mac));
-	s->OctetsReceivedOK = enetc_port_rd(hw, ENETC_PM_REOCT(mac));
-	s->FramesLostDueToIntMACRcvError = enetc_port_rd(hw, ENETC_PM_RDRNTP(mac));
-	s->MulticastFramesXmittedOK = enetc_port_rd(hw, ENETC_PM_TMCA(mac));
-	s->BroadcastFramesXmittedOK = enetc_port_rd(hw, ENETC_PM_TBCA(mac));
-	s->MulticastFramesReceivedOK = enetc_port_rd(hw, ENETC_PM_RMCA(mac));
-	s->BroadcastFramesReceivedOK = enetc_port_rd(hw, ENETC_PM_RBCA(mac));
+	s->FramesTransmittedOK = enetc_port_rd64(hw, ENETC_PM_TFRM(mac));
+	s->SingleCollisionFrames = enetc_port_rd64(hw, ENETC_PM_TSCOL(mac));
+	s->MultipleCollisionFrames = enetc_port_rd64(hw, ENETC_PM_TMCOL(mac));
+	s->FramesReceivedOK = enetc_port_rd64(hw, ENETC_PM_RFRM(mac));
+	s->FrameCheckSequenceErrors = enetc_port_rd64(hw, ENETC_PM_RFCS(mac));
+	s->AlignmentErrors = enetc_port_rd64(hw, ENETC_PM_RALN(mac));
+	s->OctetsTransmittedOK = enetc_port_rd64(hw, ENETC_PM_TEOCT(mac));
+	s->FramesWithDeferredXmissions = enetc_port_rd64(hw, ENETC_PM_TDFR(mac));
+	s->LateCollisions = enetc_port_rd64(hw, ENETC_PM_TLCOL(mac));
+	s->FramesAbortedDueToXSColls = enetc_port_rd64(hw, ENETC_PM_TECOL(mac));
+	s->FramesLostDueToIntMACXmitError = enetc_port_rd64(hw, ENETC_PM_TERR(mac));
+	s->CarrierSenseErrors = enetc_port_rd64(hw, ENETC_PM_TCRSE(mac));
+	s->OctetsReceivedOK = enetc_port_rd64(hw, ENETC_PM_REOCT(mac));
+	s->FramesLostDueToIntMACRcvError = enetc_port_rd64(hw, ENETC_PM_RDRNTP(mac));
+	s->MulticastFramesXmittedOK = enetc_port_rd64(hw, ENETC_PM_TMCA(mac));
+	s->BroadcastFramesXmittedOK = enetc_port_rd64(hw, ENETC_PM_TBCA(mac));
+	s->MulticastFramesReceivedOK = enetc_port_rd64(hw, ENETC_PM_RMCA(mac));
+	s->BroadcastFramesReceivedOK = enetc_port_rd64(hw, ENETC_PM_RBCA(mac));
 }
 
 static void enetc_ctrl_stats(struct enetc_hw *hw, int mac,
 			     struct ethtool_eth_ctrl_stats *s)
 {
-	s->MACControlFramesTransmitted = enetc_port_rd(hw, ENETC_PM_TCNP(mac));
-	s->MACControlFramesReceived = enetc_port_rd(hw, ENETC_PM_RCNP(mac));
+	s->MACControlFramesTransmitted = enetc_port_rd64(hw, ENETC_PM_TCNP(mac));
+	s->MACControlFramesReceived = enetc_port_rd64(hw, ENETC_PM_RCNP(mac));
 }
 
 static const struct ethtool_rmon_hist_range enetc_rmon_ranges[] = {
@@ -389,26 +389,26 @@ static const struct ethtool_rmon_hist_range enetc_rmon_ranges[] = {
 static void enetc_rmon_stats(struct enetc_hw *hw, int mac,
 			     struct ethtool_rmon_stats *s)
 {
-	s->undersize_pkts = enetc_port_rd(hw, ENETC_PM_RUND(mac));
-	s->oversize_pkts = enetc_port_rd(hw, ENETC_PM_ROVR(mac));
-	s->fragments = enetc_port_rd(hw, ENETC_PM_RFRG(mac));
-	s->jabbers = enetc_port_rd(hw, ENETC_PM_RJBR(mac));
-
-	s->hist[0] = enetc_port_rd(hw, ENETC_PM_R64(mac));
-	s->hist[1] = enetc_port_rd(hw, ENETC_PM_R127(mac));
-	s->hist[2] = enetc_port_rd(hw, ENETC_PM_R255(mac));
-	s->hist[3] = enetc_port_rd(hw, ENETC_PM_R511(mac));
-	s->hist[4] = enetc_port_rd(hw, ENETC_PM_R1023(mac));
-	s->hist[5] = enetc_port_rd(hw, ENETC_PM_R1522(mac));
-	s->hist[6] = enetc_port_rd(hw, ENETC_PM_R1523X(mac));
-
-	s->hist_tx[0] = enetc_port_rd(hw, ENETC_PM_T64(mac));
-	s->hist_tx[1] = enetc_port_rd(hw, ENETC_PM_T127(mac));
-	s->hist_tx[2] = enetc_port_rd(hw, ENETC_PM_T255(mac));
-	s->hist_tx[3] = enetc_port_rd(hw, ENETC_PM_T511(mac));
-	s->hist_tx[4] = enetc_port_rd(hw, ENETC_PM_T1023(mac));
-	s->hist_tx[5] = enetc_port_rd(hw, ENETC_PM_T1522(mac));
-	s->hist_tx[6] = enetc_port_rd(hw, ENETC_PM_T1523X(mac));
+	s->undersize_pkts = enetc_port_rd64(hw, ENETC_PM_RUND(mac));
+	s->oversize_pkts = enetc_port_rd64(hw, ENETC_PM_ROVR(mac));
+	s->fragments = enetc_port_rd64(hw, ENETC_PM_RFRG(mac));
+	s->jabbers = enetc_port_rd64(hw, ENETC_PM_RJBR(mac));
+
+	s->hist[0] = enetc_port_rd64(hw, ENETC_PM_R64(mac));
+	s->hist[1] = enetc_port_rd64(hw, ENETC_PM_R127(mac));
+	s->hist[2] = enetc_port_rd64(hw, ENETC_PM_R255(mac));
+	s->hist[3] = enetc_port_rd64(hw, ENETC_PM_R511(mac));
+	s->hist[4] = enetc_port_rd64(hw, ENETC_PM_R1023(mac));
+	s->hist[5] = enetc_port_rd64(hw, ENETC_PM_R1522(mac));
+	s->hist[6] = enetc_port_rd64(hw, ENETC_PM_R1523X(mac));
+
+	s->hist_tx[0] = enetc_port_rd64(hw, ENETC_PM_T64(mac));
+	s->hist_tx[1] = enetc_port_rd64(hw, ENETC_PM_T127(mac));
+	s->hist_tx[2] = enetc_port_rd64(hw, ENETC_PM_T255(mac));
+	s->hist_tx[3] = enetc_port_rd64(hw, ENETC_PM_T511(mac));
+	s->hist_tx[4] = enetc_port_rd64(hw, ENETC_PM_T1023(mac));
+	s->hist_tx[5] = enetc_port_rd64(hw, ENETC_PM_T1522(mac));
+	s->hist_tx[6] = enetc_port_rd64(hw, ENETC_PM_T1523X(mac));
 }
 
 static void enetc_get_eth_mac_stats(struct net_device *ndev,
-- 
2.34.1

Re: [PATCH v2 net-next 3/3] net: enetc: read 64-bit statistics from port MAC counters

[Frank Li]

On Tue, Jun 24, 2025 at 06:15:48PM +0800, Wei Fang wrote:
> The counters of port MAC are all 64-bit registers, and the statistics of
> ethtool are u64 type, so replace enetc_port_rd() with enetc_port_rd64()
> to read 64-bit statistics.
>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>

Reviewed-by: Frank Li <Frank.Li@nxp.com>

> ---
>  .../ethernet/freescale/enetc/enetc_ethtool.c  | 84 +++++++++----------
>  1 file changed, 42 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
> index 2c9aa94c8e3d..961e76cd8489 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
> @@ -320,8 +320,8 @@ static void enetc_get_ethtool_stats(struct net_device *ndev,
>  static void enetc_pause_stats(struct enetc_hw *hw, int mac,
>  			      struct ethtool_pause_stats *pause_stats)
>  {
> -	pause_stats->tx_pause_frames = enetc_port_rd(hw, ENETC_PM_TXPF(mac));
> -	pause_stats->rx_pause_frames = enetc_port_rd(hw, ENETC_PM_RXPF(mac));
> +	pause_stats->tx_pause_frames = enetc_port_rd64(hw, ENETC_PM_TXPF(mac));
> +	pause_stats->rx_pause_frames = enetc_port_rd64(hw, ENETC_PM_RXPF(mac));
>  }
>
>  static void enetc_get_pause_stats(struct net_device *ndev,
> @@ -348,31 +348,31 @@ static void enetc_get_pause_stats(struct net_device *ndev,
>  static void enetc_mac_stats(struct enetc_hw *hw, int mac,
>  			    struct ethtool_eth_mac_stats *s)
>  {
> -	s->FramesTransmittedOK = enetc_port_rd(hw, ENETC_PM_TFRM(mac));
> -	s->SingleCollisionFrames = enetc_port_rd(hw, ENETC_PM_TSCOL(mac));
> -	s->MultipleCollisionFrames = enetc_port_rd(hw, ENETC_PM_TMCOL(mac));
> -	s->FramesReceivedOK = enetc_port_rd(hw, ENETC_PM_RFRM(mac));
> -	s->FrameCheckSequenceErrors = enetc_port_rd(hw, ENETC_PM_RFCS(mac));
> -	s->AlignmentErrors = enetc_port_rd(hw, ENETC_PM_RALN(mac));
> -	s->OctetsTransmittedOK = enetc_port_rd(hw, ENETC_PM_TEOCT(mac));
> -	s->FramesWithDeferredXmissions = enetc_port_rd(hw, ENETC_PM_TDFR(mac));
> -	s->LateCollisions = enetc_port_rd(hw, ENETC_PM_TLCOL(mac));
> -	s->FramesAbortedDueToXSColls = enetc_port_rd(hw, ENETC_PM_TECOL(mac));
> -	s->FramesLostDueToIntMACXmitError = enetc_port_rd(hw, ENETC_PM_TERR(mac));
> -	s->CarrierSenseErrors = enetc_port_rd(hw, ENETC_PM_TCRSE(mac));
> -	s->OctetsReceivedOK = enetc_port_rd(hw, ENETC_PM_REOCT(mac));
> -	s->FramesLostDueToIntMACRcvError = enetc_port_rd(hw, ENETC_PM_RDRNTP(mac));
> -	s->MulticastFramesXmittedOK = enetc_port_rd(hw, ENETC_PM_TMCA(mac));
> -	s->BroadcastFramesXmittedOK = enetc_port_rd(hw, ENETC_PM_TBCA(mac));
> -	s->MulticastFramesReceivedOK = enetc_port_rd(hw, ENETC_PM_RMCA(mac));
> -	s->BroadcastFramesReceivedOK = enetc_port_rd(hw, ENETC_PM_RBCA(mac));
> +	s->FramesTransmittedOK = enetc_port_rd64(hw, ENETC_PM_TFRM(mac));
> +	s->SingleCollisionFrames = enetc_port_rd64(hw, ENETC_PM_TSCOL(mac));
> +	s->MultipleCollisionFrames = enetc_port_rd64(hw, ENETC_PM_TMCOL(mac));
> +	s->FramesReceivedOK = enetc_port_rd64(hw, ENETC_PM_RFRM(mac));
> +	s->FrameCheckSequenceErrors = enetc_port_rd64(hw, ENETC_PM_RFCS(mac));
> +	s->AlignmentErrors = enetc_port_rd64(hw, ENETC_PM_RALN(mac));
> +	s->OctetsTransmittedOK = enetc_port_rd64(hw, ENETC_PM_TEOCT(mac));
> +	s->FramesWithDeferredXmissions = enetc_port_rd64(hw, ENETC_PM_TDFR(mac));
> +	s->LateCollisions = enetc_port_rd64(hw, ENETC_PM_TLCOL(mac));
> +	s->FramesAbortedDueToXSColls = enetc_port_rd64(hw, ENETC_PM_TECOL(mac));
> +	s->FramesLostDueToIntMACXmitError = enetc_port_rd64(hw, ENETC_PM_TERR(mac));
> +	s->CarrierSenseErrors = enetc_port_rd64(hw, ENETC_PM_TCRSE(mac));
> +	s->OctetsReceivedOK = enetc_port_rd64(hw, ENETC_PM_REOCT(mac));
> +	s->FramesLostDueToIntMACRcvError = enetc_port_rd64(hw, ENETC_PM_RDRNTP(mac));
> +	s->MulticastFramesXmittedOK = enetc_port_rd64(hw, ENETC_PM_TMCA(mac));
> +	s->BroadcastFramesXmittedOK = enetc_port_rd64(hw, ENETC_PM_TBCA(mac));
> +	s->MulticastFramesReceivedOK = enetc_port_rd64(hw, ENETC_PM_RMCA(mac));
> +	s->BroadcastFramesReceivedOK = enetc_port_rd64(hw, ENETC_PM_RBCA(mac));
>  }
>
>  static void enetc_ctrl_stats(struct enetc_hw *hw, int mac,
>  			     struct ethtool_eth_ctrl_stats *s)
>  {
> -	s->MACControlFramesTransmitted = enetc_port_rd(hw, ENETC_PM_TCNP(mac));
> -	s->MACControlFramesReceived = enetc_port_rd(hw, ENETC_PM_RCNP(mac));
> +	s->MACControlFramesTransmitted = enetc_port_rd64(hw, ENETC_PM_TCNP(mac));
> +	s->MACControlFramesReceived = enetc_port_rd64(hw, ENETC_PM_RCNP(mac));
>  }
>
>  static const struct ethtool_rmon_hist_range enetc_rmon_ranges[] = {
> @@ -389,26 +389,26 @@ static const struct ethtool_rmon_hist_range enetc_rmon_ranges[] = {
>  static void enetc_rmon_stats(struct enetc_hw *hw, int mac,
>  			     struct ethtool_rmon_stats *s)
>  {
> -	s->undersize_pkts = enetc_port_rd(hw, ENETC_PM_RUND(mac));
> -	s->oversize_pkts = enetc_port_rd(hw, ENETC_PM_ROVR(mac));
> -	s->fragments = enetc_port_rd(hw, ENETC_PM_RFRG(mac));
> -	s->jabbers = enetc_port_rd(hw, ENETC_PM_RJBR(mac));
> -
> -	s->hist[0] = enetc_port_rd(hw, ENETC_PM_R64(mac));
> -	s->hist[1] = enetc_port_rd(hw, ENETC_PM_R127(mac));
> -	s->hist[2] = enetc_port_rd(hw, ENETC_PM_R255(mac));
> -	s->hist[3] = enetc_port_rd(hw, ENETC_PM_R511(mac));
> -	s->hist[4] = enetc_port_rd(hw, ENETC_PM_R1023(mac));
> -	s->hist[5] = enetc_port_rd(hw, ENETC_PM_R1522(mac));
> -	s->hist[6] = enetc_port_rd(hw, ENETC_PM_R1523X(mac));
> -
> -	s->hist_tx[0] = enetc_port_rd(hw, ENETC_PM_T64(mac));
> -	s->hist_tx[1] = enetc_port_rd(hw, ENETC_PM_T127(mac));
> -	s->hist_tx[2] = enetc_port_rd(hw, ENETC_PM_T255(mac));
> -	s->hist_tx[3] = enetc_port_rd(hw, ENETC_PM_T511(mac));
> -	s->hist_tx[4] = enetc_port_rd(hw, ENETC_PM_T1023(mac));
> -	s->hist_tx[5] = enetc_port_rd(hw, ENETC_PM_T1522(mac));
> -	s->hist_tx[6] = enetc_port_rd(hw, ENETC_PM_T1523X(mac));
> +	s->undersize_pkts = enetc_port_rd64(hw, ENETC_PM_RUND(mac));
> +	s->oversize_pkts = enetc_port_rd64(hw, ENETC_PM_ROVR(mac));
> +	s->fragments = enetc_port_rd64(hw, ENETC_PM_RFRG(mac));
> +	s->jabbers = enetc_port_rd64(hw, ENETC_PM_RJBR(mac));
> +
> +	s->hist[0] = enetc_port_rd64(hw, ENETC_PM_R64(mac));
> +	s->hist[1] = enetc_port_rd64(hw, ENETC_PM_R127(mac));
> +	s->hist[2] = enetc_port_rd64(hw, ENETC_PM_R255(mac));
> +	s->hist[3] = enetc_port_rd64(hw, ENETC_PM_R511(mac));
> +	s->hist[4] = enetc_port_rd64(hw, ENETC_PM_R1023(mac));
> +	s->hist[5] = enetc_port_rd64(hw, ENETC_PM_R1522(mac));
> +	s->hist[6] = enetc_port_rd64(hw, ENETC_PM_R1523X(mac));
> +
> +	s->hist_tx[0] = enetc_port_rd64(hw, ENETC_PM_T64(mac));
> +	s->hist_tx[1] = enetc_port_rd64(hw, ENETC_PM_T127(mac));
> +	s->hist_tx[2] = enetc_port_rd64(hw, ENETC_PM_T255(mac));
> +	s->hist_tx[3] = enetc_port_rd64(hw, ENETC_PM_T511(mac));
> +	s->hist_tx[4] = enetc_port_rd64(hw, ENETC_PM_T1023(mac));
> +	s->hist_tx[5] = enetc_port_rd64(hw, ENETC_PM_T1522(mac));
> +	s->hist_tx[6] = enetc_port_rd64(hw, ENETC_PM_T1523X(mac));
>  }
>
>  static void enetc_get_eth_mac_stats(struct net_device *ndev,
> --
> 2.34.1
>

Re: [PATCH v2 net-next 3/3] net: enetc: read 64-bit statistics from port MAC counters

[Simon Horman]

On Tue, Jun 24, 2025 at 06:15:48PM +0800, Wei Fang wrote:
> The counters of port MAC are all 64-bit registers, and the statistics of
> ethtool are u64 type, so replace enetc_port_rd() with enetc_port_rd64()
> to read 64-bit statistics.
> 
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [PATCH v2 net-next 0/3] change some statistics to 64-bit

[Jakub Kicinski]

On Tue, 24 Jun 2025 18:15:45 +0800 Wei Fang wrote:
> The port MAC counters of ENETC are 64-bit registers and the statistics
> of ethtool are also u64 type, so add enetc_port_rd64() helper function
> to read 64-bit statistics from these registers, and also change the
> statistics of ring to unsigned long type to be consistent with the
> statistics type in struct net_device_stats.

this series adds almost 100 sparse warnings
please trying building it with C=1
-- 
pw-bot: cr

RE: [PATCH v2 net-next 0/3] change some statistics to 64-bit

[Wei Fang]

> On Tue, 24 Jun 2025 18:15:45 +0800 Wei Fang wrote:
> > The port MAC counters of ENETC are 64-bit registers and the statistics
> > of ethtool are also u64 type, so add enetc_port_rd64() helper function
> > to read 64-bit statistics from these registers, and also change the
> > statistics of ring to unsigned long type to be consistent with the
> > statistics type in struct net_device_stats.
> 
> this series adds almost 100 sparse warnings please trying building it with C=1
> --
> pw-bot: cr

Hi Jakub,

Simon has posted a patch [1] to fix the sparse warnings. Do I need to wait until
Simon's patch is applied to the net-next tree and then resend this patch set?

[1] https://lore.kernel.org/imx/20250624-etnetc-le-v1-1-a73a95d96e4e@kernel.org/

Re: [PATCH v2 net-next 0/3] change some statistics to 64-bit

[Simon Horman]

On Wed, Jun 25, 2025 at 02:22:54AM +0000, Wei Fang wrote:
> > On Tue, 24 Jun 2025 18:15:45 +0800 Wei Fang wrote:
> > > The port MAC counters of ENETC are 64-bit registers and the statistics
> > > of ethtool are also u64 type, so add enetc_port_rd64() helper function
> > > to read 64-bit statistics from these registers, and also change the
> > > statistics of ring to unsigned long type to be consistent with the
> > > statistics type in struct net_device_stats.
> > 
> > this series adds almost 100 sparse warnings please trying building it with C=1
> > --
> > pw-bot: cr
> 
> Hi Jakub,
> 
> Simon has posted a patch [1] to fix the sparse warnings. Do I need to wait until
> Simon's patch is applied to the net-next tree and then resend this patch set?
> 
> [1] https://lore.kernel.org/imx/20250624-etnetc-le-v1-1-a73a95d96e4e@kernel.org/

Yes, I have confirmed that with patch[1] applied this patch-set
does not introduce any Sparse warnings (in my environment).

I noticed the Sparse warnings that are otherwise introduced when reviewing
v1 of this patchset which is why I crated patch[1].

The issue is that there is are long standing Sparse warnings - which
highlight a driver bug, albeit one that doesn't manifest with in tree
users. They is due to an unnecessary call to le64_to_cpu(). The warnings
are:

  .../enetc_hw.h:513:16: warning: cast to restricted __le64
  .../enetc_hw.h:513:16: warning: restricted __le64 degrades to integer
  .../enetc_hw.h:513:16: warning: cast to restricted __le64

Patches 2/3 and 3/3 multiply the incidence of the above 3 warnings because
they increase the callers of the inline function where the problem lies.

But I'd argue that, other than noise, they don't make things worse.
The bug doesn't manifest for in-tree users (and if it did, it would
have been manifesting anyway).

So I'd advocate accepting this series (or not) independent of resolving
the Sparse warnings. Which should disappear when patch[1], or some variant
thereof, is accepted (via net or directly into net-next).

Re: [PATCH v2 net-next 0/3] change some statistics to 64-bit

[Jakub Kicinski]

On Wed, 25 Jun 2025 17:34:59 +0100 Simon Horman wrote:
> > Simon has posted a patch [1] to fix the sparse warnings. Do I need to wait until
> > Simon's patch is applied to the net-next tree and then resend this patch set?
> > 
> > [1] https://lore.kernel.org/imx/20250624-etnetc-le-v1-1-a73a95d96e4e@kernel.org/  
> 
> Yes, I have confirmed that with patch[1] applied this patch-set
> does not introduce any Sparse warnings (in my environment).
> 
> I noticed the Sparse warnings that are otherwise introduced when reviewing
> v1 of this patchset which is why I crated patch[1].
> 
> The issue is that there is are long standing Sparse warnings - which
> highlight a driver bug, albeit one that doesn't manifest with in tree
> users. They is due to an unnecessary call to le64_to_cpu(). The warnings
> are:
> 
>   .../enetc_hw.h:513:16: warning: cast to restricted __le64
>   .../enetc_hw.h:513:16: warning: restricted __le64 degrades to integer
>   .../enetc_hw.h:513:16: warning: cast to restricted __le64
> 
> Patches 2/3 and 3/3 multiply the incidence of the above 3 warnings because
> they increase the callers of the inline function where the problem lies.
> 
> But I'd argue that, other than noise, they don't make things worse.
> The bug doesn't manifest for in-tree users (and if it did, it would
> have been manifesting anyway).
> 
> So I'd advocate accepting this series (or not) independent of resolving
> the Sparse warnings. Which should disappear when patch[1], or some variant
> thereof, is accepted (via net or directly into net-next).

All fair points, but unfortunately if there is a build issue 
the patches are not fed into the full CI cycle. Simon's fix
will hit net-next tomorrow, let's get these reposted tomorrow
so we can avoid any (unlikely) surprises?

RE: [PATCH v2 net-next 0/3] change some statistics to 64-bit

[Wei Fang]

> On Wed, 25 Jun 2025 17:34:59 +0100 Simon Horman wrote:
> > > Simon has posted a patch [1] to fix the sparse warnings. Do I need to wait
> until
> > > Simon's patch is applied to the net-next tree and then resend this patch set?
> > >
> > > [1]
> https://lore.kern/
> el.org%2Fimx%2F20250624-etnetc-le-v1-1-a73a95d96e4e%40kernel.org%2F&d
> ata=05%7C02%7Cwei.fang%40nxp.com%7Ca68166be285a4e0f081908ddb4276
> 67a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63886480348665
> 4949%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA
> uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7
> C%7C&sdata=X1UJzBeU2dYFir7YQaMHkpoS03axSQGqQJm%2F2EIIh0E%3D&res
> erved=0
> >
> > Yes, I have confirmed that with patch[1] applied this patch-set
> > does not introduce any Sparse warnings (in my environment).
> >
> > I noticed the Sparse warnings that are otherwise introduced when reviewing
> > v1 of this patchset which is why I crated patch[1].
> >
> > The issue is that there is are long standing Sparse warnings - which
> > highlight a driver bug, albeit one that doesn't manifest with in tree
> > users. They is due to an unnecessary call to le64_to_cpu(). The warnings
> > are:
> >
> >   .../enetc_hw.h:513:16: warning: cast to restricted __le64
> >   .../enetc_hw.h:513:16: warning: restricted __le64 degrades to integer
> >   .../enetc_hw.h:513:16: warning: cast to restricted __le64
> >
> > Patches 2/3 and 3/3 multiply the incidence of the above 3 warnings because
> > they increase the callers of the inline function where the problem lies.
> >
> > But I'd argue that, other than noise, they don't make things worse.
> > The bug doesn't manifest for in-tree users (and if it did, it would
> > have been manifesting anyway).
> >
> > So I'd advocate accepting this series (or not) independent of resolving
> > the Sparse warnings. Which should disappear when patch[1], or some variant
> > thereof, is accepted (via net or directly into net-next).
>
> All fair points, but unfortunately if there is a build issue
> the patches are not fed into the full CI cycle. Simon's fix
> will hit net-next tomorrow, let's get these reposted tomorrow
> so we can avoid any (unlikely) surprises?

No problem, I will resend this patch set after Simon's patch is applied
to net-next tree. Thanks.

Re: [PATCH v2 net-next 0/3] change some statistics to 64-bit

[Simon Horman]

On Wed, Jun 25, 2025 at 01:32:24PM -0700, Jakub Kicinski wrote:
> On Wed, 25 Jun 2025 17:34:59 +0100 Simon Horman wrote:
> > > Simon has posted a patch [1] to fix the sparse warnings. Do I need to wait until
> > > Simon's patch is applied to the net-next tree and then resend this patch set?
> > > 
> > > [1] https://lore.kernel.org/imx/20250624-etnetc-le-v1-1-a73a95d96e4e@kernel.org/  
> > 
> > Yes, I have confirmed that with patch[1] applied this patch-set
> > does not introduce any Sparse warnings (in my environment).
> > 
> > I noticed the Sparse warnings that are otherwise introduced when reviewing
> > v1 of this patchset which is why I crated patch[1].
> > 
> > The issue is that there is are long standing Sparse warnings - which
> > highlight a driver bug, albeit one that doesn't manifest with in tree
> > users. They is due to an unnecessary call to le64_to_cpu(). The warnings
> > are:
> > 
> >   .../enetc_hw.h:513:16: warning: cast to restricted __le64
> >   .../enetc_hw.h:513:16: warning: restricted __le64 degrades to integer
> >   .../enetc_hw.h:513:16: warning: cast to restricted __le64
> > 
> > Patches 2/3 and 3/3 multiply the incidence of the above 3 warnings because
> > they increase the callers of the inline function where the problem lies.
> > 
> > But I'd argue that, other than noise, they don't make things worse.
> > The bug doesn't manifest for in-tree users (and if it did, it would
> > have been manifesting anyway).
> > 
> > So I'd advocate accepting this series (or not) independent of resolving
> > the Sparse warnings. Which should disappear when patch[1], or some variant
> > thereof, is accepted (via net or directly into net-next).
> 
> All fair points, but unfortunately if there is a build issue 
> the patches are not fed into the full CI cycle.

Thanks, I wasn't aware of that.

> Simon's fix
> will hit net-next tomorrow, let's get these reposted tomorrow
> so we can avoid any (unlikely) surprises?

Yes, agreed. Let's avoid surprises.