From: Jacob Keller <jacob.e.keller@intel.com>
To: "Korba, Przemyslaw" <przemyslaw.korba@intel.com>,
Simon Horman <horms@kernel.org>
Cc: "intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
"Kitszel, Przemyslaw" <przemyslaw.kitszel@intel.com>
Subject: Re: [PATCH iwl-next] i40e: PTP: set supported flags in ptp_clock_info
Date: Wed, 25 Mar 2026 17:15:24 -0700 [thread overview]
Message-ID: <dce634db-bd85-4c39-ae01-4272c432f017@intel.com> (raw)
In-Reply-To: <PH0PR11MB490443FB49C3F762297A992E9445A@PH0PR11MB4904.namprd11.prod.outlook.com>
On 3/13/2026 6:47 AM, Korba, Przemyslaw wrote:
>> -----Original Message-----
>> From: Simon Horman <horms@kernel.org>
>> Sent: Friday, March 13, 2026 2:35 PM
>> To: Korba, Przemyslaw <przemyslaw.korba@intel.com>
>> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
>> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>
>> 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 <horms@kernel.org>
>>>> Sent: Tuesday, March 10, 2026 7:25 PM
>>>> To: Korba, Przemyslaw <przemyslaw.korba@intel.com>
>>>> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
>>>> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>
>>>> 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 <przemyslaw.korba@intel.com>
>>>>> ---
>>>>> 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/20250414-jk-supported-perout-flags-v2-1-f6b17d15475c@intel.com/
>>
>> 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
next prev parent reply other threads:[~2026-03-26 0:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 14:11 [PATCH iwl-next] i40e: PTP: set supported flags in ptp_clock_info Przemyslaw Korba
2026-03-09 16:34 ` [Intel-wired-lan] " Paul Menzel
2026-03-11 12:42 ` Korba, Przemyslaw
2026-03-10 18:24 ` Simon Horman
2026-03-11 12:42 ` Korba, Przemyslaw
2026-03-13 13:34 ` Simon Horman
2026-03-13 13:47 ` Korba, Przemyslaw
2026-03-26 0:15 ` Jacob Keller [this message]
2026-03-11 8:01 ` [Intel-wired-lan] " Dawid Osuchowski
2026-03-11 12:45 ` Korba, Przemyslaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dce634db-bd85-4c39-ae01-4272c432f017@intel.com \
--to=jacob.e.keller@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=przemyslaw.korba@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox