Received-SPF: pass (google.com: domain of linux-kernel+bounces-149062-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 17 Apr 2024 20:39:54 +0200
From: Andrew Lunn <andrew@lunn.ch>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: 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>,
	Richard Cochran <richardcochran@gmail.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
Message-ID: <c8e3f5d0-832b-4ab1-a65f-52f983ff110a@lunn.ch>
References: <20240417164316.1755299-1-o.rempel@pengutronix.de>
 <20240417164316.1755299-3-o.rempel@pengutronix.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240417164316.1755299-3-o.rempel@pengutronix.de>

On Wed, Apr 17, 2024 at 06:43:14PM +0200, Oleksij Rempel wrote:
> Set default PTP latency values to provide realistic path delay
> measurements and reflecting internal PHY latency asymetry.
> 
> This values are based on ptp4l measurements for the path delay against
> identical PHY as link partner and latency asymmetry extracted from
> documented SOF Latency values of this PHY.
> 
> Documented SOF Latency values are:
> TX 138ns/RX 430ns @ 1000Mbps
> TX 140ns/RX 615ns @ 100Mbps (fixed latency mode)
> TX 140ns/RX 488-524ns @ 100Mbps (variable latency mode)
> TX 654ns/227-2577ns @ 10Mbps

Does Half Duplex vs Full Duplex make a difference here?

> +static int lan8841_ptp_latency_init(struct phy_device *phydev)
> +{
> +	int ret;
> +
> +	ret = phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> +			    LAN8841_PTP_RX_LATENCY_10M,
> +			    LAN8841_PTP_RX_LATENCY_10M_VAL);
> +	if (ret)
> +		return ret;
> +
> +	ret = phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> +			    LAN8841_PTP_TX_LATENCY_10M,
> +			    LAN8841_PTP_TX_LATENCY_10M_VAL);
> +	if (ret)
> +		return ret;
> +
> +	ret = phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> +			    LAN8841_PTP_RX_LATENCY_100M,
> +			    LAN8841_PTP_RX_LATENCY_100M_VAL);
> +	if (ret)
> +		return ret;
> +
> +	ret = phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> +			    LAN8841_PTP_TX_LATENCY_100M,
> +			    LAN8841_PTP_TX_LATENCY_100M_VAL);
> +	if (ret)
> +		return ret;
> +
> +	ret = phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> +			    LAN8841_PTP_RX_LATENCY_1000M,
> +			    LAN8841_PTP_RX_LATENCY_1000M_VAL);
> +	if (ret)
> +		return ret;
> +
> +	return phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> +			     LAN8841_PTP_TX_LATENCY_1000M,
> +			     LAN8841_PTP_TX_LATENCY_1000M_VAL);
> +}

What affect does this have on systems which have already applied
adjustments in user space to correct for this? Will this cause
regressions for such systems?

I know Richard has rejected changes like this in the past.

	Andrew