From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     netdev@vger.kernel.org
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        UNGLinuxDriver@microchip.com,
        Colin Foster <colin.foster@in-advantage.com>,
        linux-kernel@vger.kernel.org
Subject: [PATCH net 3/3] net: mscc: ocelot: add TX_MM_HOLD to ocelot_mm_stats_layout
Date:   Tue, 21 Mar 2023 03:03:25 +0200
Message-Id: <20230321010325.897817-4-vladimir.oltean@nxp.com>
In-Reply-To: <20230321010325.897817-1-vladimir.oltean@nxp.com>
References: <20230321010325.897817-1-vladimir.oltean@nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?CYV5SGKHlI9ZLq2z1QeuHIMvA7n1j4kasUU6oPtroO/mUis1e1tBT/XxAA/u?=
 =?us-ascii?Q?u7UWt/aaK/rXLExPcgC/UQ1XCDHXx4HDHol+2uOnf2PnXYWlvaRB5BZV1l1c?=
 =?us-ascii?Q?03Wr9oA4bukWsm90PjU9R9au9j+5pviMqwU48inufrtzAi9EjFn1INto3z12?=
 =?us-ascii?Q?oqE+pb5hFTPJMUsBOxMVguYB3gORr6OoVV3oCasWePBvNQ5yEhyF9/xknRk1?=
 =?us-ascii?Q?piSeZl9Aj4DQnco502LgbVz21jUQYDOAjSaQrHSh+agk+NmIpMDBPJdHZ5MP?=
 =?us-ascii?Q?A9iYfEgAxcFK8mGd9s2U8KYz1oOdCK5KJ51NedkGONCJpyDiTT4TVauUOUpL?=
 =?us-ascii?Q?8aWAY21TKvbGaUsgWZZCXmzqxscaBZCdK8v18FG5un2tz4OF/1J2wrF/gBXp?=
 =?us-ascii?Q?j9OJlX4gfOQki4isiePpRN8c9rzwoh0IHkUUpAeqIXCZrXCIe/PytxVx51fb?=
 =?us-ascii?Q?BsnBP+6eP+R/vpj8YMHP2L12+iEa6+RhSM6pysmuxs7beChctJzKyoNNoOjU?=
 =?us-ascii?Q?WG0fKs9zuZwIcmlUiKZjFYYOJxN5lkKTGrs5gAGA7+jGKtsf9iuK7W6n1g2X?=
 =?us-ascii?Q?lQsvTXZUjXhrgHDq7h/OGsCk0k17LBv/flGl5kwJ2IPzjf0DfyI4fqhIw6lS?=
 =?us-ascii?Q?pW4lQHfzxfm0Lw3/79qPOUz+cONplwFz6jRkajEh7REVZpCFg8j79+1XPUek?=
 =?us-ascii?Q?Vao5r+cX5y3pRdUmvWJ2ljWllVb2TMAIsjwmqylb8tJbR7QgdJus2YydBYqR?=
 =?us-ascii?Q?ViJQpNAdjH680ydi/GUYhDioPmsLnH5DFgiFwqaAcdIRcSV29Q8ftE7KnfUl?=
 =?us-ascii?Q?xb4f7bYiUfSxB0+s8vRJlaqgIU0V21MrMJ9SfD5spoofSm/ejOC7IR5+sHRn?=
 =?us-ascii?Q?5wFK/4E27MLFdKeB/TFuWFfVghns4tdlHIEC1rNgvHCnZ3IiyDGhjAFA5+b1?=
 =?us-ascii?Q?D/Pnem9IzKtw21oALoTbHTulGhDcaceh5gcYYGQuUggagW/IwSvlUyzt2Ro6?=
 =?us-ascii?Q?N0D0LlLI6tec2Xan35CJKgxowlMps2ubtZGDDVJwbOqb5Mud4hLLQADrRKCl?=
 =?us-ascii?Q?QrfjNxvkc42C/v1F1nX8GT5K/Nwgdik3R3RWlyTl44v0bNasgchjiAFu13wV?=
 =?us-ascii?Q?L7iWzTy9qdLIzlMUnhubXDMOCYMyxcU4goOtIN26dtD4McrETC7nicz8Is+L?=
 =?us-ascii?Q?vNX+GD4achREda9gm73GGG5Caxy2y0UWwxqLFBJicgGYDJfRbY6ufNXkxexc?=
 =?us-ascii?Q?/Cdq21Y0SMuFCxaqawk0gUKCrhqEL/X/2sWDygKJRKtSw3ur+2Fzuv8Z5qC9?=
 =?us-ascii?Q?lS+jaYyYY191BLWuDenIhM4fZI00CkrL2vLcbZttvdTgxIuSjyinREnmk3AW?=
 =?us-ascii?Q?5zziBWxDpYrudDQ5JCs8rwBqftibiPDrIrLAvn4geV+ErhUWM7gbHUWx9qVy?=
 =?us-ascii?Q?DslJdC5qe0vTW6uGBIw7bpbmDB2ZZ3WRFJKxvMJSNETFJy0Mj1/jVL4XAjH9?=
 =?us-ascii?Q?aHSzymE++VCBbCXz6252aBWV1WRQbhNjrCQrKzGhidcQ+vBx28zGpf7s3u1D?=
 =?us-ascii?Q?utM25uUKVSI6Wx+5SO9BthCBXSz7gmAfIgYfTgVDmTUHNzDrV4FYZf6ZoQSU?=
 =?us-ascii?Q?Wg=3D=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 03e8431e-bdaa-435b-a4c0-08db29a81c9b
X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB6452.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2023 01:03:41.5982
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: jVMiIV3jmb5GlBBXmXb8Cf01C/QUx+d8tLYVsS5pJ92RFR/PSc+9eKJiXGVsJ16JV/1TapM/C0z8nXhUVbYqPw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB7911
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

The lack of a definition for this counter is what initially prompted me
to investigate a problem which really manifested itself as the previous
change, "net: mscc: ocelot: fix transfer from region->buf to ocelot->stats".

When TX_MM_HOLD is defined in enum ocelot_stat but not in struct
ocelot_stat_layout ocelot_mm_stats_layout, this creates a hole, which
due to the aforementioned bug, makes all counters following TX_MM_HOLD
be recorded off by one compared to their correct position. So for
example, a non-zero TX_PMAC_OCTETS would be reported as TX_MERGE_FRAGMENTS,
TX_PMAC_UNICAST would be reported as TX_PMAC_OCTETS, TX_PMAC_64 would be
reported as TX_PMAC_PAUSE, etc etc. This is because the size of the hole
(1) is much smaller than the size of the region, so the phenomenon where
the stats are off-by-one, rather than lost, prevails.

However, the phenomenon where stats are lost can be seen too, for
example with DROP_LOCAL, which is at the beginning of its own region
(offset 0x000400 vs the previous 0x0002b0 constitutes a discontinuity).
This is also reported as off by one and saved to TX_PMAC_1527_MAX, but
that counter is not reported to the unstructured "ethtool -S", as
opposed to DROP_LOCAL which is (as "drop_local").

Fixes: ab3f97a9610a ("net: mscc: ocelot: export ethtool MAC Merge stats for Felix VSC9959")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/ethernet/mscc/ocelot_stats.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mscc/ocelot_stats.c b/drivers/net/ethernet/mscc/ocelot_stats.c
index f18371154475..d0e6cd8dbe5c 100644
--- a/drivers/net/ethernet/mscc/ocelot_stats.c
+++ b/drivers/net/ethernet/mscc/ocelot_stats.c
@@ -274,6 +274,7 @@ static const struct ocelot_stat_layout ocelot_mm_stats_layout[OCELOT_NUM_STATS]
 	OCELOT_STAT(RX_ASSEMBLY_OK),
 	OCELOT_STAT(RX_MERGE_FRAGMENTS),
 	OCELOT_STAT(TX_MERGE_FRAGMENTS),
+	OCELOT_STAT(TX_MM_HOLD),
 	OCELOT_STAT(RX_PMAC_OCTETS),
 	OCELOT_STAT(RX_PMAC_UNICAST),
 	OCELOT_STAT(RX_PMAC_MULTICAST),
-- 
2.34.1