Re: [PATCH net-next 0/2] net: stmmac: allow generation of flexible PPS relative to MAC time

[Gatien CHEVALLIER]

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