linux-kernel - Re: [RFC PATCH 0/2] AT8031 PHY timestamping 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:   Wed, 26 Feb 2020 01:07:26 +0100
From:   Michael Walle <michael@...le.cc>
To:     Andrew Lunn <andrew@...n.ch>
CC:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S . Miller" <davem@...emloft.net>,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [RFC PATCH 0/2] AT8031 PHY timestamping support

Am 26. Februar 2020 00:50:40 MEZ schrieb Andrew Lunn <andrew@...n.ch>:
>On Wed, Feb 26, 2020 at 12:08:17AM +0100, Michael Walle wrote:
>> This patchset is the current state of my work for adding PHY
>timestamping
>> support. I just wanted to post this to the mailinglist before I never
>do
>> it. Maybe its a starting point for other people. That being said, I
>> wouldn't mind comments ;) The code basically works but there are
>three
>> major caveats:
>> 
>>  (1) The reading of timestamps via MDIO sometimes return wrong
>values. What
>>      I see is that a part of the timestamp corresponds to the new
>timestamp
>> 	 while another part still contains old values. Thus at the moment,
>I'm
>> 	 reading the registers twice. I don't know if the reading actually
>> 	 affects the update of the timestamp or the different timing (my
>MDIO
>> 	 bus is rather slow, so reading the timestamp a second time take
>some
>> 	 amount of time; but I've also tested with some delays and it didn't
>> 	 had any effects). There is also no possibility to read the
>timestamp
>> 	 atomically :(
>
>Hi Michael
>
>That sounds fundamentally broken. Which would be odd. Sometimes there
>is a way to take a snapshot of the value. Reading the first word could
>trigger this snapshot. Or the last word, or some status register. One
>would hope the datasheet would talk about this.

Hi Andrew

This might be the case, but the datasheet (some older revision can be found on the internet, maybe you find something) doesn't mention it. Nor does the PTP "guide" (I don't know the exact name, I'd have to check at work) of this PHY. Besides the timestamp there's also the sequence number and the source port id which would need to be read atomically together with the timestamp. 

I might give it a try reading the whole tx or rx block (sequenceId, sourcePortId, timestamp) sequentially. 

-michael