Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Fri, 24 Nov 2023 21:57:09 +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: <20231124195709.wkhplnhtpxf75a6n@skbuf>
References: <20231121094354.635ee8cd@kernel.org>
 <20231122144453.5eb0382f@kmaincent-XPS-13-7390>
 <20231122140850.li2mvf6tpo3f2fhh@skbuf>
 <20231122085000.79f2d14c@kernel.org>
 <20231122165517.5cqqfor3zjqgyoow@skbuf>
 <20231122100142.338a2092@kernel.org>
 <20231123160056.070f3311@kmaincent-XPS-13-7390>
 <20231123093205.484356fc@kernel.org>
 <20231124154343.sr3ajyueoshke6tn@skbuf>
 <20231124183431.5d4cc189@kmaincent-XPS-13-7390>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231124183431.5d4cc189@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?Wkex0m7PZrPvpo9BsQOLIu1skeNmEhc3f4MKsCbWCBYNpTpP57jJXeWaf6?=
 =?iso-8859-1?Q?ZoddXENoFZ48JqrcNXuG1lDai1cgpeE+VoCZ1jF6VhZBBbHngr26bM3fRD?=
 =?iso-8859-1?Q?DLztvjgBD5Vgz+L9yLLo5HeHfL3MH1EYTBKph0tjo+8c5K6rKoKCR7tgaK?=
 =?iso-8859-1?Q?dktwNjX15GL1rlipSxfZyxZiFfT/Pl20hwH1hztJFsVLPdI8nWzX3HqYUN?=
 =?iso-8859-1?Q?NRFoUnRcvDYW4/U/GFaLidJ6RrkmoIqgfa9OphkEIoKsUbJv3MgVSytr6V?=
 =?iso-8859-1?Q?rzJBXW1i4Mkcf4qL9OI8AsQX4W/e8bybVx85U7O/KqyYcQdHguqtwnxsts?=
 =?iso-8859-1?Q?Pgzf44417R5p5R527GGWcndtk1ZfwugTVI0THQ0VhQMTXnKl/y+otWqXSP?=
 =?iso-8859-1?Q?SzwiviYNbJHv4+GqUItJdoj+8lqmmKqOqdSNkCYn3g2sJX6eY0YjeG/RuB?=
 =?iso-8859-1?Q?Ii39cGhGEgJslVVVr2cFIKI4jST1X1Uv+5sawp/TnGvbFoym0y2LYIpMbP?=
 =?iso-8859-1?Q?gYQ92q82P5pqT73VfbT2OzW14aDd3U3itQCQESbyy8nKypbVUD/WZBMaxm?=
 =?iso-8859-1?Q?SP5+EEkEMvW3Xp/a7LAX2p9NOb6wa7QiKG7ePKJ+p7xbr+D1Lyo6fqKxEC?=
 =?iso-8859-1?Q?NIrQ7d20WwsVjATCZRumIownakcD9D92Gt8WdDc6LAzuRZYNk/MMwZoyw0?=
 =?iso-8859-1?Q?biBGSDa9CtdxhVRp4q2tRk70a/D5FaEFuZtgccaI1OVKBk5ck1kV4nNlBV?=
 =?iso-8859-1?Q?cIs/D9MzgT6II6pRswPLPrlM1CLzlr46hyEhPvYfl6pAHgeaJuJpCkNHm3?=
 =?iso-8859-1?Q?5niPVaASOXPeXBPSLJXoNmhIIMDTldmC0D6bKT6w9GJ6K/QkU/zoR79m4l?=
 =?iso-8859-1?Q?cOqTL1Pbu1XuhaSYUcS2jpBJWRbOTpS2x01L0i0Ts63kwczQKwgKs2PxAz?=
 =?iso-8859-1?Q?VaDqQcSIVcBhNDJpzOeXGZYjR5anZq5JsxjlML3i7fQaSlu0Xrr24NQZ7K?=
 =?iso-8859-1?Q?8ZMIR/FVdWPHvtUW0ZLxa2YTaAGIvpq9NYSF40ZCi1HzO6XZ93o2+GCP3P?=
 =?iso-8859-1?Q?o0iKbm6oXxQ2janPrjPjXOb0Y8bTh4iUZDs+oL3rhOADjoV1XVRuX3NRlN?=
 =?iso-8859-1?Q?EYKEu3dE+bSptGQ9y/QfY6yBC7MZv3Y0j1CzqZU0IYIcDlFgSsrFWiQDoB?=
 =?iso-8859-1?Q?nzPTJo5yBld2IpsW6AaRJY0RkV6UnD7nu4oXhEj7l4g7ZE5U/tWTA430wj?=
 =?iso-8859-1?Q?V9Y3VRqyWA5oTtkAzOTyv2MZqhUXyUcvkAGcYJiyDaIL2PiVD0+ZxysdrL?=
 =?iso-8859-1?Q?54wM/lL2VSKFu6B0znny7XP3kMsnB8IZgK+Si8xeLQ6KhhztCmwzVngFHC?=
 =?iso-8859-1?Q?fmJbgAV84XL58TbTP1jJjB+6xw5L2cEsulY43fkzhdm6Dfwyxpy80VvD30?=
 =?iso-8859-1?Q?/f+nyTbG3MG2wXBZe1sETa1bNWhGadkwD+Ggzy0s8Chn7ODOJLC1o8b/mp?=
 =?iso-8859-1?Q?KD7dyb9L4C0LrJ26QwEFaxFSXJrC6S8v+P+4+ZkjvF6nR5Y6GmcJSFizKV?=
 =?iso-8859-1?Q?QiKR2oxNGyMUz4xYhpox52Qad7Od6SMYmdebmQDcH7VXKDiBTXkEmc01y0?=
 =?iso-8859-1?Q?GbUkskPSPy1zSiftkjvBxyEDLAbhOPh4SEtcGxGWgfUgKJ6+OEqyoQ7g?=
 =?iso-8859-1?Q?=3D=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a694f66-bbcb-411e-4f43-08dbed278d61
X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB6452.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2023 19:57:13.6645
 (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: ayoa6SdvlfIKCmwLjtsccc4kKyiOb9YIWOMozEfIo8JB1L8n2odpqNwOYvzM1Ewlumfrtp6l52SjZ5a14w9cgA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR04MB7841
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]); Fri, 24 Nov 2023 11:57:43 -0800 (PST)

On Fri, Nov 24, 2023 at 06:34:31PM +0100, K?ry Maincent wrote:
> Would it break things if both ioctls and netlink can get and set the
> hwtstamps configuration?

Uhm, obviously? It would break things if ioctl and netlink were _not_
freely interchangeable, and you couldn't see in a ioctl GET what got set
through a netlink SET.

> It is only configuration. Both happen under rtnl_lock it should be
> alright.

Yeah, but you always need to keep the API interchangeability in mind
during the implementation.

> The question is which hwtstamp provider will the original ioctls be able to
> change? Maybe the default one (MAC with phy whitelist) and only this one.

TL;DR: yeah.

Remember one single rule and go from there: new development should not
change established setups. So SIOCSHWSTAMPs should continue to behave
"as before".

This is also the exact reason why I asked for the phy whitelist. The
introduction of CONFIG_NETWORK_PHY_TIMESTAMPING introduced exactly that:
a breaking change in the mode in which deployed setups operate.

> > But by all means, still hold a poll if you want to. I would vote for
> > ethtool netlink, not because it's great, just because I don't have a
> > better alternative to propose.
> 
> If you agree on that choice, let's go. Jakub and your are the most proactive
> reviewers in this patch series. Willem you are the timestamping maintainer do
> you also agree on this? 
> If anyone have another proposition let them speak now, or forever remain
> silent! ;)

Hmm, proactive means doing stuff in anticipation of being requested to
do it. I'd use the work "active" at most...