[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZGVZXTEn+qnMyNgV@hoboy.vegasvil.org>
Date: Wed, 17 May 2023 15:46:53 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
Köry Maincent <kory.maincent@...tlin.com>,
netdev@...r.kernel.org, glipus@...il.com,
maxime.chevallier@...tlin.com, vladimir.oltean@....com,
vadim.fedorenko@...ux.dev, gerhard@...leder-embedded.com,
thomas.petazzoni@...tlin.com, krzysztof.kozlowski+dt@...aro.org,
robh+dt@...nel.org, linux@...linux.org.uk
Subject: Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping
layers to user space.
On Wed, May 17, 2023 at 03:13:06PM -0700, Jacob Keller wrote:
> For example, ice hardware captures timestamp data in its internal PHY
> well after the MAC layer finishes, but it doesn't expose the PHY to the
> host at all..
>
> From a timing perspective it matters that its PHY, but from an
> implementation perspective there's not much difference since we don't
> support MAC timestamping at all (and the PHY isn't accessible through
> phylink...)
Here is a crazy idea: Wouldn't it be nice to have all PHYs represented
in the kernel driver world, even those PHYs that are built in?
I've long thought that having NETWORK_PHY_TIMESTAMPING limited to
PHYLIB (and in practice device tree) systems is unfortunate.
Thanks,
Richard
Powered by blists - more mailing lists