netdev - Re: [PATCH] ptp: Add PTP_CLOCK_EXTTSUSR internal ptp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210629001928.yhiql2dngstkpadb@bsd-mbp.dhcp.thefacebook.com>
Date:   Mon, 28 Jun 2021 17:19:28 -0700
From:   Jonathan Lemon <jonathan.lemon@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     netdev@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH] ptp: Add PTP_CLOCK_EXTTSUSR internal ptp_event

On Mon, Jun 28, 2021 at 04:30:56PM -0700, Richard Cochran wrote:
> On Mon, Jun 28, 2021 at 11:46:11AM -0700, Jonathan Lemon wrote:
> > This event differs from CLOCK_EXTTS in two ways:
> > 
> >  1) The caller provides the sec/nsec fields directly, instead of
> >     needing to convert them from the timestamp field.
> 
> And that is useful?  how?

The devices I have provide the sec/nsec values directly from the
FPGA/hardware.  (IIRC, there is another in-tree driver that does
the same thing).  Right now, these values must be coerced into a
timestap, and then re-converted back to a sec/nsec value, which
seems a bit pointless.

> >  2) A 32 bit data field is attached to the event, which is returned
> >     to userspace, which allows returning timestamped data information.
> >     This may be used for things like returning the phase difference
> >     between two time sources.
> 
> What two time sources?
> 
> What problem are you trying to solve?
> 
> As it stands, without any kind of rational at all, this patch gets a NAK.

I have two use cases:

1) The external PPS source from the FPGA returns a counter
   corresponding to the pulse events which is used to insure
   a pulse isn't lost.   This is a marginal case, since the 
   counter can be reverse engineered from the timestamp.

2) The OpenCompute timecard has an on-board rubidium atomic
   clock, and also a GPS receiver.  The atomic clock needs 
   to be steered slightly to keep thse in phase.

   The PPS from the clock and GPS are measured and the 
   phase difference/error is reported every second.  This
   difference is then used to steer the clock, so it can 
   reliably take over in case of GPS loss.

   So, I need a PPS (with timestamp), along with the phase
   difference (data).

This fits in nicely with the extts event model.  I really
don't want to have to re-invent another ptp_chardev device
that does the same thing - nor recreate a extended PTP.
-- 
Jonathan