From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39D0320897F; Tue, 18 Mar 2025 13:59:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742306395; cv=none; b=uOdcAwZd60mbJHBycA6+IGNWvuNuSJ3PggFlJaDsEpbZ8UBzamurgjUwvXvlERn9yaZwc/rllLFuw4hPlwOvI67SaxCiUNe+Dtuk7Z2EGZoCj2PTt5pT52f5nFzMgpKoedalUbnbrGLnDJdw5vBSrn4gaXELTc7UNfmkZw1Vhrc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742306395; c=relaxed/simple; bh=Nv2oYFqOTXkVlqdbynct8r7DC63L/Bx+7ExDdZB11tg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ig8sePlnm44y0m58cfaqjmJjUDsRZ4T0603MUA0z+B+uAEWC0h41YzlbuFPEl7wib0kjcUiF1oVOiqJlqnq7h2KjxXRwXYslAyQrM/rzRrCkcugEkam0iBC+eEIjCkJa4E+UN9F0OU0hk9AlEWmAM5r6kYMjwGxZKEHDwwi/5P0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=naGNJt06; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="naGNJt06" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E44DBC4CEDD; Tue, 18 Mar 2025 13:59:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742306394; bh=Nv2oYFqOTXkVlqdbynct8r7DC63L/Bx+7ExDdZB11tg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=naGNJt06PGOqLdmvK6CJLnXQQGra4v3zUyPdAMjdASTjH9LhOD/KcGXowGj4LRBYS GlAd9jp7Qm2ATN4M302/B8W3nHCeik1NuSBKL4fSo7v8kLKmao16NcIvnOhUZ6hlFY qwmuZ48m1tziCFmIcohVeyxCVj/bv+cw60jsIjPoGD8apdYItTT3V955BY1/4XrC9F yhmbn5ieYteFZYmyU4+4EmsHn5/jyBBIOt0S9qwUOCAkoCiETVcic221WB5PMk1BJ1 /fNJLkGBim13YkoJb4DfgWHN1YmSIq/QEyMm5C586dLnOW/747Y+xv16rbdIB0+B7i OKVCLHismJZ3A== Date: Tue, 18 Mar 2025 13:59:47 +0000 From: Simon Horman To: Jacob Keller Cc: Tony Nguyen , Przemek Kitszel , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Richard Cochran , Ruud Bos , Paul Barker , Niklas =?utf-8?Q?S=C3=B6derlund?= , Bryan Whitehead , UNGLinuxDriver@microchip.com, Raju Lakkaraju , Florian Fainelli , Broadcom internal kernel review list , Andrew Lunn , Heiner Kallweit , Russell King , Jonathan Lemon , Lasse Johnsen , Vadim Fedorenko , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Yoshihiro Shimoda Subject: Re: [PATCH net 2/5] renesas: reject PTP_STRICT_FLAGS as unsupported Message-ID: <20250318135947.GR688833@kernel.org> References: <20250310-jk-net-fixes-supported-extts-flags-v1-0-854ffb5f3a96@intel.com> <20250310-jk-net-fixes-supported-extts-flags-v1-2-854ffb5f3a96@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250310-jk-net-fixes-supported-extts-flags-v1-2-854ffb5f3a96@intel.com> + Shimoda-san On Mon, Mar 10, 2025 at 03:16:37PM -0700, Jacob Keller wrote: > The ravb_ptp_extts() function checks the flags coming from the > PTP_EXTTS_REQUEST ioctl, to ensure that future flags are not accepted on > accident. > > This was updated to 'honor' the PTP_STRICT_FLAGS in commit 6138e687c7b6 > ("ptp: Introduce strict checking of external time stamp options."). > However, the driver does not *actually* validate the flags. > > I originally fixed this driver to reject future flags in commit > 592025a03b34 ("renesas: reject unsupported external timestamp flags"). It > is still unclear whether this hardware timestamps the rising, falling, or > both edges of the input signal. > > Accepting requests with PTP_STRICT_FLAGS is a bug, as this could lead to > users mistakenly assuming a request with PTP_RISING_EDGE actually > timestamps the rising edge only. > > Reject requests with PTP_STRICT_FLAGS (and hence all PTP_EXTTS_REQUEST2 > requests) until someone with access to the datasheet or hardware knowledge > can confirm the timestamping behavior and update this driver. > > Fixes: 6138e687c7b6 ("ptp: Introduce strict checking of external time stamp options.") > Signed-off-by: Jacob Keller Adding Shimoda-san who may be able to help coordinate a review if Niklas and Paul are unavailable for some reason. > --- > drivers/net/ethernet/renesas/ravb_ptp.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/renesas/ravb_ptp.c b/drivers/net/ethernet/renesas/ravb_ptp.c > index 6e4ef7af27bf31ab2aad8e06a65e0ede6046e3c0..b4365906669f3bd40953813e263aeaafd2e1eb70 100644 > --- a/drivers/net/ethernet/renesas/ravb_ptp.c > +++ b/drivers/net/ethernet/renesas/ravb_ptp.c > @@ -179,8 +179,7 @@ static int ravb_ptp_extts(struct ptp_clock_info *ptp, > /* Reject requests with unsupported flags */ > if (req->flags & ~(PTP_ENABLE_FEATURE | > PTP_RISING_EDGE | > - PTP_FALLING_EDGE | > - PTP_STRICT_FLAGS)) > + PTP_FALLING_EDGE)) > return -EOPNOTSUPP; > > if (req->index) > > -- > 2.48.1.397.gec9d649cc640 > >