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: Thu, 18 May 2023 16:23:10 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Richard Cochran <richardcochran@...il.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 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'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.

> Thanks,
> Richard