From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (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 6DF74A38 for ; Tue, 5 Sep 2023 11:00:37 +0000 (UTC) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::227]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45C7B12A; Tue, 5 Sep 2023 04:00:35 -0700 (PDT) Received: by mail.gandi.net (Postfix) with ESMTPSA id DC1F22000E; Tue, 5 Sep 2023 11:00:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arinc9.com; s=gm1; t=1693911633; 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=vYzf4PHEoghXFdMmCHAIIQGECn1QD3BWvIxyh4qMpVg=; b=b4qq1/Q1XTOsh7nK+KHIVbBxbzwl/avkrWEXgKOU2B+Pj2K6R2wBhChiSGk4Zu6IuZM9QG JCkh12kBuPNaYmUpT+Auid5rRkeOQZIJWiOGxBeuI4uoU6BARODxPVO3OT2dFqeQohREd9 2LoT+xQwnHIyxXD//Skg6vsAXfBsChtx+E1yd2x9EN4X14piSf8DElXn19XSXTMoSIC4S7 7DaQqiu/W03BQK8ZqYHsYbZ+uXdcK7+sjJbuEuAc9sNu62H96AGoUDMYHHiECZ6FVFGjIP HarvB3RK0ZrrkTB5/8oQ5V2y6C56O44zgBf/2JCfP+E8RdfZwaFYtaPjAoVv9w== Message-ID: <03d3341b-be77-4b25-bec2-fcae91a549d3@arinc9.com> Date: Tue, 5 Sep 2023 14:00:21 +0300 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] dt-bindings: net: dsa: document internal MDIO bus To: Luiz Angelo Daros de Luca Cc: Vladimir Oltean , Andrew Lunn , Florian Fainelli , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Woojung Huh , UNGLinuxDriver@microchip.com, Linus Walleij , =?UTF-8?Q?Alvin_=C5=A0ipraga?= , Daniel Golle , Landen Chao , DENG Qingfang , Sean Wang , Matthias Brugger , AngeloGioacchino Del Regno , 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 References: <20230812091708.34665-3-arinc.unal@arinc9.com> <47b61929-5c2d-4906-b153-2046a94858c8@arinc9.com> <20230813112026.ohsx6srbt2staxma@skbuf> <8a8e14f1-0493-4298-a2cc-6e7ae7929334@arinc9.com> <20230813190157.4y3zoro53qsz43pe@skbuf> <20230814143601.mnpxtcm2zybnbvoh@skbuf> <0cee0928-74c9-4048-8cd8-70bfbfafd9b2@arinc9.com> <20230827121235.zog4c3ehu2cyd3jy@skbuf> <676d1a2b-6ffa-4aff-8bed-a749c373f5b3@arinc9.com> Content-Language: en-US From: =?UTF-8?B?QXLEsW7DpyDDnE5BTA==?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-GND-Sasl: arinc.unal@arinc9.com X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On 5.09.2023 05:42, Luiz Angelo Daros de Luca wrote: >>> [1] ...this. The SMI-controlled and MDIO-controlled Realtek switches are >>> otherwise the same, right? So why would they have different dt-bindings? >> >> Honestly, I'm wondering the answer to this as well. For some reason, when >> probing the SMI controlled Realtek switches, instead of just letting >> dsa_switch_setup() populate ds->slave_mii_bus, on realtek_smi_setup_mdio() >> on realtek-smi.c: >> >> - priv->slave_mii_bus is allocated. >> - mdio_np = of_get_compatible_child(priv->dev->of_node, "realtek,smi-mdio"); >> - priv->slave_mii_bus->dev.of_node = mdio_np; >> - ds->slave_mii_bus = priv->slave_mii_bus; > > I might be able to help here. The Realtek SMI version created a custom > slave_mii driver because it was the only way to associate it with an > MDIO DT node. And that DT node was required to specify the interrupts > for each phy0. > It would work without that mdio node, letting DSA setup handle the > slave bus, but it would rely only on polling for port status. > > As we only have a single internal MDIO, the compatible string > "realtek,smi-mdio" would not be necessary if the driver checks for a > "mdio"-named child node. Maybe the code was just inspired by another > DSA driver that uses more MDIO buses or external ones. The "mdio" name > is suggested by docs since it was committed > (https://www.kernel.org/doc/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt). > That name was also kept in the YAML translation > (https://www.kernel.org/doc/Documentation/devicetree/bindings/net/dsa/realtek.yaml). > > The Realtek MDIO driver was merged at the same release that included > the change that allows dsa_switch_setup() to reference the "mdio" > OF-node if present. That way, it could avoid creating a custom > slave_mii_bus driver. > > I submitted a small series of patches to unify that behavior between > those two drivers: > > https://lore.kernel.org/netdev/CAJq09z44SNGFkCi_BCpQ+3DuXhKfGVsMubRYE7AezJsGGOboVA@mail.gmail.com/ > (This is my answer to the series opening message to include the first > paragraph ate by the editor) > > There was some discussion but not NAC, ACK or RFC. It would have > dropped some lines of code. I can revive it if there is interest. I'd like this to happen, thanks Luiz! Arınç