Re: [PATCH net-next 2/2] ptp: rework ptp_clock_unregister() to disable events

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Sep 16, 2025 at 08:46:28PM +0100, Russell King (Oracle) wrote:
> On Tue, Sep 16, 2025 at 05:20:19PM +0100, Vadim Fedorenko wrote:
> > On 16/09/2025 16:45, Russell King (Oracle) wrote:
> > > Having used NTP with a PPS sourced from a GPS, I'd personally want
> > > the PPS to stop if the GPS is no longer synchronised, so NTP knows
> > > that a fault has occurred, rather than PPS continuing but being
> > > undiscplined and thus of unknown accuracy.
> > > 
> > > I'd suggest that whether PPS continues to be generated should be a
> > > matter of user policy. I would suggest that policy should include
> > > whether or not userspace is discplining the clock - in other words,
> > > whether the /dev/ptp* device is open or not.
> > 
> > The deduction based on the amount of references to ptp device is not
> > quite correct. Another option is to introduce another flag and use it
> > as a signal to remove the function in case of error/shutdown/etc.
> > > Consider the case where the userspace daemons get OOM-killed and
> > > that isn't realised. The PPS signal continues to be generated but
> > > is now unsynchronised and drifts. Yet PPS users continue to
> > > believe it's accurate.
> > 
> > And again, there is another use-case which actually needs thisunsynchronised
> > signal
> 
> For my use case (Marvell platforms) we only support EXTTS there, so I'm
> happy to restrict this behaviour to EXTTS. If drivers need e.g. timers
> or workqueues to support the other pin functions, then this will need
> to be revisited so they can safely tear down their software resources.

I think I've missed another source of trouble here: PPS input, enabled
via PTP_CLK_REQ_PPS, which seems to be a purely software construct
where the hardware triggers e.g. an interrupt to forward a PPS event.

As this is not a pin, this doesn't get disabled. This is subject to
all the same race conditions that EXTTS is subject to, so I think
ptp_unregister_clock() needs to deal with this too.

New patches on their way shortly...

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