RE: [PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point

Kubalewski, Arkadiusz posted 2 patches 3 weeks, 5 days ago
Only 0 patches received!
RE: [PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point
Posted by Kubalewski, Arkadiusz 3 weeks, 5 days ago
>From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
>Sent: Tuesday, October 29, 2024 12:30 PM
>
>On 28/10/2024 20:47, Arkadiusz Kubalewski wrote:
>> HW support of PTP/timesync solutions in network PHY chips can be
>> achieved with two different approaches, the timestamp maybe latched
>> either in the beginning or after the Start of Frame Delimiter (SFD) [1].
>>
>> Allow ptp device drivers to provide user with control over the timestamp
>> latch point.
>>
>> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
>
>I just wonder should we add ethtool interface to control this feature.
>As we are adding it for phy devices, it's good idea to have a way to
>control it through eth device too. WDYT?

Seems doable, I guess somehow expand the controllability being added right
now with this series:
https://lore.kernel.org/netdev/20241023-feature_ptp_netnext-v18-0-ed948f3b6887@bootlin.com/#r
Or some other idea?


Re: [PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point
Posted by Vadim Fedorenko 3 weeks, 5 days ago
On 29/10/2024 15:56, Kubalewski, Arkadiusz wrote:
>> From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
>> Sent: Tuesday, October 29, 2024 12:30 PM
>>
>> On 28/10/2024 20:47, Arkadiusz Kubalewski wrote:
>>> HW support of PTP/timesync solutions in network PHY chips can be
>>> achieved with two different approaches, the timestamp maybe latched
>>> either in the beginning or after the Start of Frame Delimiter (SFD) [1].
>>>
>>> Allow ptp device drivers to provide user with control over the timestamp
>>> latch point.
>>>
>>> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
>>
>> I just wonder should we add ethtool interface to control this feature.
>> As we are adding it for phy devices, it's good idea to have a way to
>> control it through eth device too. WDYT?
> 
> Seems doable, I guess somehow expand the controllability being added right
> now with this series:
> https://lore.kernel.org/netdev/20241023-feature_ptp_netnext-v18-0-ed948f3b6887@bootlin.com/#r
> Or some other idea?

Yeah, the series mentioned correlates with your work, that's why I asked 
about it.
It would be great to be sure that the interface you are proposing can be
reused or somehow combined with the series.
RE: [Intel-wired-lan] [PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point
Posted by Kubalewski, Arkadiusz 2 weeks, 5 days ago
>From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
>Vadim Fedorenko
>Sent: Tuesday, October 29, 2024 5:17 PM
>
>On 29/10/2024 15:56, Kubalewski, Arkadiusz wrote:
>>> From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
>>> Sent: Tuesday, October 29, 2024 12:30 PM
>>>
>>> On 28/10/2024 20:47, Arkadiusz Kubalewski wrote:
>>>> HW support of PTP/timesync solutions in network PHY chips can be
>>>> achieved with two different approaches, the timestamp maybe latched
>>>> either in the beginning or after the Start of Frame Delimiter (SFD)
>>>>[1].
>>>>
>>>> Allow ptp device drivers to provide user with control over the
>>>> timestamp latch point.
>>>>
>>>> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
>>>
>>> I just wonder should we add ethtool interface to control this feature.
>>> As we are adding it for phy devices, it's good idea to have a way to
>>> control it through eth device too. WDYT?
>>
>> Seems doable, I guess somehow expand the controllability being added
>> right now with this series:
>> https://lore.kernel.org/netdev/20241023-feature_ptp_netnext-v18-0-ed94
>> 8f3b6887@bootlin.com/#r
>> Or some other idea?
>
>Yeah, the series mentioned correlates with your work, that's why I asked
>about it.
>It would be great to be sure that the interface you are proposing can be
>reused or somehow combined with the series.

Sure, I did some modifications to allow this extension in the future, as
this is still being developed.

Thank you!
Arkadiusz