From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Richard Cochran <richardcochran@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Marcin Wojtas <marcin.s.wojtas@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next v3] net: mvpp2: tai: warn once if we fail to update our timestamp
Date: Thu, 2 Jan 2025 16:26:04 +0000 [thread overview]
Message-ID: <Z3a-HOwAVyJGEg67@shell.armlinux.org.uk> (raw)
In-Reply-To: <Z10UGg_osMZ6TZrc@hoboy.vegasvil.org>
On Fri, Dec 13, 2024 at 09:14:02PM -0800, Richard Cochran wrote:
> On Fri, Dec 13, 2024 at 04:34:06PM +0000, Russell King wrote:
> > The hardware timestamps for packets contain a truncated seconds field,
> > only containing two bits of seconds. In order to provide the full
> > number of seconds, we need to keep track of the full hardware clock by
> > reading it every two seconds.
> >
> > However, if we fail to read the clock, we silently ignore the error.
> > Print a warning indicating that the PP2 TAI clock timestamps have
> > become unreliable.
>
> Rather than printing a warning that user space might not read, why not
> set a flag and stop delivering time stamps until the upper bits are
> available once again?
If we fail to read the clock, that will be because the hardware didn't
respond to our request to read it, which means the hardware broke in
some way. We could make mvpp22_tai_tstamp() fail and not provide
timestamps until we have successfully read the HW clock, but we would
still want to print a warning to explain why HW timestamps vanish.
However, if this happens, then it also means that the gettimex64 PTP
clock ioctl will also fail, so I would suggest that the user would
find out about it anyway.
So, I don't think the extra complexity is worth doing.
This is to catch a spurious failure that may only affects an occasoinal
attempt to read the HW PTP time. Currently, we would never know,
because the kernel is currently completely silent if that were to ever
happen.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2025-01-02 16:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-13 16:34 [PATCH net-next v3] net: mvpp2: tai: warn once if we fail to update our timestamp Russell King
2024-12-14 5:14 ` Richard Cochran
2025-01-02 16:26 ` Russell King (Oracle) [this message]
2025-01-03 8:43 ` Richard Cochran
2025-01-03 9:08 ` Russell King (Oracle)
2025-01-03 9:16 ` Russell King (Oracle)
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=Z3a-HOwAVyJGEg67@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=marcin.s.wojtas@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.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: 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;
as well as URLs for NNTP newsgroup(s).