netdev - Re: [PATCH net-next 0/3] Unlock new potential in SJA1105 with PTP system timestamping

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:   Mon, 11 Nov 2019 12:45:47 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     olteanv@...il.com
Cc:     richardcochran@...il.com, andrew@...n.ch, f.fainelli@...il.com,
        vivien.didelot@...il.com, jakub.kicinski@...ronome.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/3] Unlock new potential in SJA1105 with PTP
 system timestamping

From: Vladimir Oltean <olteanv@...il.com>
Date: Sat,  9 Nov 2019 13:32:21 +0200

> The SJA1105 being an automotive switch means it is designed to live in a
> set-and-forget environment, far from the configure-at-runtime nature of
> Linux. Frequently resetting the switch to change its static config means
> it loses track of its PTP time, which is not good.
> 
> This patch series implements PTP system timestamping for this switch
> (using the API introduced for SPI here:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg316725.html),
> adding the following benefits to the driver:
> - When under control of a user space PTP servo loop (ptp4l, phc2sys),
>   the loss of sync during a switch reset is much more manageable, and
>   the switch still remains in the s2 (locked servo) state.
> - When synchronizing the switch using the software technique (based on
>   reading clock A and writing the value to clock B, as opposed to
>   relying on hardware timestamping), e.g. by using phc2sys, the sync
>   accuracy is vastly improved due to the fact that the actual switch PTP
>   time can now be more precisely correlated with something of better
>   precision (CLOCK_REALTIME). The issue is that SPI transfers are
>   inherently bad for measuring time with low jitter, but the newly
>   introduced API aims to alleviate that issue somewhat.
> 
> This series is also a requirement for a future patch set that adds full
> time-aware scheduling offload support for the switch.

Series applied, thank you.