On Tue, Feb 17, 2026 at 2:35 AM Andrew Lunn [off-list ref] wrote:

quoted

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 43cd013bb70e..26f9ccadd9f6 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c

@@ -3159,8 +3159,8 @@ static void gem_get_ethtool_strings(struct net_device *dev, u32 sset, u8 *p)

              for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
                      for (i = 0; i < QUEUE_STATS_LEN; i++, p += ETH_GSTRING_LEN) {
-                             snprintf(stat_string, ETH_GSTRING_LEN, "q%d_%s",
-                                             q, queue_statistics[i].stat_string);
+                             snprintf(stat_string, ETH_GSTRING_LEN, "q%u_%.19s",
+                                      q, queue_statistics[i].stat_string);

These strings are special, in that they are fixed length, 32 bytes
long, and not \0 terminated. There are some helpers at the end of
linux/ethtool.h for dealing with these strings. You might want to use
them.

Yes, I've switched to ethtool_sprintf() from linux/ethtool.h and
removed the manual
snprintf() and memcpy() calls. After testing, it behaves exactly as expected,
so I will send out [PATCH V3] shortly.

I also wounder, why is just one architecture complaining about this?

Regarding the architecture-specific nature of the warning: I have verified that
this warning is not triggered on x86_64, even with W=1. It appears to
be specific
to the RISC-V toolchain's diagnostic analysis.

Regardless, converting to ethtool_sprintf() is the correct approach
which does not throw
any warning on the both platforms.

Best regards,
Sean