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]
Message-ID: <9955C44A-8105-4087-8555-BAC5AE4AF25D@walle.cc>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ