From: Paolo Abeni <pabeni@redhat.com>
To: Vivian Wang <wangruikang@iscas.ac.cn>, Jakub Kicinski <kuba@kernel.org>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>, Yixun Lan <dlan@gentoo.org>,
Chukun Pan <amadeus@jmu.edu.cn>,
Michael Opdenacker <michael.opdenacker@rootcommit.com>,
netdev@vger.kernel.org, linux-riscv@lists.infradead.org,
spacemit@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net: spacemit: Clarify stat timeout comments and messages
Date: Thu, 22 Jan 2026 12:51:26 +0100 [thread overview]
Message-ID: <d9170bdd-140f-4d36-954d-76223e31b209@redhat.com> (raw)
In-Reply-To: <5639ff0c-dfd1-4528-a0ce-92d3c457ce64@iscas.ac.cn>
On 1/22/26 11:39 AM, Vivian Wang wrote:
> On 1/22/26 12:04, Jakub Kicinski wrote:
>> On Wed, 21 Jan 2026 10:17:18 +0800 Vivian Wang wrote:
>>> This patch isn't a fix for the problem per se, since it is hardware
>>> behavior. The new message and comments, however, should direct those
>>> running into this on new hardware towards a fix.
>> Is it not possible to improve the situation?
>
> Maybe I should have made it clearer, but this comment and messages
> improvement was proposed by Andrew in the linked thread [1].
>
> As an aside, saying that made me realize this patch should be:
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
>
>> Is the refclock disappearing because of power saving?
>> Or because the link is down?
>
> I'm not really well-versed in what's allowed from the PHY here, but at
> least the Motorcomm and Realtek PHYs seem to only stop this clock while
> the link is down. So from what I can tell it's PHY stopping the clock
> because of power saving for when the link is down. I'm not sure how that
> should translate into an answer to your question here...
>
>> Because if it's the latter we should be able to skip reading the stats
>> when link is down (still racy but better than waiting in cases we can
>> detect?)
>
> If checking the link is definitely up as a condition for updating stats
> would be acceptable, then maybe the original patch from the linked
> thread [2] can also be adopted?
My understanding is that such option would fit Jakub's suggestion. Note
that the commit message should be expanded and clarified WRT the
original submission.
/P
next prev parent reply other threads:[~2026-01-22 11:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 2:17 [PATCH net v2] net: spacemit: Clarify stat timeout comments and messages Vivian Wang
2026-01-22 4:04 ` Jakub Kicinski
2026-01-22 10:39 ` Vivian Wang
2026-01-22 11:51 ` Paolo Abeni [this message]
2026-01-22 15:30 ` Jakub Kicinski
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=d9170bdd-140f-4d36-954d-76223e31b209@redhat.com \
--to=pabeni@redhat.com \
--cc=amadeus@jmu.edu.cn \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=dlan@gentoo.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=michael.opdenacker@rootcommit.com \
--cc=netdev@vger.kernel.org \
--cc=spacemit@lists.linux.dev \
--cc=wangruikang@iscas.ac.cn \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox