From: Jesper Nilsson <jesper.nilsson@axis.com> To: Florian Fainelli <f.fainelli@gmail.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, "Jakub Kicinski" <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, <netdev@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <kernel@axis.com> Subject: Re: [PATCH] net: stmmac: mmc_core: Assign, don't add interrupt registers Date: Mon, 19 Feb 2024 11:40:25 +0100 [thread overview] Message-ID: <20240219104025.GM22484@axis.com> (raw) In-Reply-To: <61bdd802-abe4-4544-8e48-9493a6bb99c8@gmail.com> On Fri, Feb 16, 2024 at 09:13:51AM -0800, Florian Fainelli wrote: > So in premise I agree with the patch, that incrementing those is not the > right way to go about them. However these registers are currently provided > as part of the statistics set, but they should instead be accessed via the > register dumping method. You mean extending the dump register code to dump the MAC Management Counter registers that are not counters? From what I understand it's only the Rx and Tx interrupt and interrupt mask registers that aren't counters. Oh, and the MMC control register itself? To be honest, I don't think their use can justify the code churn. > In either case you will get at best a snapshot of those two registers at any > given time and I suppose this can help diagnose a stuck RX condition, but > not much more than that. Yeah, their use is very doubtful. For me, they only introduce more nonsense data in my logs. The Rx registers looks to have been added in the first version of the MMC back in 2011, but the Tx registers never was. In commit 1c901a46d57 Giuseppe mentions the MMC interrupts as something to add later (if actually useful). So Serge's suggestion to drop the entries completely is actually quite attractive. > Florian /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nilsson@axis.com
WARNING: multiple messages have this Message-ID (diff)
From: Jesper Nilsson <jesper.nilsson@axis.com> To: Florian Fainelli <f.fainelli@gmail.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, "Jakub Kicinski" <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, <netdev@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <kernel@axis.com> Subject: Re: [PATCH] net: stmmac: mmc_core: Assign, don't add interrupt registers Date: Mon, 19 Feb 2024 11:40:25 +0100 [thread overview] Message-ID: <20240219104025.GM22484@axis.com> (raw) In-Reply-To: <61bdd802-abe4-4544-8e48-9493a6bb99c8@gmail.com> On Fri, Feb 16, 2024 at 09:13:51AM -0800, Florian Fainelli wrote: > So in premise I agree with the patch, that incrementing those is not the > right way to go about them. However these registers are currently provided > as part of the statistics set, but they should instead be accessed via the > register dumping method. You mean extending the dump register code to dump the MAC Management Counter registers that are not counters? From what I understand it's only the Rx and Tx interrupt and interrupt mask registers that aren't counters. Oh, and the MMC control register itself? To be honest, I don't think their use can justify the code churn. > In either case you will get at best a snapshot of those two registers at any > given time and I suppose this can help diagnose a stuck RX condition, but > not much more than that. Yeah, their use is very doubtful. For me, they only introduce more nonsense data in my logs. The Rx registers looks to have been added in the first version of the MMC back in 2011, but the Tx registers never was. In commit 1c901a46d57 Giuseppe mentions the MMC interrupts as something to add later (if actually useful). So Serge's suggestion to drop the entries completely is actually quite attractive. > Florian /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nilsson@axis.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-19 10:40 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-16 15:24 [PATCH] net: stmmac: mmc_core: Assign, don't add interrupt registers Jesper Nilsson 2024-02-16 15:24 ` Jesper Nilsson 2024-02-16 17:13 ` Florian Fainelli 2024-02-16 17:13 ` Florian Fainelli 2024-02-16 18:24 ` Serge Semin 2024-02-16 18:24 ` Serge Semin 2024-02-19 10:40 ` Jesper Nilsson [this message] 2024-02-19 10:40 ` Jesper Nilsson 2024-02-19 20:17 ` Florian Fainelli 2024-02-19 20:17 ` Florian Fainelli 2024-02-20 10:51 ` Paolo Abeni 2024-02-20 10:51 ` Paolo Abeni
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240219104025.GM22484@axis.com \ --to=jesper.nilsson@axis.com \ --cc=alexandre.torgue@foss.st.com \ --cc=davem@davemloft.net \ --cc=edumazet@google.com \ --cc=f.fainelli@gmail.com \ --cc=joabreu@synopsys.com \ --cc=kernel@axis.com \ --cc=kuba@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-stm32@st-md-mailman.stormreply.com \ --cc=mcoquelin.stm32@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.