linux-kernel - Re: [PATCH net v2 0/3] net: phy: micrel: Remove latencies support lan8814

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, 1 Apr 2022 16:11:20 +0200
From:   "Allan W. Nielsen" <allan.nielsen@...rochip.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Horatiu Vultur <horatiu.vultur@...rochip.com>,
        <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <hkallweit1@...il.com>,
        <linux@...linux.org.uk>, <Divya.Koppera@...rochip.com>,
        <davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
        <richardcochran@...il.com>, <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH net v2 0/3] net: phy: micrel: Remove latencies support
 lan8814

On 01.04.2022 14:57, Andrew Lunn wrote:
>On Fri, Apr 01, 2022 at 01:05:19PM +0200, Horatiu Vultur wrote:
>> Remove the latencies support both from the PHY driver and from the DT.
>> The IP already has some default latencies values which can be used to get
>> decent results. It has the following values(defined in ns):
>> rx-1000mbit: 429
>> tx-1000mbit: 201
>> rx-100mbit:  2346
>> tx-100mbit:  705
>
>So one alternative option here is that ptp4l looks at
>
>/sys/class/net/<ifname>/phydev/phy_id
>
>to identify the PHY, listens to netlink messages to determine the link
>speed and then applies the correction itself in user space. That gives
>you a pretty generic solution, works for any existing PHY and pretty
>much any existing kernel version.  And if you want board specific
>values you can override them in the ptp4l configuration file.
I think it is good to have both options. If you want PTP4L to compensate
in user-space, do not call the tunable, if you want to HW to compensate,
call the tunable (this is useful both for users using ptp4l and other
ptpimplementations).

If system behaves strange, it is easy to see what delays has been
applied.

We are planning on creating a small proejct, which go through all PHYs
in the current system. It shall check a config file to see if the user
has configured interface specific numbers, then apply them, other wise
see if we have default numbers based on the PHY-ID (like you describe).

Idea is to run this at boot as a one-off. It will apply the adjustments
on all speeds, all capable PHYs regardless of they PHY-Timestamping is
used or not.

BTW: If there is a desire, we can add a flag to this tool which can set
all the delay-values to zero.

Just for the record: It is not that I do not like PTP4L - it is by far
the best PTP implementation I have seen. But I'm keen on having a
solution that also works for non-ptp4l users.

/Allan