> -----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 > >> > >> 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
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?
