On 4/10/2026 6:20 AM, Korba, Przemyslaw wrote:
>> -----Original Message-----
>> From: Keller, Jacob E <[email protected]>
>> Sent: Thursday, March 26, 2026 1:15 AM
>> To: Korba, Przemyslaw <[email protected]>; Simon Horman
>> <[email protected]>
>> Cc: [email protected]; [email protected]; Nguyen,
>> Anthony L <[email protected]>; Kitszel, Przemyslaw
>> <[email protected]>
>> Subject: Re: [PATCH iwl-next] i40e: PTP: set supported flags in
>> ptp_clock_info
>>
>> On 3/13/2026 6:47 AM, Korba, Przemyslaw wrote:
>>>> -----Original Message-----
>>>> From: Simon Horman <[email protected]>
>>>> Sent: Friday, March 13, 2026 2:35 PM
>>>> To: Korba, Przemyslaw <[email protected]>
>>>> Cc: [email protected]; [email protected]; Nguyen,
>>>> Anthony L <[email protected]>; Kitszel, Przemyslaw
>>>> <[email protected]>; Keller, Jacob E <[email protected]>
>>>> Subject: Re: [PATCH iwl-next] i40e: PTP: set supported flags in
>>>> ptp_clock_info
>> Yes, Simon is correct, but we do have to be certain that the driver
>> actually implements the facts correctly, i.e. that it will actually
>> honor the RISING or FALLING edge, before you actually add the flags to
>> the supported flags list.
>>
>> I don't see any mention of PTP_RISING_EDGE nor PTP_FALLING_EDGE in the
>> driver. Thus, I can't confirm which edge is actually timestamped.
>>
>> Thus I would NACK this patch until you can confirm whether the hardware
>> either a) timestamps one edge, in which case you should set only that
>> flag as allowed, b) timestamps both edges, in which case you should set
>> all flags and then explicitly reject the case where only one flag is
>> set, or c) can be configured based on which flag is set, in which case
>> you should set all the flags and then check the flags when programming
>> to enable the appropriate edge.
>>
>> This patch does none of these, and is therefor incorrect. Applying it
>> will "allow" the userspace to work but they will not get the strict
>> behavior of timestamping the desired edge, which completely negates the
>> point of the strict mode!
>>
>> As an example, look at the ice driver:
>>
>> #define GLTSYN_AUX_IN_0_EVNTLVL_RISING_EDGE BIT(0)
>> #define GLTSYN_AUX_IN_0_EVNTLVL_FALLING_EDGE BIT(1)
>>
>> /* set event level to requested edge */
>> if (rq->flags & PTP_FALLING_EDGE)
>> aux_reg |= GLTSYN_AUX_IN_0_EVNTLVL_FALLING_EDGE;
>> if (rq->flags & PTP_RISING_EDGE)
>> aux_reg |= GLTSYN_AUX_IN_0_EVNTLVL_RISING_EDGE;
>>
>>
>> It sets the appropriate register values to ensure the correct edges are
>> timestamped as requested.
>>
>> Thanks,
>> Jake
>
> Hi, thank you for your review, and sorry for late response.
> The original point of this patch was to fix the issue, where ts2phc fails due
> to not seeing supported flags
> (now when I think about it iwl-net would be a better place for this patch)
> I've read in our documentation FVL supports both rising, falling and both
> edges,
> but in i40e_ptp_set_timestamp_mode we are hardcoding EVNTLVL register to
> Rising edge only.
> Implementing other edges would require DCR, and I couldn't find anything like
> that.
> I think for now setting the rising edge as a supported flag would be the way
> to go. Do you agree?
Agreed. I would propose the following path to resolving this:
a) as a net fix, set the flag to match what the driver actually enables.
If this is Rising edge only, then set the rising edge and strict flag.
Strictly, this is a bug introduced by commit 1050713026a0 ("i40e: add
support for PTP external synchronization clock"), because this commit
added support for EXTTS output without checking the flags, but.. the
original issue was being too accepting, while the new issue is being
caused by silently excluding the flags because the flags aren't listed
as supported. Thus, use Fixes: 7c571ac57d9d ("net: ptp: introduce
.supported_extts_flags to ptp_clock_info")
Since you confirmed that the driver explicitly sets rising edge support,
you should set STRICT_FLAGS and RISING_EDGE in the
.supported_extts_flags field.
b) as a net-next improvement, add support for both flags and
conditionally set the register to program the desired edge. This might
take longer if we need to go through internal approval for a new
feature, but in my opinion this is small and obviously correct and
something we should support within the PTP ecosystem. Since the window
will be closing soon this part should wait until after it re-opens in 2
weeks.
