Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Mon, 20 Nov 2023 18:10:04 +0200
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     =?utf-8?B?S8O2cnk=?= Maincent <kory.maincent@bootlin.com>
Cc:     Jakub Kicinski <kuba@kernel.org>,
        Florian Fainelli <florian.fainelli@broadcom.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@broadcom.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>,
        Richard Cochran <richardcochran@gmail.com>,
        Radu Pirea <radu-nicolae.pirea@oss.nxp.com>,
        Jay Vosburgh <j.vosburgh@gmail.com>,
        Andy Gospodarek <andy@greyhouse.net>,
        Nicolas Ferre <nicolas.ferre@microchip.com>,
        Claudiu Beznea <claudiu.beznea@tuxon.dev>,
        Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Horatiu Vultur <horatiu.vultur@microchip.com>,
        UNGLinuxDriver@microchip.com, Simon Horman <horms@kernel.org>,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-doc@vger.kernel.org,
        Maxime Chevallier <maxime.chevallier@bootlin.com>
Subject: Re: [PATCH net-next v7 15/16] net: ethtool: ts: Let the active time
 stamping layer be selectable
Message-ID: <20231120161004.flnwqv5dousiltcb@skbuf>
References: <20231114-feature_ptp_netnext-v7-0-472e77951e40@bootlin.com>
 <20231114-feature_ptp_netnext-v7-15-472e77951e40@bootlin.com>
 <20231118183433.30ca1d1a@kernel.org>
 <20231120104439.15bfdd09@kmaincent-XPS-13-7390>
 <20231120105255.cgbart5amkg4efaz@skbuf>
 <20231120121440.3274d44c@kmaincent-XPS-13-7390>
 <20231120120601.ondrhbkqpnaozl2q@skbuf>
 <20231120144929.3375317e@kmaincent-XPS-13-7390>
 <20231120142316.d2emoaqeej2pg4s3@skbuf>
 <20231120155344.14cd69d9@kmaincent-XPS-13-7390>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231120155344.14cd69d9@kmaincent-XPS-13-7390>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?WPRKjIDtSTa3tibpN43T8+NsLHy1Y7TEsVDzvdq5B35Btw+3pzhDTlTLCV?=
 =?iso-8859-1?Q?FsyV7JBgYrA6WoIugqD18Zn8Ax4uYp2pBcTBxHcYcBP8NYO57FtbbCLog1?=
 =?iso-8859-1?Q?GVjN1IfLSKkBQX/YN2Ky8kbTU7OWF1qqKgEC5q7bztvPz85rLczwSkI56+?=
 =?iso-8859-1?Q?O0e6B6y5rFo5gvePxmK9on8b2QuOaNXRByavDpHcqpoJN3Yhpudee+U8o2?=
 =?iso-8859-1?Q?CyyC1UwCm+9tdWvfTsXK8giftu/cCxP5FU3di936ASMrdJHjuPBADRLLe7?=
 =?iso-8859-1?Q?TnVjKk2hx4Cyud3F1jGosYyDcTEv2Wd6nx9s0dJP0tRl9K1WCtNGzLDIiQ?=
 =?iso-8859-1?Q?UPXKhYjJirzRYTButwXYesKK3fevPg+GbsVMT+uabKU5b3DBgGtqgM6hVH?=
 =?iso-8859-1?Q?f3/P//5RI+AQAAzEeBoe4udF9kgZrag50xzqRTOdbXjckatIP2ML3Zlqvr?=
 =?iso-8859-1?Q?NPMKaW7Kkn2L13z5rVqo7Q0qqE0NJPtAVoDPAORZU4MJ511K4gfIye7PfI?=
 =?iso-8859-1?Q?Y/VHCpD+dk2YRXJ4ggqdSj11uXWEJ23LjwaL+FHsCGgtN3lHz+MkdM7CBr?=
 =?iso-8859-1?Q?hJGUFCeDp6+boUpKmAW2aJx6ci92IUprZxh4JrsDRMzN/ragSeTEARJu+T?=
 =?iso-8859-1?Q?JzHPHRp5O6UDHuEQfjOI/Bj08/qRqRTOjh5eEhFBJ7IEDC/rq7f2ov4Cof?=
 =?iso-8859-1?Q?2EmNlAztxF99AHu+tDcwzl8TS4MqnimL6eiieyADQ/LRPvxsoWIPgvjqIz?=
 =?iso-8859-1?Q?vNIs6lhyDmIhYg4ce2zpWvUj4JQQVKMuH4ufHkKu/4DEosEqG/grJIx4CB?=
 =?iso-8859-1?Q?RIzi5vlEcs3j3Pzjk6JPvcJNVDWSQ/7YOqlZo7F3pZqRGbeAIhACgiGJag?=
 =?iso-8859-1?Q?R1bLIwumbIlDcBZmPktgl7Ypqq4vwwvmgn/Z7pggR4EjLnoJDnt+Jm9OGa?=
 =?iso-8859-1?Q?5GWdXAJko6YdZ1wY4BvELZJJxuJF1ncMiYC4sr7OD1qdlIZqULMPjpA4Cw?=
 =?iso-8859-1?Q?lYHTkyXKfvxZA3UKsMYw6YB1rDkVDmTSDjuXRAY+0S1PPNpgFT2hHbfXbq?=
 =?iso-8859-1?Q?41hwI+bcaL2+uzfn5vPdFpk0NKXVQ5hgSWe/pHb8hfbCkkz5i9wjb7CGoQ?=
 =?iso-8859-1?Q?8jsonPehZQzLKe6UvyEleCS0/NlqvH4QbMiSFfR1rCg7s/q3weE+Nd4Hmx?=
 =?iso-8859-1?Q?mlWiBmA6JsjMvQEe/u15hreI68BOB3nYNSK90FRwaztBQ7YFt7gTq7cSEJ?=
 =?iso-8859-1?Q?5/zUEWul0TDqcI4LZfroGKjztZ9o8N8nMgpjavhkwA9MEBY3pK9GoW+EJy?=
 =?iso-8859-1?Q?gD8Ee5jKU2jdSwdyU4rbhMMGkcaPpRh0O861Zi/oxw6KUSGb7SfxC8Hd+b?=
 =?iso-8859-1?Q?IbAxDc6IfrS2kb9SqJhljpGaTSZ2Ww7K20kM7ZoQ6s35F2Q5wNuBArwj0j?=
 =?iso-8859-1?Q?Df+43lyk4HpvroB/77OdlRqr0SvjiOTnSYxIsRJ7faLto0gRuPUI3jfi9u?=
 =?iso-8859-1?Q?CGU7DpI8ib0GXY5ergpNQ5BI110rnPeCod87HzpFg1e/4p/+JlIxRFutUf?=
 =?iso-8859-1?Q?roudeO0SNTNc5uxDYHAVpjVCMf1NKhlw6Dm2UGVWeuEovY1KyH0UNLKiaw?=
 =?iso-8859-1?Q?RwbYljBxXgOP2fYpA29QyuIak/XHXzjN8eYQ+vwx3L1UNEdhPT6604dA?=
 =?iso-8859-1?Q?=3D=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 082236be-0cfa-4d70-3354-08dbe9e32aa2
X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB6452.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2023 16:10:08.7036
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vhg6ftKptbYLI9OM0Jsyqb0FsRXOJ2z4VvwsHXMvsAMgWm4mxxl6gvx1wKiuXb3VIDtYyodLVgMxRIi79gsG8w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR04MB9867
X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Mon, 20 Nov 2023 08:10:28 -0800 (PST)

On Mon, Nov 20, 2023 at 03:53:44PM +0100, K?ry Maincent wrote:
> I did thought about it but I got stuck by the case of hardware timestamping
> without PHC. Richard explained the reason of its existence here:
> https://lore.kernel.org/netdev/ZS3MKWlnPqTe8gkq@hoboy.vegasvil.org/#t
> 
> Maybe I got a bit stuck in my implementation and should investigate more your
> proposition and how to deal with this case. Do you have an idea on how to
> solve it?

I would take what Richard said with a grain of salt, and interpret as
"there exists hardware with hwts but w/o PHC, and that may work for
marginal use cases", not that "we should design having that as a
first-class citizen in mind".

If there is any need for me to point out that such kind of driver isn't
a first class citizen, then here's an experiment:

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
index e993ed04ab57..5755f54197b9 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
@@ -842,13 +842,7 @@ static int enetc_get_ts_info(struct net_device *ndev,
 {
 	int *phc_idx;
 	
-	phc_idx = symbol_get(enetc_phc_index);
-	if (phc_idx) {
-		info->phc_index = *phc_idx;
-		symbol_put(enetc_phc_index);
-	} else {
-		info->phc_index = -1;
-	}
+	info->phc_index = -1;
 
 #ifdef CONFIG_FSL_ENETC_PTP_CLOCK
 	info->so_timestamping = SOF_TIMESTAMPING_TX_HARDWARE |

When elected as master, it kinda works, and does synchronize with a
slave, even if ptp4l gets confused about the phc_index being -1.

But when elected as a slave by the BMCA, ptp4l gets confused and thinks
that phc_index == -1 means that it's supposed to use software timestamping.

$ ptp4l -i eno0 -2 -P -m -s
ptp4l[1185.594]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1185.598]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1186.887]: port 1: new foreign master 00049f.fffe.05f628-1
ptp4l[1190.889]: selected best master clock 00049f.fffe.05f628
ptp4l[1190.890]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1191.891]: master offset 37000003850 s0 freq +100000000 path delay       823
ptp4l[1192.896]: master offset 3[ 1235.693485] systemd-journald[125]: Time jumped backwards, rotating.
7000003848 s1 freq +99999998 path delay       822
ptp4l[1193.603]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[1193.892]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[1193.893]: master offset 37000003852 s0 freq +99999998 path delay       822
ptp4l[1194.342]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[1194.604]: clockcheck: clock jumped forward or running faster than expected!

So, I guess the only thing we need to do to this kind of setup is not do
too much harm to it.

We break nothing if we make the phc_index the central aspect of hwts
layer selection - except for the fact that such a MAC won't be able to
change its timestamping layer to be a PHY.

If we wanted to add such a capability to that MAC driver, the obvious
way to solve the lack of a PHC is to create a PHC that returns
-EOPNOTSUPP for all of its ptp_clock_info operations (gettime, settime
etc). It may possibly be that, in the worst case, ptp4l needs to probe
for each syscall on the NIC's PHC being operational before deciding what
can be done with it. But that's already an improvement over the current
handling to make it more graceful, it's not to keep things on par.

> > Hmm, can you please explain what is the reason why software timestamping
> > can't coexist with PHY timestamping? It is a genuine question to which I
> > don't have an answer - I haven't used PHY timestamping. It must be
> > something specific to that, since I do know that MAC + software
> > timestamping work simultaneously just fine.
> 
> The software timestamp is managed through the MAC driver calling
> skb_tx_timestamp() function. The PHY driver does not call it, that's why there
> is no software timestamping in PHY driver capabilities. Also the PHY driver
> doesn't know if the MAC driver support it so it currently can not coexist with
> PHY timestamping.

I don't understand. Documentation/networking/timestamping.rst says that
skb_tx_timestamp() is one of the actual _mechanisms_ through which phylib
timestamping works. It's called by the parent MAC driver, and
mii_ts->txtstamp() hooks onto that. So in some situations, the PHY
timestamping core _piggybacks_ on top of software timestamping support
in the MAC.

Where I agree is that the PHY driver has no business in deciding whether
the interface should report the socket option flags for software timestamping
or not. But I still don't see a proof that they can't coexist. What you need
to explain is what makes said software timestamping unusable in the
presence of PHY timestamping - to justify this separate software
timestamping layer in your UAPI proposal.