From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28A33E7D0AA for ; Thu, 21 Sep 2023 20:58:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231954AbjIUU6D (ORCPT ); Thu, 21 Sep 2023 16:58:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232273AbjIUU5h (ORCPT ); Thu, 21 Sep 2023 16:57:37 -0400 Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 490A8880B5; Thu, 21 Sep 2023 10:38:50 -0700 (PDT) Received: from relay9-d.mail.gandi.net (unknown [IPv6:2001:4b98:dc4:8::229]) by mslow1.mail.gandi.net (Postfix) with ESMTP id EAB5BC0A2F; Thu, 21 Sep 2023 11:38:53 +0000 (UTC) Received: by mail.gandi.net (Postfix) with ESMTPSA id 18E4AFF809; Thu, 21 Sep 2023 11:38:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arinc9.com; s=gm1; t=1695296310; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Jg1KwFh5lSvkfLStS1akS234BD88W219/y2jE+qO6JQ=; b=FB+WZwNSKjLpXhOD9eu3aYO9S6xv7RKPVKfQqt6Yyak4R0XVc2bs16R2Ke/+V/3txgPjPr wNyBzW42Tn7VAFs2jhEpLj1G9U6dnj08SGVZCzFzU+kN0/r6dBMoRCU2I1O3Q8xtwIolig xJ1YEEOth0NiXYYwOeMIAC90CHeyPQYQTN1YQTfV6AKvrznfMYMqllejuEeIHK1xAQoq7D B2wVQWekSUN/HVPKuTr+U8nV6amDRMGb5hUj07YiP5dfthswJzspcJcvSs0Fc397s1bG45 3KvHozxpJJGdRulhdH2AcaicpASeaoEDTfZJ6ynuWsTayDIRxLyeQVsxkaRHLg== Message-ID: <16710cf9-8911-4fed-8e2d-b19b581446c1@arinc9.com> Date: Thu, 21 Sep 2023 14:38:09 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2 07/10] dt-bindings: net: enforce phylink bindings on certain ethernet controllers To: Rob Herring Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Krzysztof Kozlowski , Conor Dooley , George McCollister , Andrew Lunn , Florian Fainelli , Vladimir Oltean , Kurt Kanzenbach , Matthias Brugger , AngeloGioacchino Del Regno , Woojung Huh , UNGLinuxDriver@microchip.com, Linus Walleij , =?UTF-8?Q?Alvin_=C5=A0ipraga?= , =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= , Marcin Wojtas , "Russell King (Oracle)" , Lars Povlsen , Steen Hegelund , Daniel Machon , Radhey Shyam Pandey , Daniel Golle , Landen Chao , DENG Qingfang , Sean Wang , Geert Uytterhoeven , Magnus Damm , Maxime Chevallier , Nicolas Ferre , Claudiu Beznea , Marek Vasut , Claudiu Manoil , Alexandre Belloni , John Crispin , Madalin Bucur , Ioana Ciornei , Lorenzo Bianconi , Felix Fietkau , Horatiu Vultur , Oleksij Rempel , Alexandre Torgue , Giuseppe Cavallaro , Jose Abreu , Grygorii Strashko , Sekhar Nori , Shyam Pandey , mithat.guner@xeront.com, erkin.bozoglu@xeront.com, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-renesas-soc@vger.kernel.org References: <20230916110902.234273-1-arinc.unal@arinc9.com> <20230916110902.234273-8-arinc.unal@arinc9.com> <20230918181319.GA1445647-robh@kernel.org> Content-Language: en-US From: =?UTF-8?B?QXLEsW7DpyDDnE5BTA==?= In-Reply-To: <20230918181319.GA1445647-robh@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-GND-Sasl: arinc.unal@arinc9.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18.09.2023 21:13, Rob Herring wrote: > On Sat, Sep 16, 2023 at 02:08:59PM +0300, Arınç ÜNAL wrote: >> Phylink bindings are required for ethernet controllers that utilise >> phylink_fwnode_phy_connect() directly or through phylink_of_phy_connect(), >> and register OF-based only MDIO buses, if they register any. > > What is phylink? > > Don't describe/justify binding changes based on some Linux functions. I'd like to discuss the influence of the Linux drivers on the devicetree bindings. Before that let me clarify these "phylink" bindings. They are certain rules to properly describe the link of the ethernet controller. Any of the phy-handle, pcs-handle, sfp, and fixed-link properties describe the link. They are already defined on ethernet-controller.yaml, just not enforced. Why I called them phylink bindings, is because when phylink is used on the ethernet controller driver, only then we can be sure that the link descriptions on the ethernet controller are needed. Because, some drivers don't need the link descriptions on the ethernet controller as they can search a certain MDIO bus to find and connect a MAC to a PHY or set up a fixed link without looking at the devicetree. I don't like this approach because, as you said, devicetree bindings should describe the hardware, not driver policies. So I propose that we don't let Linux drivers interfere with dt-bindings. To that extent: - Link descriptions must be required on ethernet controllers. We don't care whether some Linux driver can or cannot find the PHY or set up a fixed link without looking at the devicetree. - The MDIO bus description on an ethernet controller describes that the hardware comes with an MDIO bus. The MDIO property is optional not because some Linux driver can find and map the PHYs to MACs without DT descriptions but because the hardware doesn't have to use that or any MDIO bus. Let's also talk about the elephant in the room: DSA bindings. Distributed Switch Architecture is a Linux subsystem, not a hardware property. Devicetree bindings are supposed to describe the hardware, yet we have bindings specifically for DSA so that the DSA driver can properly control the hardware. Although I see dsa.yaml and dsa-port.yaml mostly consist of describing an ethernet switch with CPU port(s), there're properties that are specific to DSA, such as dsa,member on dsa.yaml and dsa-tag-protocol and label on dsa-port.yaml. Depending on how I get responses, I will address my patches. Then I can further discuss the DSA bindings. Arınç