[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MW3PR11MB4666D202C42B699FAF31DF3F9B532@MW3PR11MB4666.namprd11.prod.outlook.com>
Date: Wed, 6 Nov 2024 01:15:48 +0000
From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
To: "Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>
CC: "Nguyen, Anthony L" <anthony.l.nguyen@...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>, "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>
Subject: RE: [PATCH net-next v2 1/2] ptp: add control over HW timestamp latch
point
>From: Kitszel, Przemyslaw <przemyslaw.kitszel@...el.com>
>Sent: Tuesday, October 29, 2024 9:25 AM
>Subject: Re: [PATCH net-next v2 1/2] ptp: add control over HW timestamp
>latch point
>
>On 10/28/24 21:47, 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:
>> * 0 - timestamp latched by PHY at the beginning of SFD,
>> * 1 - timestamp latched by PHY after the SFD,
>> * None - callback returns error to the user.
>>
>> ** Configure timestamp latch point at the beginning of SFD:
>> $ echo 0 > /sys/class/ptp/ptp<N>/ts_point
>>
>> ** Configure timestamp latch point after the SFD:
>> $ echo 1 > /sys/class/ptp/ptp<N>/ts_point
>>
>> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
>>
>> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@...el.com>
>> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>
>
>[...]
>
>> diff --git a/include/linux/ptp_clock_kernel.h
>> b/include/linux/ptp_clock_kernel.h
>> index c892d22ce0a7..ea1bcca7f7f6 100644
>> --- a/include/linux/ptp_clock_kernel.h
>> +++ b/include/linux/ptp_clock_kernel.h
>> @@ -55,6 +55,24 @@ struct ptp_system_timestamp {
>> clockid_t clockid;
>> };
>>
>> +/**
>> + * enum ptp_ts_point - possible timestamp latch points (IEEE 802.3cx)
>> + *
>> + * @PTP_TS_POINT_SFD: timestamp latched at the beginning of sending
>Start
>> + * of Frame Delimiter (SFD)
>> + * @PTP_TS_POINT_POST_SFD: timestamp latched after the end of sending
>Start
>> + * of Frame Delimiter (SFD)
>> + */
>> +enum ptp_ts_point {
>> + PTP_TS_POINT_SFD,
>> + PTP_TS_POINT_POST_SFD,
>> +
>> + /* private: */
>> + __PTP_TS_POINT_MAX
>> +};
>> +
>> +#define PTP_TS_POINT_MAX (__PTP_TS_POINT_MAX - 1)
>
>I would move PTP_TS_POINT_MAX into the enum
>
Fixed in v3.
Thank you!
Arkadiusz
Powered by blists - more mailing lists