When doing some testing on stm32mp2x platforms(MACv5), I noticed that
the command previously used with a MACv4 for genering a PPS signal:
echo "0 0 0 1 1" > /sys/class/ptp/ptp0/period
did not work.

This is because the arguments passed through this command must contain
the start time at which the PPS should be generated, relative to the
MAC system time. For some reason, a time set in the past seems to work
with a MACv4.

Because passing such an argument is tedious, introduce
STMMAC_RELATIVE_FLEX_PPS config switch so that the MAC system time
is added to the args to the stmmac_ptp driver.

Example to generate a flexible PPS signal that has a 1s period 3s
relative to when the command was entered before and after setting
STMMAC_RELATIVE_FLEX_PPS:

Before: echo "0 175xxxxxxx 0 1 1" > /sys/class/ptp/ptp0/period

After: echo "0 3 0 1 1" > /sys/class/ptp/ptp0/period

Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
Gatien Chevallier (2):
      drivers: net: stmmac: add STMMAC_RELATIVE_FLEX_PPS
      net: stmmac: select STMMAC_RELATIVE_FLEX_PPS for stm32 SoCs

 drivers/net/ethernet/stmicro/stmmac/Kconfig      | 10 ++++++++++
 drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c | 13 +++++++++++++
 2 files changed, 23 insertions(+)
---
base-commit: 8aad37d16cffb6c0940d9b213456a2733a786f57
change-id: 20250723-relative_flex_pps-faa2fbcaf835

Best regards,
-- 
Gatien Chevallier <gatien.chevallier@foss.st.com>

On Thu, 24 Jul 2025 14:31:17 +0200 Gatien Chevallier wrote:
> When doing some testing on stm32mp2x platforms(MACv5), I noticed that
> the command previously used with a MACv4 for genering a PPS signal:
> echo "0 0 0 1 1" > /sys/class/ptp/ptp0/period
> did not work.
> 
> This is because the arguments passed through this command must contain
> the start time at which the PPS should be generated, relative to the
> MAC system time. For some reason, a time set in the past seems to work
> with a MACv4.
> 
> Because passing such an argument is tedious, introduce
> STMMAC_RELATIVE_FLEX_PPS config switch so that the MAC system time
> is added to the args to the stmmac_ptp driver.
> 
> Example to generate a flexible PPS signal that has a 1s period 3s
> relative to when the command was entered before and after setting
> STMMAC_RELATIVE_FLEX_PPS:
> 
> Before: echo "0 175xxxxxxx 0 1 1" > /sys/class/ptp/ptp0/period
> 
> After: echo "0 3 0 1 1" > /sys/class/ptp/ptp0/period

Kconfig doesn't seem like a great way of achieving the outcome.
Some per-platform knob would be better.
But ideally we wouldn't do either. Could we possibly guess which
format user has chosen based on the values, at runtime?

On 7/26/25 02:25, Jakub Kicinski wrote:
> On Thu, 24 Jul 2025 14:31:17 +0200 Gatien Chevallier wrote:
>> When doing some testing on stm32mp2x platforms(MACv5), I noticed that
>> the command previously used with a MACv4 for genering a PPS signal:
>> echo "0 0 0 1 1" > /sys/class/ptp/ptp0/period
>> did not work.
>>
>> This is because the arguments passed through this command must contain
>> the start time at which the PPS should be generated, relative to the
>> MAC system time. For some reason, a time set in the past seems to work
>> with a MACv4.
>>
>> Because passing such an argument is tedious, introduce
>> STMMAC_RELATIVE_FLEX_PPS config switch so that the MAC system time
>> is added to the args to the stmmac_ptp driver.
>>
>> Example to generate a flexible PPS signal that has a 1s period 3s
>> relative to when the command was entered before and after setting
>> STMMAC_RELATIVE_FLEX_PPS:
>>
>> Before: echo "0 175xxxxxxx 0 1 1" > /sys/class/ptp/ptp0/period
>>
>> After: echo "0 3 0 1 1" > /sys/class/ptp/ptp0/period
> 
> Kconfig doesn't seem like a great way of achieving the outcome.
> Some per-platform knob would be better.
> But ideally we wouldn't do either. Could we possibly guess which
> format user has chosen based on the values, at runtime?

Hello Jakub,

There are two reasons for which I chose this approach:
1) I did not want to affect other platforms and possibly
break scripts that work with the current behavior. Is it
acceptable to do otherwise? If so, maybe there's no need
for a config switch or a per-platform implementation.
2) SoCs may implement more than one MAC and the system
time for these MACs may or may not be synced + the system
time maintained by a MAC may not be a value that represents
a date.

For these reasons, I'm not sure we can rely on the values
that were given to stmmac_enable() to deduce what behavior
we choose. The ptp_clock_request() structure does not hold
loads of information as well.

Maybe we could compare the time to the current MAC system
time and, if the start time is in the past, consider the
value to be an offset. Therefore, any value set in the past
would be considered as an offset. I see some implementations
doing either that or replacing any value set in the past to
a safe start + a fixed offset.

Best regards,
Gatien

On Mon, 28 Jul 2025 10:15:07 +0200 Gatien CHEVALLIER wrote:
> Maybe we could compare the time to the current MAC system
> time and, if the start time is in the past, consider the
> value to be an offset. Therefore, any value set in the past
> would be considered as an offset. I see some implementations
> doing either that or replacing any value set in the past to
> a safe start + a fixed offset.

Let's try this.

On 7/28/25 17:58, Jakub Kicinski wrote:
> On Mon, 28 Jul 2025 10:15:07 +0200 Gatien CHEVALLIER wrote:
>> Maybe we could compare the time to the current MAC system
>> time and, if the start time is in the past, consider the
>> value to be an offset. Therefore, any value set in the past
>> would be considered as an offset. I see some implementations
>> doing either that or replacing any value set in the past to
>> a safe start + a fixed offset.
> 
> Let's try this.

Ok, I sent a V2 with a proposal implementing this behavior.
Thank you.