lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 15 Nov 2020 18:07:24 +0100
From:   Hauke Mehrtens <hauke@...ke-m.de>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        netdev@...r.kernel.org
Cc:     andrew@...n.ch, vivien.didelot@...il.com, f.fainelli@...il.com,
        olteanv@...il.com, davem@...emloft.net, kuba@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] net: lantiq: Wait for the GPHY firmware to be ready

On 11/15/20 5:57 PM, Martin Blumenstingl wrote:
> A user reports (slightly shortened from the original message):
>    libphy: lantiq,xrx200-mdio: probed
>    mdio_bus 1e108000.switch-mii: MDIO device at address 17 is missing.
>    gswip 1e108000.switch lan: no phy at 2
>    gswip 1e108000.switch lan: failed to connect to port 2: -19
>    lantiq,xrx200-net 1e10b308.eth eth0: error -19 setting up slave phy
> 
> This is a single-port board using the internal Fast Ethernet PHY. The
> user reports that switching to PHY scanning instead of configuring the
> PHY within device-tree works around this issue.
> 
> The documentation for the standalone variant of the PHY11G (which is
> probably very similar to what is used inside the xRX200 SoCs but having
> the firmware burnt onto that standalone chip in the factory) states that
> the PHY needs 300ms to be ready for MDIO communication after releasing
> the reset.
> 
> Add a 300ms delay after initializing all GPHYs to ensure that the GPHY
> firmware had enough time to initialize and to appear on the MDIO bus.
> Unfortunately there is no (known) documentation on what the minimum time
> to wait after releasing the reset on an internal PHY so play safe and
> take the one for the external variant. Only wait after the last GPHY
> firmware is loaded to not slow down the initialization too much (
> xRX200 has two GPHYs but newer SoCs have at least three GPHYs).
> 
> Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Reviewed-by: Andrew Lunn <andrew@...n.ch>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@...glemail.com>

Acked-by: Hauke Mehrtens <hauke@...ke-m.de>

> ---
> Changes since v1:
> - move the msleep() closer to the actual loop over all GPHY instances
>    as suggested by Andrew
> - added Andrew's Reviewed-by (thank you!)
> 
> 
>   drivers/net/dsa/lantiq_gswip.c | 11 +++++++++++
>   1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
> index 74db81dafee3..09701c17f3f6 100644
> --- a/drivers/net/dsa/lantiq_gswip.c
> +++ b/drivers/net/dsa/lantiq_gswip.c
> @@ -26,6 +26,7 @@
>    */
>   
>   #include <linux/clk.h>
> +#include <linux/delay.h>
>   #include <linux/etherdevice.h>
>   #include <linux/firmware.h>
>   #include <linux/if_bridge.h>
> @@ -1837,6 +1838,16 @@ static int gswip_gphy_fw_list(struct gswip_priv *priv,
>   		i++;
>   	}
>   
> +	/* The standalone PHY11G requires 300ms to be fully
> +	 * initialized and ready for any MDIO communication after being
> +	 * taken out of reset. For the SoC-internal GPHY variant there
> +	 * is no (known) documentation for the minimum time after a
> +	 * reset. Use the same value as for the standalone variant as
> +	 * some users have reported internal PHYs not being detected
> +	 * without any delay.
> +	 */
> +	msleep(300);
> +
>   	return 0;
>   
>   remove_gphy:
> 


Download attachment "OpenPGP_0x93DD20630910B515.asc" of type "application/pgp-keys" (9896 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ