linux-kernel - 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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 13 Oct 2021 15:28:12 +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 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.

> But you can't make the end users respect that.  In many cases in the
> wild, the GM offset changes suddenly for various reasons, and then the
> clients slew at max adjustment.  So there is no expectation of
> "limited frequency adjustments."

Even if very high, there are already some limitations which are driver
specific.
We wouldn't be changing the current "regular" API but only adding some
limitations in the specific case of virtual clocks usage (added by the
user btw). This is less limitating than preventing any adjustment at
all.

Thanks,
Sebastien