[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230517121925.518473aa@kernel.org>
Date: Wed, 17 May 2023 12:19:25 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, Andrew Lunn
<andrew@...n.ch>, Köry Maincent
<kory.maincent@...tlin.com>, netdev@...r.kernel.org, glipus@...il.com,
maxime.chevallier@...tlin.com, vadim.fedorenko@...ux.dev,
richardcochran@...il.com, gerhard@...leder-embedded.com,
thomas.petazzoni@...tlin.com, krzysztof.kozlowski+dt@...aro.org,
robh+dt@...nel.org
Subject: Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping
layers to user space.
On Fri, 12 May 2023 10:38:52 -0700 Jakub Kicinski wrote:
> On Fri, 12 May 2023 13:29:11 +0300 Vladimir Oltean wrote:
> > On Thu, May 11, 2023 at 04:16:25PM -0700, Jakub Kicinski wrote:
> > > Oh, you should tell me, maybe off-list then. 'Cause I don't know any.
> >
> > I hope the examples given in private will make you reconsider the
> > validity of my argument about DMA timestamps.
>
> I may have lost track of what the argument is. There are devices
> which will provide a DMA stamp for Tx and Rx. We need an API that'll
> inform the user about it.
>
> To be clear I'm talking about drivers which are already in the tree,
> not opening the door for some shoddy new HW in.
It dawned on me while reading a phylink discussion that I may have
misunderstood the meaning of the MAC vs PHY time stamp sources.
By the standard - stamping happens under the MAC, so MAC is
the "right" place to stamp, not the PHY. And there can be multiple
PHYs technically? Are we just using the MAC vs PHY thing as an
implementation aid, to know which driver to send the request to?
Shouldn't we use the clock ID instead?
Powered by blists - more mailing lists