Message ID | 20230727-synquacer-net-v1-1-4d7f5c4cc8d9@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:918b:0:b0:3e4:2afc:c1 with SMTP id s11csp44269vqg; Thu, 27 Jul 2023 15:22:55 -0700 (PDT) X-Google-Smtp-Source: APBJJlG0tx4RR4gX82vlylaqp03r/c9syebkis8HUbq4sWVLOAsUyKVexP+cgF/3nlnvx5018eem X-Received: by 2002:a17:906:cc18:b0:994:536c:ab45 with SMTP id ml24-20020a170906cc1800b00994536cab45mr367417ejb.50.1690496575277; Thu, 27 Jul 2023 15:22:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690496575; cv=none; d=google.com; s=arc-20160816; b=tGe9ys5QRqRGmaZmGYqxgk/deww4AeQ22Sc2mk4cC9srPovYQJ1slqlxjpM+bAfODX DSn2qvWy+D4OAHtJM3ya5X6Ylm5qQ8LNdmHBS7SWTCcayyFnTBk/7jw9aJtMMyea+qPO 2VsnDPqO6x7/TJp2o2Tdq0bE+xBd8+R+KXzY2ASUjoWJTk4roxahcbJ48oETrU5jY3J5 2BYpQYoQkGJV990L3pAXHAJhfw3k1LnBElNSnX81F5cFSwzy8o9lbOlQ1HCfiSWc9uwW KkgkCDD+3me68xrVJmVtZ/VwkyfdikxhxbuZIt9v2oi13u4Xgi37paJjYDQgOJMSgTVy s+qA== 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=q9naNjmmV+kjiINXUG9ovc+0PVemwMLz2VaaEFwu3d4=; fh=gsAi6XYBDlj2no5ch28ZlwFf5rjnIoE7OSMSOysE1bo=; b=Q3+EW8hQOxiSQl/tcq2QIrD3MKK6B7JnMgWsWKnI/9AkcUKhnsZu+voBoLUOMk5u41 9BSaDZdv7xTlxVBA9EKXJW8BjmufQhhQqnQUN8hn7pnvZH+qOEHDUljS58YwU3OTRrZs wTcPANYBf1lWot/pUwG7Ofw1KY36naEairFqHWaG6iqQbLX92B2AORaeenXupxFW+/Np WGjTpYDlVYXyO+ftI+SWuO6T9k+WvyP9rmgiY4ExCY7YPQcDTwSkg1FxXYhqNud1zJrh fGBex3mEYzv1TXIH2qTPYSue1n5HQXPZl/3i/BQv4Fywq+KxrBM+niLQE44UYaSAO79e +8Nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kp+CBFFr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lu22-20020a170906fad600b0099bc91d70cdsi1642041ejb.545.2023.07.27.15.22.31; Thu, 27 Jul 2023 15:22:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kp+CBFFr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232411AbjG0Vwc (ORCPT <rfc822;kloczko.tomasz@gmail.com> + 99 others); Thu, 27 Jul 2023 17:52:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232329AbjG0Vw2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 27 Jul 2023 17:52:28 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B07EF273D for <linux-kernel@vger.kernel.org>; Thu, 27 Jul 2023 14:52:26 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3ED3861F60 for <linux-kernel@vger.kernel.org>; Thu, 27 Jul 2023 21:52:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 680C2C433C7; Thu, 27 Jul 2023 21:52:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690494745; bh=Ci/kQ+3GXmZ9KWTZr+IFy1WrIkY5Ht6Ig6pJfUkdeDo=; h=From:Date:Subject:To:Cc:From; b=kp+CBFFrgbVA9nunVmFfFov2c6X35oqh2h5sc8XEvUINx8ARq6p8FjI3csT5rWwqO xgSDi2/+G6YESrMG2cVTnPzO0ID+rjGkRzKxHbgGkdKJsuuIuGxrj68zHgohSviUSJ 5PhBleO1JhFktaVuMNAVCOBQueyCgqDaDHlrjZJtxUrgAxcvk4LGPq6VybKE2I4Ofi KJvkVsBSARXq/xijcHzaVykzJgKqFz9tFoU91pwrRb+ueq9TxaF2P8EY0Jt3ztGh3g KsxHhhDlqpEwHnDC8D0g8H6kG+0YwAhBWPeFb57n1jVA9otNCQXIlWPj0sLNepXbM3 4XVfIdSRnk89Q== From: Mark Brown <broonie@kernel.org> Date: Thu, 27 Jul 2023 22:52:18 +0100 Subject: [PATCH] net: netsec: Ignore 'phy-mode' on SynQuacer in DT mode MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230727-synquacer-net-v1-1-4d7f5c4cc8d9@kernel.org> X-B4-Tracking: v=1; b=H4sIABHnwmQC/x2MSwqAIBQArxJvneAPhK4SLdSe9TZWWlGId09az sBMgYyJMMPQFUh4U6YtNhB9B361cUFGc2OQXCpupGH5jcdlPSYW8WQotQhKuyYctGZPGOj5f+N U6wdNSuQKXwAAAA== To: Jassi Brar <jaswinder.singh@linaro.org>, Ilias Apalodimas <ilias.apalodimas@linaro.org>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Ard Biesheuvel <ardb@kernel.org> Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org> X-Mailer: b4 0.13-dev-099c9 X-Developer-Signature: v=1; a=openpgp-sha256; l=2333; i=broonie@kernel.org; h=from:subject:message-id; bh=Ci/kQ+3GXmZ9KWTZr+IFy1WrIkY5Ht6Ig6pJfUkdeDo=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBkwucVsRSi9lgKrSxbjfqZ9spBLrUU4uPGExUZQ fK4hbw2O6KJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZMLnFQAKCRAk1otyXVSH 0E+qB/4xv+rjWIsXLmaGzgl8gXmDKVoJJddQspvU1fkqxvAehiVocxiYQMny4dDJsUDQpMmdidH OEmt5Pz5wO8Bm3cKwgh+itjcK7FpGYDAJhVX+eIByTC8EKviHUhgJ8dAgcmkCF1WU6YSkH/FYLG 12OtRQaGB0zamvBW6ANKMjVGR5PHmPUrufOWMY+uAZ8Q2VKhLTwXI2hoY4ma+HttMRdyRKg1IUu svM6QaXtVn17vOXqcX4gxro82hASks4OmDwPaa99SuGh8M9wVvpnSr5frWiSue+eXEPs8mtRAwJ RuFK/zY/RN5tJz5jGHyehh71GzSyPDX6UR3hCBgFkZUv7iEA X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772614137072925079 X-GMAIL-MSGID: 1772614137072925079 |
Series |
net: netsec: Ignore 'phy-mode' on SynQuacer in DT mode
|
|
Commit Message
Mark Brown
July 27, 2023, 9:52 p.m. UTC
As documented in acd7aaf51b20 ("netsec: ignore 'phy-mode' device
property on ACPI systems") the SocioNext SynQuacer platform ships with
firmware defining the PHY mode as RGMII even though the physical
configuration of the PHY is for TX and RX commits. Since
bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx delay config")
this has caused misconfiguration of the PHY, rendering the network
unusable.
This was worked around for ACPI by ignoring the phy-mode property but
the system is also used with DT. Since the firmware used with DT is the
same (the firmware interface is selectable in the firmware
configuration) and the firmware configures the PHY prior to running the
OS we can use the same workaround.
Limit this to the SynQuacer, though practically speaking this is the
only currently known system using this device.
Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver")
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/net/ethernet/socionext/netsec.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
---
base-commit: 6eaae198076080886b9e7d57f4ae06fa782f90ef
change-id: 20230727-synquacer-net-e241f34baceb
Best regards,
Comments
(cc Masahisa) On Thu, 27 Jul 2023 at 23:52, Mark Brown <broonie@kernel.org> wrote: > > As documented in acd7aaf51b20 ("netsec: ignore 'phy-mode' device > property on ACPI systems") the SocioNext SynQuacer platform ships with > firmware defining the PHY mode as RGMII even though the physical > configuration of the PHY is for TX and RX commits. Since > bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx delay config") > this has caused misconfiguration of the PHY, rendering the network > unusable. > > This was worked around for ACPI by ignoring the phy-mode property but > the system is also used with DT. Since the firmware used with DT is the > same (the firmware interface is selectable in the firmware > configuration) and the firmware configures the PHY prior to running the > OS we can use the same workaround. > Wouldn't this break SynQuacers booting with firmware that lacks a network driver? (I.e., u-boot?) I am not sure why, but quite some effort has gone into porting u-boot to this SoC as well. > Limit this to the SynQuacer, though practically speaking this is the > only currently known system using this device. > > Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > drivers/net/ethernet/socionext/netsec.c | 18 ++++++++++++++---- > 1 file changed, 14 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c > index 2d7347b71c41..ae4d336efaa4 100644 > --- a/drivers/net/ethernet/socionext/netsec.c > +++ b/drivers/net/ethernet/socionext/netsec.c > @@ -1845,10 +1845,20 @@ static int netsec_of_probe(struct platform_device *pdev, > { > 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; > + if (of_machine_is_compatible("socionext,developer-box")) { > + /* > + * SynQuacer reports RGMII but is physically > + * configured with TX and RX delays, since the > + * firwmare configures the PHY prior to boot just > + * ignore the configuration. > + */ > + priv->phy_interface = PHY_INTERFACE_MODE_NA; > + } else { > + 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); > > --- > base-commit: 6eaae198076080886b9e7d57f4ae06fa782f90ef > change-id: 20230727-synquacer-net-e241f34baceb > > Best regards, > -- > Mark Brown <broonie@kernel.org> >
> Wouldn't this break SynQuacers booting with firmware that lacks a > network driver? (I.e., u-boot?) > > I am not sure why, but quite some effort has gone into porting u-boot > to this SoC as well. Agreed, Rather than PHY_INTERFACE_MODE_NA, please use the correct value. Andrew
Hi Ard, Mark On Fri, Jul 28, 2023 at 07:45:44AM +0200, Ard Biesheuvel wrote: > (cc Masahisa) > > On Thu, 27 Jul 2023 at 23:52, Mark Brown <broonie@kernel.org> wrote: > > > > As documented in acd7aaf51b20 ("netsec: ignore 'phy-mode' device > > property on ACPI systems") the SocioNext SynQuacer platform ships with > > firmware defining the PHY mode as RGMII even though the physical > > configuration of the PHY is for TX and RX commits. Since > > bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx delay config") > > this has caused misconfiguration of the PHY, rendering the network > > unusable. > > > > This was worked around for ACPI by ignoring the phy-mode property but > > the system is also used with DT. Since the firmware used with DT is the > > same (the firmware interface is selectable in the firmware > > configuration) and the firmware configures the PHY prior to running the > > OS we can use the same workaround. > > > > Wouldn't this break SynQuacers booting with firmware that lacks a > network driver? (I.e., u-boot?) > U-Boot does support the network interface (sni-netsec.c) but I'll have to check what that code does wrt to the PHY config. Since the interface works I am assuming some config is done properly. > I am not sure why, but quite some effort has gone into porting u-boot > to this SoC as well. It was mostly an effort to prove the box is SystemReady-IR compliant. On top of that it was (back then) one of the few available platforms with an RPMB interface and OP-TEE support, so it was used for demonstrating storing EFI variables there. Regards /Ilias > > > > Limit this to the SynQuacer, though practically speaking this is the > > only currently known system using this device. > > > > Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") > > Signed-off-by: Mark Brown <broonie@kernel.org> > > --- > > drivers/net/ethernet/socionext/netsec.c | 18 ++++++++++++++---- > > 1 file changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c > > index 2d7347b71c41..ae4d336efaa4 100644 > > --- a/drivers/net/ethernet/socionext/netsec.c > > +++ b/drivers/net/ethernet/socionext/netsec.c > > @@ -1845,10 +1845,20 @@ static int netsec_of_probe(struct platform_device *pdev, > > { > > 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; > > + if (of_machine_is_compatible("socionext,developer-box")) { > > + /* > > + * SynQuacer reports RGMII but is physically > > + * configured with TX and RX delays, since the > > + * firwmare configures the PHY prior to boot just > > + * ignore the configuration. > > + */ > > + priv->phy_interface = PHY_INTERFACE_MODE_NA; > > + } else { > > + 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); > > > > --- > > base-commit: 6eaae198076080886b9e7d57f4ae06fa782f90ef > > change-id: 20230727-synquacer-net-e241f34baceb > > > > Best regards, > > -- > > Mark Brown <broonie@kernel.org> > >
> U-Boot does support the network interface (sni-netsec.c) but I'll have to > check what that code does wrt to the PHY config. Since the interface works > I am assuming some config is done properly. It might only be done if TFTP boot is used etc. If booting from FLASH, maybe the network is not initialised, leaving the PHY in its power on default state. In general, it is much better for Linux not to assume the bootloader has configured the hardware, since developers have a choice of boot loaders. Andrew
On Fri, Jul 28, 2023 at 07:45:44AM +0200, Ard Biesheuvel wrote: > On Thu, 27 Jul 2023 at 23:52, Mark Brown <broonie@kernel.org> wrote: > > As documented in acd7aaf51b20 ("netsec: ignore 'phy-mode' device > > property on ACPI systems") the SocioNext SynQuacer platform ships with > > firmware defining the PHY mode as RGMII even though the physical > > configuration of the PHY is for TX and RX commits. Since > > bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx delay config") > > this has caused misconfiguration of the PHY, rendering the network > > unusable. > Wouldn't this break SynQuacers booting with firmware that lacks a > network driver? (I.e., u-boot?) > I am not sure why, but quite some effort has gone into porting u-boot > to this SoC as well. Yes, it'd be break them. I wasn't aware that any other firmwares existed.
On Fri, Jul 28, 2023 at 10:41:40AM +0200, Andrew Lunn wrote: > > Wouldn't this break SynQuacers booting with firmware that lacks a > > network driver? (I.e., u-boot?) > > I am not sure why, but quite some effort has gone into porting u-boot > > to this SoC as well. > Agreed, Rather than PHY_INTERFACE_MODE_NA, please use the correct > value. Does anyone know off hand what the correct value is? I only have access to one of these in a remote test lab which makes everything more painful.
On Fri, 28 Jul 2023 at 20:43, Mark Brown <broonie@kernel.org> wrote: > > On Fri, Jul 28, 2023 at 10:41:40AM +0200, Andrew Lunn wrote: > > > Wouldn't this break SynQuacers booting with firmware that lacks a > > > network driver? (I.e., u-boot?) > > > > I am not sure why, but quite some effort has gone into porting u-boot > > > to this SoC as well. > > > Agreed, Rather than PHY_INTERFACE_MODE_NA, please use the correct > > value. > > Does anyone know off hand what the correct value is? I only have access > to one of these in a remote test lab which makes everything more > painful. "rgmii-id" is correct, configured by board level. The latest EDK2 firmware was already modified to use the correct value for DT(Thank you, Ard). http://snapshots.linaro.org/components/kernel/leg-96boards-developerbox-edk2/100/ Thanks, Masahisa Kojima
On Fri, Jul 28, 2023 at 09:35:00PM +0900, Masahisa Kojima wrote: > On Fri, 28 Jul 2023 at 20:43, Mark Brown <broonie@kernel.org> wrote: > > > > On Fri, Jul 28, 2023 at 10:41:40AM +0200, Andrew Lunn wrote: > > > > Wouldn't this break SynQuacers booting with firmware that lacks a > > > > network driver? (I.e., u-boot?) > > > > > > I am not sure why, but quite some effort has gone into porting u-boot > > > > to this SoC as well. > > > > > Agreed, Rather than PHY_INTERFACE_MODE_NA, please use the correct > > > value. > > > > Does anyone know off hand what the correct value is? I only have access > > to one of these in a remote test lab which makes everything more > > painful. > > "rgmii-id" is correct, configured by board level. > The latest EDK2 firmware was already modified to use the correct value > for DT(Thank you, Ard). > http://snapshots.linaro.org/components/kernel/leg-96boards-developerbox-edk2/100/ Yes, anything other than rgmii-id is generally wrong. That maps to PHY_INTERFACE_MODE_RGMII_ID. If the firmware has been fixed, i would actually do something like: err = of_get_phy_mode(pdev->dev.of_node, &priv->phy_interface); if (err) return err; if (of_machine_is_compatible("socionext,developer-box") && priv->phy_interface != PHY_INTERFACE_MODE_RGMII_ID) { pr_warn(FW_WARN, "Working around broken firmware. Please upgrade your firmware"); priv->phy_interface = PHY_INTERFACE_MODE_RGMII_ID; } Andrew
On Fri, Jul 28, 2023 at 07:07:36PM +0200, Andrew Lunn wrote: > On Fri, Jul 28, 2023 at 09:35:00PM +0900, Masahisa Kojima wrote: > > "rgmii-id" is correct, configured by board level. > > The latest EDK2 firmware was already modified to use the correct value > > for DT(Thank you, Ard). > > http://snapshots.linaro.org/components/kernel/leg-96boards-developerbox-edk2/100/ Thanks, that does seem to be working. > If the firmware has been fixed, i would actually do something like: > err = of_get_phy_mode(pdev->dev.of_node, &priv->phy_interface); > if (err) > return err; > if (of_machine_is_compatible("socionext,developer-box") && > priv->phy_interface != PHY_INTERFACE_MODE_RGMII_ID) { > pr_warn(FW_WARN, "Working around broken firmware. Please upgrade your firmware"); > priv->phy_interface = PHY_INTERFACE_MODE_RGMII_ID; > } It is not clear to me that the release channels for this firmware are sufficiently clear to users for this to be constructive.
On Sat, 29 Jul 2023 at 02:11, Mark Brown <broonie@kernel.org> wrote: > > On Fri, Jul 28, 2023 at 07:07:36PM +0200, Andrew Lunn wrote: > > On Fri, Jul 28, 2023 at 09:35:00PM +0900, Masahisa Kojima wrote: > > > > "rgmii-id" is correct, configured by board level. > > > The latest EDK2 firmware was already modified to use the correct value > > > for DT(Thank you, Ard). > > > http://snapshots.linaro.org/components/kernel/leg-96boards-developerbox-edk2/100/ > > Thanks, that does seem to be working. > > > If the firmware has been fixed, i would actually do something like: > > > err = of_get_phy_mode(pdev->dev.of_node, &priv->phy_interface); > > if (err) > > return err; > > > if (of_machine_is_compatible("socionext,developer-box") && > > priv->phy_interface != PHY_INTERFACE_MODE_RGMII_ID) { > > pr_warn(FW_WARN, "Working around broken firmware. Please upgrade your firmware"); > > priv->phy_interface = PHY_INTERFACE_MODE_RGMII_ID; > > } > > It is not clear to me that the release channels for this firmware are > sufficiently clear to users for this to be constructive. It is not a good situation, but a new firmware release is not officially announced. Development efforts moved from EDK2 to U-Boot for System Ready-IR for the last two years. Thanks, Masahisa Kojima
diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c index 2d7347b71c41..ae4d336efaa4 100644 --- a/drivers/net/ethernet/socionext/netsec.c +++ b/drivers/net/ethernet/socionext/netsec.c @@ -1845,10 +1845,20 @@ static int netsec_of_probe(struct platform_device *pdev, { 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; + if (of_machine_is_compatible("socionext,developer-box")) { + /* + * SynQuacer reports RGMII but is physically + * configured with TX and RX delays, since the + * firwmare configures the PHY prior to boot just + * ignore the configuration. + */ + priv->phy_interface = PHY_INTERFACE_MODE_NA; + } else { + 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);