From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Kory Maincent <kory.maincent@bootlin.com>
Cc: "Maxime Chevallier" <maxime.chevallier@bootlin.com>,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"Jose Abreu" <joabreu@synopsys.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
davem@davemloft.net, "Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Richard Cochran" <richardcochran@gmail.com>,
"Alexis Lothoré" <alexis.lothore@bootlin.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 3/3] net: ethtool: tsconfig: Re-configure hwtstamp upon provider change
Date: Thu, 16 Oct 2025 09:53:12 +0100 [thread overview]
Message-ID: <aPCyeCOMX7FHnZkY@shell.armlinux.org.uk> (raw)
In-Reply-To: <20251015144526.23e55ee0@kmaincent-XPS-13-7390>
On Wed, Oct 15, 2025 at 02:45:26PM +0200, Kory Maincent wrote:
> On Wed, 15 Oct 2025 12:27:23 +0200
> Maxime Chevallier <maxime.chevallier@bootlin.com> wrote:
>
> > When a hwprov timestamping source is changed, but without updating the
> > timestamping parameters, we may want to reconfigure the timestamping
> > source to enable the new provider.
> >
> > This is especially important if the same HW unit implements 2 providers,
> > a precise and an approx one. In this case, we need to make sure we call
> > the hwtstamp_set operation for the newly selected provider.
>
> This is a design choice.
> Do we want to preserve the hwtstamp config if only the hwtstamp source is
> changed from ethtool?
This depends what is meant by "preserve". If the hwtstamp capabilities
of the two sources being switched between are the same in terms of how
userspace configures them, then it's fine.
However, it's my understanding that the hwtstamp configuration is a
negotiation between kernel and userspace - drivers are required to
return back to userspace what they're actually doing when userspace
requests a certain configuration. If the hwtstamp capabilities are
different, it breaks this model because what the previous instance
reports back to userspace for a certain configuration could be
different to that which the new instance would report back.
This could get worse when a configuration is set on the previous
instance that isn't supported by the new instance.
--
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-10-16 8:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 10:27 [PATCH net-next 0/3] net: stmmac: Add support for coarse timestamping Maxime Chevallier
2025-10-15 10:27 ` [PATCH net-next 1/3] net: stmmac: Move subsecond increment configuration in dedicated helper Maxime Chevallier
2025-10-15 15:06 ` Russell King (Oracle)
2025-10-15 16:20 ` Maxime Chevallier
2025-10-15 17:20 ` Russell King (Oracle)
2025-10-15 10:27 ` [PATCH net-next 2/3] net: stmmac: Allow supporting coarse adjustment mode Maxime Chevallier
2025-10-18 1:23 ` Jakub Kicinski
2025-10-18 7:42 ` Maxime Chevallier
2025-10-20 9:00 ` Kory Maincent
2025-10-20 9:32 ` Maxime Chevallier
2025-10-20 12:52 ` Kory Maincent
2025-10-21 1:03 ` Jakub Kicinski
2025-10-21 8:02 ` Maxime Chevallier
2025-10-21 23:02 ` Jakub Kicinski
2025-10-23 8:29 ` Maxime Chevallier
2025-10-23 8:35 ` Kory Maincent
2025-10-15 10:27 ` [PATCH net-next 3/3] net: ethtool: tsconfig: Re-configure hwtstamp upon provider change Maxime Chevallier
2025-10-15 12:45 ` Kory Maincent
2025-10-16 8:01 ` Maxime Chevallier
2025-10-16 8:44 ` Kory Maincent
2025-10-16 8:53 ` Russell King (Oracle) [this message]
2025-10-15 12:55 ` [PATCH net-next 0/3] net: stmmac: Add support for coarse timestamping Kory Maincent
2025-10-16 8:14 ` Maxime Chevallier
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=aPCyeCOMX7FHnZkY@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=alexandre.torgue@foss.st.com \
--cc=alexis.lothore@bootlin.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=joabreu@synopsys.com \
--cc=kory.maincent@bootlin.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=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=thomas.petazzoni@bootlin.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).