[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aTLuSZugpZDNCRzf@hoboy.vegasvil.org>
Date: Fri, 5 Dec 2025 06:38:01 -0800
From: Richard Cochran <richardcochran@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Paolo Abeni <pabeni@...hat.com>,
Rohan G Thomas <rohan.g.thomas@...era.com>,
Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Jose Abreu <Jose.Abreu@...opsys.com>,
Fugang Duan <fugang.duan@....com>,
Kurt Kanzenbach <kurt@...utronix.de>, netdev@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2] net: stmmac: Fix E2E delay mechanism
On Thu, Dec 04, 2025 at 11:19:01AM +0000, Russell King (Oracle) wrote:
> Basically, the conclusion I am coming to is that Synopsys's idea
> of "lets tell the hardware what _kind_ of PTP clock we want to be,
> whether we're master, etc" is subject to multiple revisions in
> terms of which messages each mode selects, and it would have been
> _far_ simpler and easier to understand had they just provided a
> 16-bit bitfield of message types to accept.
Encoding the PTP role in the hardware is a fundamentally stupid idea,
because it makes changing roles (which is a normal and expected)
impossible without losing time stamps during the transition. Some
early PTP hardware designs had this defect, but vendors figured it out
in the second generation of cards.
Thanks,
Richard
Powered by blists - more mailing lists