From patchwork Thu Dec 7 21:12:40 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Halaney X-Patchwork-Id: 175381 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp5066789vqy; Thu, 7 Dec 2023 13:13:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IGN95afRSHytRLWNqu5dANr1C08XJnh/UUd2GU2qaLIF8b+vC4INvG8lJMQNmG+4qJzMLNi X-Received: by 2002:a17:903:244e:b0:1d0:d007:98d with SMTP id l14-20020a170903244e00b001d0d007098dmr3516211pls.53.1701983581868; Thu, 07 Dec 2023 13:13:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701983581; cv=none; d=google.com; s=arc-20160816; b=Kc8dOh5sGeNem7ZLzWNbdNRS2KR4QZE/PaMX9wUKsPqkK4CU0Q5FKlL34J670YfWu4 eWuOLkaKjVMW4N7iIG4JtrUDZyj06riMdaIio1mO/BTU+gXxE9weGKsCNgen+7MjUMcF wuHDedp+cA9GmqUj2kIyp83a3kfho7FWYXliogAvMYNz8TT6IpBjtvyaokJHh+wyi0PF wxei1UX+a5dEIOs8UUsBuA37CPtacugsT6WSoYnvYP9ftnaCLIlASJvnNSueTBYuqbQ8 /dU4dwqsDJF+Ri/f+/uO8V2jL/R+RJ10YhIs8NFnPi30K2SoVt8u32fXchy74QldJ6EJ a97g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=m0tm0lsXPlnCiFdUXwz3yeCYNRe8/nR8iqlVxg/Ese8=; fh=e95a1bHSUArKqofcKNnyWBwvTbSBrVSg/GSgZFoUaZg=; b=xmWjttO3ipO/wxN0wfS5gUZAv68+mzBGWZCfB3ABd/KP3NTpatgJVTDsIhPKuO8X+7 fi0Ndq2nImilztmFdCVgNBaNw5/C5Si1QOPvKblhG/1kSE/eTCRJSOGfkaaOre5i5C+W HOTs9QvpxOms1C3VOBiqIP2Tmv/vz972D7lQenvqlqq16sOkT9sOp8+sv0J0vNk5nA3J bOdpWOLchv92N2wIIz5FGSNL9LcL4Mkn199NkRBW2OKJODXLZ6Ji5d8AZD/oNzYWEAQv clc+JaMHKXZNDXzgAzAs5xxu754uYB4Sk4ZYvsSHj33Of8RtZdQ8+gIBszwahTqpzyYj bGrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Qn2NIJp2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id u9-20020a170902e80900b001d091c3ab04si353057plg.355.2023.12.07.13.13.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Dec 2023 13:13:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Qn2NIJp2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id D98CA801BCC8; Thu, 7 Dec 2023 13:12:56 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1443925AbjLGVMr (ORCPT + 99 others); Thu, 7 Dec 2023 16:12:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231473AbjLGVMp (ORCPT ); Thu, 7 Dec 2023 16:12:45 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE2D61718 for ; Thu, 7 Dec 2023 13:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701983569; 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; bh=m0tm0lsXPlnCiFdUXwz3yeCYNRe8/nR8iqlVxg/Ese8=; b=Qn2NIJp27vDfEPZ9jPXoaU+8GMHtp5ke+sU/M0M7XiwB+x+Rh73y6RtqejnR/qtDJOlzgJ DU926hlL4Xvl9qhSJkW6u+qL14TEbwAlxCjH7UmHoEQxH85QfTcGbO1eoxycXoKiCvjrsH c76lswIQoNZMn8ncQgInw4Dlh6PcxAU= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-271-suJRT1mgMMKXJQ9jeDC7hg-1; Thu, 07 Dec 2023 16:12:48 -0500 X-MC-Unique: suJRT1mgMMKXJQ9jeDC7hg-1 Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-77efc1b094aso131153285a.1 for ; Thu, 07 Dec 2023 13:12:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701983568; x=1702588368; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m0tm0lsXPlnCiFdUXwz3yeCYNRe8/nR8iqlVxg/Ese8=; b=I1iKGskmYpIgu+medM/MqmkXKTiNGy5VN1zZR65uDy+/bG9IqMdFO7LqLunesWhlUH Yw+6U5orxyo/6+RmtofTSp9DlTeCxxBZRwojs+sBZm71wwrSdHbPhS6+ctaeqeSWiGYl UirN6j263qiRsq9XeJIcLb494e8qzqclwZZG18A0xHhLzVUoLPW7R3+sfqDsuex5HIY8 tqHyvPvpUXWbRyoDD8E4fkSzDie8TsMr8a6nFI98giVVKjd3USChjjE8Z9/3B6kXPq8l wkt/UirfCBklXcJZf/r5gSqz60Pv5w/ohR9MytTdUCT5guuMGTGQilc9RqRAZ/TAzpia T9Wg== X-Gm-Message-State: AOJu0YzxqPIZmhYqa6oIeFv8vvgooH+NtJ2RL2PpoAUvmWqZAG3126aN /Jw3Q50xPWXSSnLBlHvfn5j4SmqOOEaojDTg59dIURiu69+xBquA1tYSsd0hbNPuwGZj0DbFZUA 9p2s1b7VlnxKxZr7Zxq6YTOo1 X-Received: by 2002:a05:620a:12d9:b0:77e:fba3:8206 with SMTP id e25-20020a05620a12d900b0077efba38206mr1847333qkl.156.1701983567819; Thu, 07 Dec 2023 13:12:47 -0800 (PST) X-Received: by 2002:a05:620a:12d9:b0:77e:fba3:8206 with SMTP id e25-20020a05620a12d900b0077efba38206mr1847324qkl.156.1701983567552; Thu, 07 Dec 2023 13:12:47 -0800 (PST) Received: from [192.168.1.164] ([2600:1700:1ff0:d0e0::47]) by smtp.gmail.com with ESMTPSA id rb3-20020a05620a8d0300b00774350813ccsm180707qkn.118.2023.12.07.13.12.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Dec 2023 13:12:47 -0800 (PST) From: Andrew Halaney Date: Thu, 07 Dec 2023 15:12:40 -0600 Subject: [PATCH net-next v3] net: stmmac: don't create a MDIO bus if unnecessary MIME-Version: 1.0 Message-Id: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com> X-B4-Tracking: v=1; b=H4sIAEc1cmUC/22OQQ6DIBBFr2Jm3TEC1WpXvUfjAmGqJAUMENLGe PdSF1119f/PZF7eBpGCoQjXaoNA2UTjXRniVIFapJsJjS4beMMFY/yCMVkrFTqPVhtfUhMyPQ1 a9pK3eoDyuQZ6mNdBvYOjhI5eCcZyeQRvMS2B5I/a9E3PSmnPNWNdK5DhFObnbZo15Xp9foGLi cmH92GZ+YE9hHjT/RXKvFCEEErSeZiYkrdAepGpVt7CuO/7BxyLB074AAAA To: Alexandre Torgue , Jose Abreu , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Bartosz Golaszewski , Andrew Halaney X-Mailer: b4 0.12.3 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 07 Dec 2023 13:12:57 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784659136495870048 X-GMAIL-MSGID: 1784659136495870048 The stmmac_dt_phy() function, which parses the devicetree node of the MAC and ultimately causes MDIO bus allocation, misinterprets what fixed-link means in relation to the MAC's MDIO bus. This results in a MDIO bus being created in situations it need not be. Currently a MDIO bus is created if the description is either: 1. Not fixed-link 2. fixed-link but contains a MDIO bus as well The "1" case above isn't always accurate. If there's a phy-handle, it could be referencing a phy on another MDIO controller's bus[1]. In this case currently the MAC will make a MDIO bus and scan it all anyways unnecessarily. There's also a lot of upstream devicetrees[2] that expect a MDIO bus to be created and scanned for a phy. This case can also be inferred from the platform description by not having a phy-handle && not being fixed-link. This hits case "1" in the current driver's logic. Let's improve the logic to create a MDIO bus if either: - Devicetree contains a MDIO bus - !fixed-link && !phy-handle (legacy handling) Below upstream devicetree snippets can be found that explain some of the cases above more concretely. Here's[0] a devicetree example where the MAC is both fixed-link and driving a switch on MDIO (case "2" above). This needs a MDIO bus to be created: &fec1 { phy-mode = "rmii"; fixed-link { speed = <100>; full-duplex; }; mdio1: mdio { switch0: switch0@0 { compatible = "marvell,mv88e6190"; pinctrl-0 = <&pinctrl_gpio_switch0>; }; }; }; Here's[1] an example where there is no MDIO bus or fixed-link for the ethernet1 MAC, so no MDIO bus should be created since ethernet0 is the MDIO master for ethernet1's phy: ðernet0 { phy-mode = "sgmii"; phy-handle = <&sgmii_phy0>; mdio { compatible = "snps,dwmac-mdio"; sgmii_phy0: phy@8 { compatible = "ethernet-phy-id0141.0dd4"; reg = <0x8>; device_type = "ethernet-phy"; }; sgmii_phy1: phy@a { compatible = "ethernet-phy-id0141.0dd4"; reg = <0xa>; device_type = "ethernet-phy"; }; }; }; ðernet1 { phy-mode = "sgmii"; phy-handle = <&sgmii_phy1>; }; Finally there's descriptions like this[2] which don't describe the MDIO bus but expect it to be created and the whole address space scanned for a phy since there's no phy-handle or fixed-link described: &gmac { phy-supply = <&vcc_lan>; phy-mode = "rmii"; snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>; snps,reset-active-low; snps,reset-delays-us = <0 10000 1000000>; }; [0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts [1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts [2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164 Co-developed-by: Bartosz Golaszewski Signed-off-by: Bartosz Golaszewski Signed-off-by: Andrew Halaney Reviewed-by: Serge Semin --- Changes in v3: - Keep logic out of stmmac_probe_config_dt() since it's already massive (Serge) Changes in v2: - Handle the fixed-link + mdio case (Andrew Lunn) - Reworded commit message - Still handle the "legacy" case mentioned in the commit - Bit further refactoring of the function for readability - Link to v2: https://lore.kernel.org/r/20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com - Link to v1: https://lore.kernel.org/netdev/20230808120254.11653-1-brgl@bgdev.pl/ --- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 91 +++++++++++++--------- 1 file changed, 54 insertions(+), 37 deletions(-) --- base-commit: fd8a79b63710acb84321be3ce74be23c876873fb change-id: 20231127-stmmac-no-mdio-node-1db9da8a25d9 Best regards, diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index 1ffde555da47..d6079c1432c7 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -296,62 +296,80 @@ static int stmmac_mtl_setup(struct platform_device *pdev, } /** - * stmmac_dt_phy - parse device-tree driver parameters to allocate PHY resources - * @plat: driver data platform structure - * @np: device tree node - * @dev: device pointer - * Description: - * The mdio bus will be allocated in case of a phy transceiver is on board; - * it will be NULL if the fixed-link is configured. - * If there is the "snps,dwmac-mdio" sub-node the mdio will be allocated - * in any case (for DSA, mdio must be registered even if fixed-link). - * The table below sums the supported configurations: - * ------------------------------- - * snps,phy-addr | Y - * ------------------------------- - * phy-handle | Y - * ------------------------------- - * fixed-link | N - * ------------------------------- - * snps,dwmac-mdio | - * even if | Y - * fixed-link | - * ------------------------------- + * stmmac_of_get_mdio() - Gets the MDIO bus from the devicetree. + * @np: devicetree node * - * It returns 0 in case of success otherwise -ENODEV. + * The MDIO bus will be searched for in the following ways: + * 1. The compatible is "snps,dwc-qos-ethernet-4.10" && a "mdio" named + * child node exists + * 2. A child node with the "snps,dwmac-mdio" compatible is present + * + * Return: The MDIO node if present otherwise NULL */ -static int stmmac_dt_phy(struct plat_stmmacenet_data *plat, - struct device_node *np, struct device *dev) +static struct device_node *stmmac_of_get_mdio(struct device_node *np) { - bool mdio = !of_phy_is_fixed_link(np); static const struct of_device_id need_mdio_ids[] = { { .compatible = "snps,dwc-qos-ethernet-4.10" }, {}, }; + struct device_node *mdio_node = NULL; if (of_match_node(need_mdio_ids, np)) { - plat->mdio_node = of_get_child_by_name(np, "mdio"); + mdio_node = of_get_child_by_name(np, "mdio"); } else { /** * If snps,dwmac-mdio is passed from DT, always register * the MDIO */ - for_each_child_of_node(np, plat->mdio_node) { - if (of_device_is_compatible(plat->mdio_node, + for_each_child_of_node(np, mdio_node) { + if (of_device_is_compatible(mdio_node, "snps,dwmac-mdio")) break; } } - if (plat->mdio_node) { + return mdio_node; +} + +/** + * stmmac_mdio_setup() - Populate platform related MDIO structures. + * @plat: driver data platform structure + * @np: devicetree node + * @dev: device pointer + * + * This searches for MDIO information from the devicetree. + * If an MDIO node is found, it's assigned to plat->mdio_node and + * plat->mdio_bus_data is allocated. + * If no connection can be determined, just plat->mdio_bus_data is allocated + * to indicate a bus should be created and scanned for a phy. + * If it's determined there's no MDIO bus needed, both are left NULL. + * + * This expects that plat->phy_node has already been searched for. + * + * Return: 0 on success, errno otherwise. + */ +static int stmmac_mdio_setup(struct plat_stmmacenet_data *plat, + struct device_node *np, struct device *dev) +{ + bool legacy_mdio; + + plat->mdio_node = stmmac_of_get_mdio(np); + if (plat->mdio_node) dev_dbg(dev, "Found MDIO subnode\n"); - mdio = true; - } - if (mdio) { - plat->mdio_bus_data = - devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data), - GFP_KERNEL); + /* Legacy devicetrees allowed for no MDIO bus description and expect + * the bus to be scanned for devices. If there's no phy or fixed-link + * described assume this is the case since there must be something + * connected to the MAC. + */ + legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node; + if (legacy_mdio) + dev_info(dev, "Deprecated MDIO bus assumption used\n"); + + if (plat->mdio_node || legacy_mdio) { + plat->mdio_bus_data = devm_kzalloc(dev, + sizeof(struct stmmac_mdio_bus_data), + GFP_KERNEL); if (!plat->mdio_bus_data) return -ENOMEM; @@ -471,8 +489,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac) if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0) dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n"); - /* To Configure PHY by using all device-tree supported properties */ - rc = stmmac_dt_phy(plat, np, &pdev->dev); + rc = stmmac_mdio_setup(plat, np, &pdev->dev); if (rc) return ERR_PTR(rc);