[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MN2PR11MB466499CCAF0540D25A5DF7689B5C2@MN2PR11MB4664.namprd11.prod.outlook.com>
Date: Thu, 7 Nov 2024 09:14:06 +0000
From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>, "Kitszel, Przemyslaw"
<przemyslaw.kitszel@...el.com>, "davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org"
<kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
"richardcochran@...il.com" <richardcochran@...il.com>, "Loktionov, Aleksandr"
<aleksandr.loktionov@...el.com>
Subject: RE: [Intel-wired-lan] [PATCH net-next v3 1/2] ptp: add control over
HW timestamp latch point
>From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of
>Andrew Lunn
>Sent: Wednesday, November 6, 2024 6:45 PM
>
>On Wed, Nov 06, 2024 at 02:07:55AM +0100, Arkadiusz Kubalewski wrote:
>> Currently HW support of ptp/timesync solutions in network PHY chips can
>>be
>> implemented with two different approaches, the timestamp maybe latched
>> either at the beginning or after the Start of Frame Delimiter (SFD) [1].
>>
>> Allow ptp device drivers to provide user with control over the HW
>> timestamp latch point with ptp sysfs ABI. Provide a new file under sysfs
>> ptp device (/sys/class/ptp/ptp<N>/ts_point). The file is available for
>>the
>> user, if the device driver implements at least one of newly provided
>> callbacks. If the file is not provided the user shall find a PHY
>>timestamp
>> latch point within the HW vendor specification.
>>
>> The file is designed for root user/group access only, as the read for
>> regular user could impact performance of the ptp device.
>>
>> Usage, examples:
>>
>> ** Obtain current state:
>> $ cat /sys/class/ptp/ptp<N>/ts_point
>> Command returns enum/integer:
>> * 1 - timestamp latched by PHY at the beginning of SFD,
>> * 2 - timestamp latched by PHY after the SFD,
>> * None - callback returns error to the user.
>
>-EOPNOTSUPP would be more conventional, not None.
>
Sure, I can change it if new version is needed (Kuba's other thread on this)
>>
>> ** Configure timestamp latch point at the beginning of SFD:
>> $ echo 1 > /sys/class/ptp/ptp<N>/ts_point
>>
>> ** Configure timestamp latch point after the SFD:
>> $ echo 2 > /sys/class/ptp/ptp<N>/ts_point
>
>and i assume these also return -EOPNOTSUPP if it is not supported.
>
>And a dumb question, why should i care where the latch point is? Why
>would i want to change it? Richard always says that you cannot trust
>the kernel to have the same latency from kernel to kernel version
>because driver developers like to tweak the latency, invalidating all
>measurements the user has done when setting up their ptp4l
>daemon. This just seems like yet another way to break my ptp4l
>configuration.
>
> Andrew
Well, making control knob available to the users.
The explanation/rationale/problem statement is available under provided
Link, and patch allows part of IEEE 802_3cx standard to be controlled.
Thank you!
Arkadiusz
Powered by blists - more mailing lists