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

Hi Richard,

Am 2020-02-28 19:15, schrieb Richard Cochran:
> On Fri, Feb 28, 2020 at 07:02:24PM +0100, Michael Walle wrote:
>>  (1) The PHY doesn't support atomic reading of the (timestamp,
>>      messageType, sequenceId) tuple. The workaround is to read the
>>      timestamp again and check if it has changed. Actually, you'd have
>>      to read the complete tuple again.
> 
> This HW is broken by design :(

Yeah, I know. And actually I don't think I'll pursue this further. Like 
I
said, I just wanted to my current work. Maybe it will be useful in the
future who knows.

>> But if you're using a P2P clock with peer delay requests this whole
>> thing falls apart because of caveat (3). You'll often see messages 
>> like
>>   received SYNC without timestamp
>> or
>>  received PDELAY_RESP without timestamp
>> in linuxptp. Sometimes it working for some time and then it starts to
>> loosing packets. I suspect this depends on how the PDELAY messages are
>> interleaved with the SYNC message. If there is not enough time to 
>> until
>> the next event message is received either of these two messages won't
>> have a timestamp.
> 
> And even the case where a Sync and a DelayResp arrive at nearly the
> same time will fail.
> 
>> The PHY also supports appending the timestamp to the actual ethernet 
>> frame,
>> but this seems to only work when the PHY is connected via RGMII. I've 
>> never
>> get it to work with a SGMII connection.
> 
> This is the way to go.  I would try to get the vendor's help in making
> this work.

Like I said, our FAE is pretty unresponsive. But I'll at least try to 
find
out if my guess is correct (that it only works with RGMII). But even 
then,
how should the outgoing timestamping work. There are two possibilities:

  (1) According to the datasheet, the PHY will attach the TX timestamp to
      the corresponding RX packet; whatever that means. Lets assume there
      is such a "corresponding packet", then we would be at the mercy of 
the
      peer to actually send such a packet, let alone in a timely manner.
  (2) Mixing both methods. Use attached timestamps for RX packets, read 
the
      timestamp via PHY registers for TX packets. Theoretically, we could
      control how the packets are send and make sure, we fetch the TX
      timestamp before sending another PTP packet. But well.. sounds 
really
      hacky to me.

-michael