From: Richard Cochran <richardcochran@gmail.com>
To: Michael Walle <michael@walle.cc>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [RFC PATCH v2 0/2] AT8031 PHY timestamping support
Date: Sat, 29 Feb 2020 06:48:18 -0800 [thread overview]
Message-ID: <20200229144818.GB25147@localhost> (raw)
In-Reply-To: <979b0b89b2610c105310e733e98cd862@walle.cc>
On Fri, Feb 28, 2020 at 08:43:05PM +0100, Michael Walle wrote:
>
> 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.
I appreciate your publishing this work. It is a good starting place.
Maybe the vendor will wake up and help this along. One can always hope.
> 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.
I see. Mysterious. For a Sync frame, I can't think of any
"corresponding RX packet".
> (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.
It would not be that bad. Some of the MAC cards can only buffer one
Tx time stamp, and for this reason, the ptp4l program always fetches
the time stamp immediately after sending.
Thanks,
Richard
prev parent reply other threads:[~2020-02-29 14:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 18:02 [RFC PATCH v2 0/2] AT8031 PHY timestamping support Michael Walle
2020-02-28 18:02 ` [RFC PATCH v2 1/2] net: phy: let the driver register its own IRQ handler Michael Walle
2020-02-28 18:02 ` [RFC PATCH v2 2/2] net: phy: at803x: add PTP support for AR8031 Michael Walle
2020-03-01 12:22 ` Richard Cochran
2020-02-28 18:15 ` [RFC PATCH v2 0/2] AT8031 PHY timestamping support Richard Cochran
2020-02-28 19:43 ` Michael Walle
2020-02-29 14:48 ` Richard Cochran [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200229144818.GB25147@localhost \
--to=richardcochran@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=michael@walle.cc \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).