All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Richard Cochran <richardcochran@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	"David S. Miller" <davem@davemloft.net>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Woojung Huh <woojung.huh@microchip.com>,
	Arun Ramadoss <arun.ramadoss@microchip.com>,
	Russell King <linux@armlinux.org.uk>,
	kernel@pengutronix.de, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, UNGLinuxDriver@microchip.com,
	linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH net-next v1 2/4] net: phy: micrel: lan8841: set default PTP latency values
Date: Tue, 23 Apr 2024 09:07:59 +0200	[thread overview]
Message-ID: <ZideTxpOcPTbR9yt@pengutronix.de> (raw)
In-Reply-To: <ZiITWEZgTx9aPqIy@hoboy.vegasvil.org>

Hi Richard,

On Thu, Apr 18, 2024 at 11:46:48PM -0700, Richard Cochran wrote:
> On Wed, Apr 17, 2024 at 10:23:07PM +0200, Andrew Lunn wrote:
> > I suggest you go read older messages from Richard. It was a discussion
> > with Microchip about one of their PHYs.
> 
> My 2 cents:
> 
> User space has all of the hooks needed to configure corrections for a
> given setup.
> 
> Hard coding corrections in device drivers is bound to fail, based on
> prior experience with Vendors not knowing or caring how their products
> actually work.  Vendors will publish value X one year, then delete the
> info (to avoid embarrassment), then publish the new value Y, once
> customers have forgotten about X.
> 
> So, prudent users will always calibrate their beloved systems, not
> trusting the Vendors to provide anything close to reasonable.
> 
> Ergo, adding new magical correction in a kernel release causes
> regressions for prudent users.
> 
> But, in the end, that doesn't matter, because prudent users are used
> to being abused by well-meaning yet misguided device driver authors.
> 
> Prudent users are wise, and they will re-calibrate their systems
> before rolling out an updated kernel.

Ok, i see. Thank you for your feedback.

Are the recommended FOSS projects managing calibration values per-
linkmode/port/device in user space?

What is recommended way for calibration? Using some recommended device?

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2024-04-23  7:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17 16:43 [PATCH net-next v1 0/4] add support for TimeSync path delays Oleksij Rempel
2024-04-17 16:43 ` [PATCH net-next v1 1/4] net: phy: Add TimeSync delay query support to PHYlib API Oleksij Rempel
2024-04-17 18:33   ` Andrew Lunn
2024-04-17 18:48   ` Woojung.Huh
2024-04-17 16:43 ` [PATCH net-next v1 2/4] net: phy: micrel: lan8841: set default PTP latency values Oleksij Rempel
2024-04-17 18:39   ` Andrew Lunn
2024-04-17 20:12     ` Oleksij Rempel
2024-04-17 20:23       ` Andrew Lunn
2024-04-19  6:46         ` Richard Cochran
2024-04-23  7:07           ` Oleksij Rempel [this message]
2024-04-24  6:10             ` Richard Cochran
2024-04-17 16:43 ` [PATCH net-next v1 3/4] net: phy: realtek: provide TimeSync data path delays for RTL8211E Oleksij Rempel
2024-04-18  5:39   ` kernel test robot
2024-04-17 16:43 ` [PATCH net-next v1 4/4] net: stmmac: use delays reported by the PHY driver to correct MAC propagation delay Oleksij Rempel
2024-04-17 19:13   ` Serge Semin

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=ZideTxpOcPTbR9yt@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew@lunn.ch \
    --cc=arun.ramadoss@microchip.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=joabreu@synopsys.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux@armlinux.org.uk \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=woojung.huh@microchip.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.