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
>>
>> On Wed, Mar 11, 2026 at 12:42:10PM +0000, Korba, Przemyslaw wrote:
>>>> -----Original Message-----
>>>> From: Simon Horman <[email protected]>
>>>> Sent: Tuesday, March 10, 2026 7:25 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
>>>>
>>>> + Jacob
>>>>
>>>> On Mon, Mar 09, 2026 at 03:11:51PM +0100, Przemyslaw Korba wrote:
>>>>> Since upstream commit d9f3e9ecc456 ("net: ptp: introduce
>>>>> .supported_perout_flags to ptp_clock_info") and commit 7c571ac57d9d ("net:
>>>>> ptp: introduce .supported_extts_flags to ptp_clock_info"), kernel core
>>>>> now requires that the driver set the .supported_perout_flags and
>>>>> .supported_extts_flags fields in PTP clock info. Otherwise, the
>>>>> additional flags will be rejected by the kernel automatically.
>>>>>
>>>>> i40e does not support perout flags, so reject any request with perout
>>>>> flags.
>>>>>
>>>>> Signed-off-by: Przemyslaw Korba <[email protected]>
>>>>> ---
>>>>>  drivers/net/ethernet/intel/i40e/i40e_ptp.c | 12 +++++++++++-
>>>>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ptp.c
>>>>> b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
>>>>> index 7bcea7d9720f..8d7958692235 100644
>>>>> --- a/drivers/net/ethernet/intel/i40e/i40e_ptp.c
>>>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
>>>>> @@ -601,10 +601,18 @@ static int i40e_ptp_feature_enable(struct 
>>>>> ptp_clock_info *ptp,
>>>>>   /* TODO: Implement flags handling for EXTTS and PEROUT */
>>>>>   switch (rq->type) {
>>>>>   case PTP_CLK_REQ_EXTTS:
>>>>> +         if (rq->extts.flags & ~(PTP_ENABLE_FEATURE |
>>>>> +                                 PTP_RISING_EDGE |
>>>>> +                                 PTP_FALLING_EDGE |
>>>>> +                                 PTP_STRICT_FLAGS))
>>>>> +                 return -EOPNOTSUPP;
>>>>> +
>>>>>           func = PTP_PF_EXTTS;
>>>>>           chan = rq->extts.index;
>>>>>           break;
>>>>>   case PTP_CLK_REQ_PEROUT:
>>>>> +         if (rq->perout.flags)
>>>>> +                 return -EOPNOTSUPP;
>>>>>           func = PTP_PF_PEROUT;
>>>>>           chan = rq->perout.index;
>>>>>           break;
>>>>
>>>> I am a little confused.
>>>>
>>>> My understanding of the cited patches is that they add checking of flags 
>>>> to the code. So code like the above isn't needed in drivers.
>>>
>>> Hi Simon, thank you very much for the review. My understanding is that the 
>>> driver needs to set the supported flags field, otherwise requests
>> won't go through kernel. The test I've been doing confirm my theory. Here's 
>> also example patch, that adds supported flags to drivers:
>> https://lore.kernel.org/intel-wired-lan/[email protected]/
>>
>> Sorry for the slow response.
>>
>> My understanding is that the hunk above is not required.
>> But the hunk below is.
>>
> 
> Well, you are very correct. Thank you so much for thorough review and let me 
> send a new version!
> 
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

Reply via email to