[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZMCRjcRF9XqEPg/Z@hoboy.vegasvil.org>
Date: Tue, 25 Jul 2023 20:22:53 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Johannes Zink <j.zink@...gutronix.de>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Russell King <linux@...linux.org.uk>,
patchwork-jzi@...gutronix.de, netdev@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
kernel@...gutronix.de, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v2] net: stmmac: correct MAC propagation delay
On Tue, Jul 25, 2023 at 08:06:06PM -0700, Jakub Kicinski wrote:
> any opinion on this one?
Yeah, I saw it, but I can't get excited about drivers trying to
correct delays. I don't think this can be done automatically in a
reliable way, and so I expect that the few end users who are really
getting into the microseconds and nanoseconds will calibrate their
systems end to end, maybe even patching out this driver nonsense in
their kernels.
Having said that, I won't stand in the way of such driver stuff.
After all, who cares about a few microseconds time error one way or
the other?
Thanks,
Richard
Powered by blists - more mailing lists