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]
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

Powered by blists - more mailing lists