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 X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C178BC9DD4D for ; Tue, 27 Oct 2020 15:43:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7BA8E22400 for ; Tue, 27 Oct 2020 15:43:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603813435; bh=h1sxDJNUepvYbFjEi5Du29K2v2j9/kl7MSSz+3Hms+g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=fcDQ2T60voFAMhoAAOPkcDm68s3mNcD1VXH/yHkKuBwMvbOYjllhJKCjfC97u1ux3 oKr4pLJvSkJsF9QGZl1cFThZjM9WIF7X1LwISf8yfiOTZt1+KsV8VM2pQnXTAoe6bf wsvJxiF+H3qCC0TBGI9TMNJGFUZtgs+rBzarCLJI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1795676AbgJ0PPS (ORCPT ); Tue, 27 Oct 2020 11:15:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:47850 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1794445AbgJ0PLx (ORCPT ); Tue, 27 Oct 2020 11:11:53 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9E35021D24; Tue, 27 Oct 2020 15:11:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603811512; bh=h1sxDJNUepvYbFjEi5Du29K2v2j9/kl7MSSz+3Hms+g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nZ4/TQSPqr6yW43SYdF/+fttAUpYeBh0NhiCe2I7vxQz2UzRtLWbOYPV8oShesPJV HtbAvVp+C3KfJEeVxACJdSx5Or0+nNyopF6oMdOlnV8EdBZfYx/uLkKMXufDzZt4Zs Iz/jzEio9FxeJLVMksPP07OGVnfngisjP7AQvztk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ard Biesheuvel , Ilias Apalodimas , Andrew Lunn , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.8 478/633] netsec: ignore phy-mode device property on ACPI systems Date: Tue, 27 Oct 2020 14:53:41 +0100 Message-Id: <20201027135545.163310625@linuxfoundation.org> X-Mailer: git-send-email 2.29.1 In-Reply-To: <20201027135522.655719020@linuxfoundation.org> References: <20201027135522.655719020@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ard Biesheuvel [ Upstream commit acd7aaf51b20263a7e62d2a26569988c63bdd3d8 ] Since commit bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the Realtek PHY driver will override any TX/RX delay set by hardware straps if the phy-mode device property does not match. This is causing problems on SynQuacer based platforms (the only SoC that incorporates the netsec hardware), since many were built with this Realtek PHY, and shipped with firmware that defines the phy-mode as 'rgmii', even though the PHY is configured for TX and RX delay using pull-ups. >>From the driver's perspective, we should not make any assumptions in the general case that the PHY hardware does not require any initial configuration. However, the situation is slightly different for ACPI boot, since it implies rich firmware with AML abstractions to handle hardware details that are not exposed to the OS. So in the ACPI case, it is reasonable to assume that the PHY comes up in the right mode, regardless of whether the mode is set by straps, by boot time firmware or by AML executed by the ACPI interpreter. So let's ignore the 'phy-mode' device property when probing the netsec driver in ACPI mode, and hardcode the mode to PHY_INTERFACE_MODE_NA, which should work with any PHY provided that it is configured by the time the driver attaches to it. While at it, document that omitting the mode is permitted for DT probing as well, by setting the phy-mode DT property to the empty string. Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Ard Biesheuvel Reviewed-by: Ilias Apalodimas Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20201018163625.2392-1-ardb@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- .../bindings/net/socionext-netsec.txt | 4 +++- drivers/net/ethernet/socionext/netsec.c | 24 +++++++++++++------ 2 files changed, 20 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/net/socionext-netsec.txt b/Documentation/devicetree/bindings/net/socionext-netsec.txt index 9d6c9feb12ff1..a3c1dffaa4bb4 100644 --- a/Documentation/devicetree/bindings/net/socionext-netsec.txt +++ b/Documentation/devicetree/bindings/net/socionext-netsec.txt @@ -30,7 +30,9 @@ Optional properties: (See ethernet.txt file in the same directory) - max-frame-size: See ethernet.txt in the same directory. The MAC address will be determined using the optional properties -defined in ethernet.txt. +defined in ethernet.txt. The 'phy-mode' property is required, but may +be set to the empty string if the PHY configuration is programmed by +the firmware or set by hardware straps, and needs to be preserved. Example: eth0: ethernet@522d0000 { diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c index 0f366cc50b74c..7f8be61a37089 100644 --- a/drivers/net/ethernet/socionext/netsec.c +++ b/drivers/net/ethernet/socionext/netsec.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include #include @@ -1836,6 +1837,14 @@ static const struct net_device_ops netsec_netdev_ops = { static int netsec_of_probe(struct platform_device *pdev, struct netsec_priv *priv, u32 *phy_addr) { + int err; + + err = of_get_phy_mode(pdev->dev.of_node, &priv->phy_interface); + if (err) { + dev_err(&pdev->dev, "missing required property 'phy-mode'\n"); + return err; + } + priv->phy_np = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0); if (!priv->phy_np) { dev_err(&pdev->dev, "missing required property 'phy-handle'\n"); @@ -1862,6 +1871,14 @@ static int netsec_acpi_probe(struct platform_device *pdev, if (!IS_ENABLED(CONFIG_ACPI)) return -ENODEV; + /* ACPI systems are assumed to configure the PHY in firmware, so + * there is really no need to discover the PHY mode from the DSDT. + * Since firmware is known to exist in the field that configures the + * PHY correctly but passes the wrong mode string in the phy-mode + * device property, we have no choice but to ignore it. + */ + priv->phy_interface = PHY_INTERFACE_MODE_NA; + ret = device_property_read_u32(&pdev->dev, "phy-channel", phy_addr); if (ret) { dev_err(&pdev->dev, @@ -1998,13 +2015,6 @@ static int netsec_probe(struct platform_device *pdev) priv->msg_enable = NETIF_MSG_TX_ERR | NETIF_MSG_HW | NETIF_MSG_DRV | NETIF_MSG_LINK | NETIF_MSG_PROBE; - priv->phy_interface = device_get_phy_mode(&pdev->dev); - if ((int)priv->phy_interface < 0) { - dev_err(&pdev->dev, "missing required property 'phy-mode'\n"); - ret = -ENODEV; - goto free_ndev; - } - priv->ioaddr = devm_ioremap(&pdev->dev, mmio_res->start, resource_size(mmio_res)); if (!priv->ioaddr) { -- 2.25.1