[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190530142356.vxkhsjalxfytvx2c@localhost>
Date: Thu, 30 May 2019 07:23:56 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Andrew Lunn <andrew@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
John Stultz <john.stultz@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Stephen Boyd <sboyd@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 3/5] net: dsa: mv88e6xxx: Let taggers specify a
can_timestamp function
On Thu, May 30, 2019 at 10:42:41AM +0300, Vladimir Oltean wrote:
> The meta frames generated by the SJA1105 do not contain any seqid.
So this cannot ever work...
> They contain:
> * A globally programmable DMAC
> * A globally programmable SMAC
Don't know what these are, but doesn't sound like they uniquely
identify the original frame.
> * The 0x8 EtherType
> * A partial (24-bit or 32-bit) RX timestamp
> * Two bytes from the initial (pre follow-up) frame's DMAC, before the
> switch mangled those with the source port and switch id. The driver is
> supposed to patch these bytes from the follow-up back into the initial
> frame before passing them up the stack.
> * The source port that generated the meta frame
> * The switch id that generated the meta frame
None of these match to the original frame uniquely. Looks like this
is a dead end.
I recommend forgetting about these meta frames. Instead, read out the
time stamps over MDIO.
Thanks,
Richard
Powered by blists - more mailing lists