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]

Message-ID: <20200225235040.GF9749@lunn.ch>
Date:   Wed, 26 Feb 2020 00:50:40 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Michael Walle <michael@...le.cc>
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

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.

      Andrew