netdev - Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping layers to user space.

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]

Date: Fri, 19 May 2023 14:50:42 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: Richard Cochran <richardcochran@...il.com>,
	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 Thu, May 18, 2023 at 04:23:10PM -0700, Jacob Keller wrote:
> 
> 
> On 5/17/2023 3:46 PM, Richard Cochran wrote:
> > 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 agree. I've wanted us to enable phylib/phylink/something for our
> internal PHYs, but never got traction here to actually make it happen.
> There was a push a few years ago for using it in igb, but ultimately
> couldn't get enough support to make the development happen :( Similar
> with using the i2c interfaces... These days, so much of the control
> happens only in firmware that it has its own challenges.

I know there is some cleanup going on reducing replicated code in
Intel Ethernet drivers. I was wondering if that would extend to
PHYs. But as you say, recent Intel hardware have firmware controlling
the PHYs, not Linux. So such cleanups would be limited to older
controllers which i guess Intel probably no longer cares about.

> > I've long thought that having NETWORK_PHY_TIMESTAMPING limited to
> > PHYLIB (and in practice device tree) systems is unfortunate.
> > 
> 
> It is a bit unfortunate. In the ice driver case, we just report the
> timestamps in the usual way for a network driver, which is ok enough
> since no other timestamps exist for us.

I would actually say there is nothing fundamentally blocking using
NETWORK_PHY_TIMESTAMPING with something other than DT. It just needs
somebody to lead the way.

For ACPI in the scope of networking, everybody just seems to accept DT
won, and stuffs DT properties into ACPI tables. For PCI devices, there
has been some good work being done by Trustnetic using software nodes,
for gluing together GPIO controllers, I2C controller, SFP and
PHYLINK. It should be possible to do the same with PHY timestampers.

	 Andrew