| Message ID | 20230727-synquacer-net-v1-1-4d7f5c4cc8d9@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: netsec: Ignore 'phy-mode' on SynQuacer in DT mode | expand |
(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);
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,