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 <[email protected]>
---
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 <[email protected]>
(cc Masahisa)
On Thu, 27 Jul 2023 at 23:52, Mark Brown <[email protected]> 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 <[email protected]>
> ---
> 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 <[email protected]>
>
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 <[email protected]> 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 <[email protected]>
> > ---
> > 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 <[email protected]>
> >
> 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
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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