netdev - Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <c361070cc08063f19bbc5756714d677d5c649ed2.camel@oss.nxp.com>
Date:   Thu, 14 Oct 2021 15:27:29 +0200
From:   Sebastien Laveze <sebastien.laveze@....nxp.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        yangbo.lu@....com, yannick.vignon@....nxp.com,
        rui.sousa@....nxp.com
Subject: Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL

On Wed, 2021-10-13 at 10:54 -0700, Richard Cochran wrote:
> On Wed, Oct 13, 2021 at 03:28:12PM +0200, Sebastien Laveze wrote:
> > On Wed, 2021-10-13 at 06:10 -0700, Richard Cochran wrote:
> > > That means no control over the phase of the output signals.  Super.
> > 
> > You have. There's just a small conversion to go from and to the low-
> > level hardware counter. (Which also needs to be done for rx/tx
> > timestamps btw) 
> > When programming an output signal you use this offset to have the right
> > phase.
> 
> I have an i210 with 2 periodic output channels.  How am I supposed to
> generate signals from two different virtual PTP clocks?

Is it something currently supported to generate output signals from
virtual clocks ? (I would say no)

It seems to me that any periodic signal handled in hardware (scheduled
traffic for instance or periodic PPS) the hardware PHC frequency needs
to be adjusted.

For the offset, adjusting the PHC counter is not mandatory but requires
to re-configure any active hardware periodic logic. And here I'm not
saying it comes free. (especially if it would have to be supported by
all devices with PHC)

In this regard, we think that the capability to allow PHC adjustements
with virtual clocks may be on a per driver basis:
-driver exposes if it can make atomic offset adjustment or not
-if yes, allow PHC freq adjustments with a limited range. This range
can be known by userspace using PTP_CLOCK_GETCAPS. This limitation
doesn't have to be drastic but just here to prevent 10^6 ppm.

A limited adjustment remains an improvement vs no adjustment at all.

Thanks,
Sebastien