netdev - Re: [RFC PATCH 3/9] net: dsa: hellcreek: Add PTP clock support

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 Jun 2020 10:26:44 +0200
From:   Kurt Kanzenbach <kurt@...utronix.de>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Richard Cochran <richardcochran@...il.com>,
        Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
        ilias.apalodimas@...aro.org
Subject: Re: [RFC PATCH 3/9] net: dsa: hellcreek: Add PTP clock support

Hi Andrew,

On Thu Jun 18 2020, Andrew Lunn wrote:
>> +static u64 __hellcreek_ptp_clock_read(struct hellcreek *hellcreek)
>> +{
>> +	u16 nsl, nsh, secl, secm, sech;
>> +
>> +	/* Take a snapshot */
>> +	hellcreek_ptp_write(hellcreek, PR_COMMAND_C_SS, PR_COMMAND_C);
>> +
>> +	/* The time of the day is saved as 96 bits. However, due to hardware
>> +	 * limitations the seconds are not or only partly kept in the PTP
>> +	 * core. That's why only the nanoseconds are used and the seconds are
>> +	 * tracked in software. Anyway due to internal locking all five
>> +	 * registers should be read.
>> +	 */
>> +	sech = hellcreek_ptp_read(hellcreek, PR_SS_SYNC_DATA_C);
>> +	secm = hellcreek_ptp_read(hellcreek, PR_SS_SYNC_DATA_C);
>> +	secl = hellcreek_ptp_read(hellcreek, PR_SS_SYNC_DATA_C);
>> +	nsh  = hellcreek_ptp_read(hellcreek, PR_SS_SYNC_DATA_C);
>> +	nsl  = hellcreek_ptp_read(hellcreek, PR_SS_SYNC_DATA_C);
>> +
>> +	return (u64)nsl | ((u64)nsh << 16);
>
> Hi Kurt
>
> What are the hardware limitations? There seems to be 48 bits for
> seconds? That allows for 8925104 years?

In theory, yes. Due to hardware hardware considerations only a few or
none of these bits are used for the seconds. The rest is zero. Meaning
that the wraparound is not 8925104 years, but at e.g. 8 seconds when
using 3 bits for the seconds.

I've discussed this the Hirschmann people and they suggested to use the
nanoseconds only. That's what I did here.

>
>> +static u64 __hellcreek_ptp_gettime(struct hellcreek *hellcreek)
>> +{
>> +	u64 ns;
>> +
>> +	ns = __hellcreek_ptp_clock_read(hellcreek);
>> +	if (ns < hellcreek->last_ts)
>> +		hellcreek->seconds++;
>> +	hellcreek->last_ts = ns;
>> +	ns += hellcreek->seconds * NSEC_PER_SEC;
>
> So the assumption is, this gets called at least once per second. And
> if that does not happen, there is no recovery. The second is lost.

Yes, exactly. If a single overflow is missed, then the time is wrong.

>
> I'm just wondering if there is something more robust using what the
> hardware does provide, even if the hardware is not perfect.

I don't think there's a more robust way to do this. The overflow period
is a second which should be enough time to catch the overflow even if
the system is loaded. We did long running tests for days and the
mechanism worked fine. We could also consider to move the delayed work
to a dedicated thread which could be run with real time (SCHED_FIFO)
priority. But, I didn't see the need for it.

Thanks,
Kurt

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)