Add the STMMAC_RELATIVE_FLEX_PPS config switch so that the MAC system
time is added to the requested start time when configuring the flexible
PPS signal start time.

This eases the configuration of the generation of flexible PPS signals.

Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig      |  9 +++++++++
 drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c | 13 +++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 67fa879b1e521ef6d7bd2a8db30d812301eb4cf7..949c744d30f19f5ff480dca4811e678d2b93c450 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -357,3 +357,12 @@ config STMMAC_PCI
 
 	  If unsure, say N.
 endif
+
+config STMMAC_RELATIVE_FLEX_PPS
+	bool "Support for STMMAC system time relative flexible PPS generation"
+	default n
+	help
+	  Say Y to add the MAC system time to the arguments passed to the
+	  PTP driver when requesting a flexible PPS generation. This avoids
+	  the tedious task of passing an absolute time value when using sysfs
+	  entry.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
index 3767ba495e78d210b0529ee1754e5331f2dd0a47..cc898eab4df6a3e2530a8b03dfdaa9016d1bb0b9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
@@ -180,6 +180,19 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
 
 		cfg->start.tv_sec = rq->perout.start.sec;
 		cfg->start.tv_nsec = rq->perout.start.nsec;
+		if (IS_ENABLED(CONFIG_STMMAC_RELATIVE_FLEX_PPS)) {
+			struct timespec64 curr_time;
+			u64 ns = 0;
+
+			/* Be aware that an offset too low may not trigger flexible PPS generation
+			 * if time spent in this configuration makes this relative time already
+			 * outdated.
+			 */
+			stmmac_get_systime(priv, priv->ptpaddr, &ns);
+			curr_time = ns_to_timespec64(ns);
+			cfg->start.tv_sec += curr_time.tv_sec;
+			cfg->start.tv_nsec += curr_time.tv_nsec;
+		}
 		cfg->period.tv_sec = rq->perout.period.sec;
 		cfg->period.tv_nsec = rq->perout.period.nsec;
 

-- 
2.25.1

On Thu, Jul 24, 2025 at 02:31:18PM +0200, Gatien Chevallier wrote:
> +config STMMAC_RELATIVE_FLEX_PPS
> +	bool "Support for STMMAC system time relative flexible PPS generation"
> +	default n

There is no need for "default n" because the default default is n.

> +	help
> +	  Say Y to add the MAC system time to the arguments passed to the
> +	  PTP driver when requesting a flexible PPS generation. This avoids
> +	  the tedious task of passing an absolute time value when using sysfs
> +	  entry.

How does a distro decide whether to enable or disable this option? What
does it depend on?

If it's only for some platforms and not others (due to causing
regressions) then what is a distro supposed to do with their kernels
that support multiple platforms?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

On 8/5/25 12:30, Russell King (Oracle) wrote:
> On Thu, Jul 24, 2025 at 02:31:18PM +0200, Gatien Chevallier wrote:
>> +config STMMAC_RELATIVE_FLEX_PPS
>> +	bool "Support for STMMAC system time relative flexible PPS generation"
>> +	default n
> 
> There is no need for "default n" because the default default is n.
>

>> +	help
>> +	  Say Y to add the MAC system time to the arguments passed to the
>> +	  PTP driver when requesting a flexible PPS generation. This avoids
>> +	  the tedious task of passing an absolute time value when using sysfs
>> +	  entry.
> 
> How does a distro decide whether to enable or disable this option? What
> does it depend on?
> 
> If it's only for some platforms and not others (due to causing
> regressions) then what is a distro supposed to do with their kernels
> that support multiple platforms?
> 

Hello Russell,

Following Jakub's feedback, I sent a v2 [1] with this config removed.
The idea now is to compare the time value given to the stmmac_ptp driver
and compare it to the MAC system time. If the time value is is the past,
relative to the MAC system time, then it is considered as an offset
relative the the MAC system time.

It's not ideal as it would have probably been better to always consider
an offset but I don't know how popular and used this feature currently
is. Therefore, I did not want to break any existing script by changing
the current behavior.

I'd be very interested to have your take on this as well.

 From what I observed, it's linked to the MAC version. So enabling this
config would have meant knowing what MAC version is embedded. Supporting
multiple platforms then becomes tricky.

[1]: 
https://lore.kernel.org/all/20250729-relative_flex_pps-v2-0-3e5f03525c45@foss.st.com/