[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f7849436-8dac-64b1-8ec6-3aced13bee94@pengutronix.de>
Date: Thu, 27 Jul 2023 08:40:51 +0200
From: Johannes Zink <j.zink@...gutronix.de>
To: Richard Cochran <richardcochran@...il.com>,
Marc Kleine-Budde <mkl@...gutronix.de>
Cc: kernel test robot <lkp@...el.com>, "David S. Miller"
<davem@...emloft.net>, Russell King <linux@...linux.org.uk>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Eric Dumazet <edumazet@...gle.com>, Jose Abreu <joabreu@...opsys.com>,
linux-arm-kernel@...ts.infradead.org, kernel@...gutronix.de,
Giuseppe Cavallaro <peppe.cavallaro@...com>, Jakub Kicinski
<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
linux-stm32@...md-mailman.stormreply.com,
Maxime Coquelin <mcoquelin.stm32@...il.com>, patchwork-jzi@...gutronix.de
Subject: Re: [PATCH v2] net: stmmac: correct MAC propagation delay
Hi Richard,
On 7/26/23 17:34, Richard Cochran wrote:
> On Wed, Jul 26, 2023 at 08:04:37AM +0200, Marc Kleine-Budde wrote:
>
>> At least the datasheet of the IP core tells to read the MAC delay from
>> the IP core (1), add the PHY delay (2) and the clock domain crossing
>> delay (3) and write it to the time stamp correction register.
>
> That is great, until they change the data sheet. Really, this happens.
I think I don't get your point here.
That's true for literally any register of any peripheral in a datasheet.
I think we can just stop doing driver development if we wait for a final
revision that is not changed any more. Datasheets change, and if they do we
update the driver.
Johannes
>
> Thanks,
> Richard
>
>
--
Pengutronix e.K. | Johannes Zink |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686| Fax: +49-5121-206917-5555 |
Powered by blists - more mailing lists