On 4/22/2021 6:47 PM, Ansuel Smith wrote:
> With the use of the qca8k dsa driver, some problem arised related to
> port status detection. With a load on a specific port (for example a
> simple speed test), the driver starts to bheave in a strange way and
s/bheave/behave/
> garbage data is produced. To address this, enlarge the sleep delay and
> address a bug for the reg offset 31 that require additional delay for
> this specific reg.
>
> Signed-off-by: Ansuel Smith <ansuelsmth@xxxxxxxxx>
> ---
> drivers/net/mdio/mdio-ipq8064.c | 36 ++++++++++++++++++++-------------
> 1 file changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/mdio/mdio-ipq8064.c b/drivers/net/mdio/mdio-ipq8064.c
> index 1bd18857e1c5..5bd6d0501642 100644
> --- a/drivers/net/mdio/mdio-ipq8064.c
> +++ b/drivers/net/mdio/mdio-ipq8064.c
> @@ -15,25 +15,26 @@
> #include <linux/mfd/syscon.h>
>
> /* MII address register definitions */
> -#define MII_ADDR_REG_ADDR 0x10
> -#define MII_BUSY BIT(0)
> -#define MII_WRITE BIT(1)
> -#define MII_CLKRANGE_60_100M (0 << 2)
> -#define MII_CLKRANGE_100_150M (1 << 2)
> -#define MII_CLKRANGE_20_35M (2 << 2)
> -#define MII_CLKRANGE_35_60M (3 << 2)
> -#define MII_CLKRANGE_150_250M (4 << 2)
> -#define MII_CLKRANGE_250_300M (5 << 2)
> +#define MII_ADDR_REG_ADDR 0x10
> +#define MII_BUSY BIT(0)
> +#define MII_WRITE BIT(1)
> +#define MII_CLKRANGE(x) ((x) << 2)
> +#define MII_CLKRANGE_60_100M MII_CLKRANGE(0)
> +#define MII_CLKRANGE_100_150M MII_CLKRANGE(1)
> +#define MII_CLKRANGE_20_35M MII_CLKRANGE(2)
> +#define MII_CLKRANGE_35_60M MII_CLKRANGE(3)
> +#define MII_CLKRANGE_150_250M MII_CLKRANGE(4)
> +#define MII_CLKRANGE_250_300M MII_CLKRANGE(5)
> #define MII_CLKRANGE_MASK GENMASK(4, 2)
> #define MII_REG_SHIFT 6
> #define MII_REG_MASK GENMASK(10, 6)
> #define MII_ADDR_SHIFT 11
> #define MII_ADDR_MASK GENMASK(15, 11)
>
> -#define MII_DATA_REG_ADDR 0x14
> +#define MII_DATA_REG_ADDR 0x14
>
> -#define MII_MDIO_DELAY_USEC (1000)
> -#define MII_MDIO_RETRY_MSEC (10)
> +#define MII_MDIO_DELAY_USEC (1000)
> +#define MII_MDIO_RETRY_MSEC (10)
These changes are not related to what you are doing and are just
whitespace cleaning, better not to mix them with functional changes.
>
> struct ipq8064_mdio {
> struct regmap *base; /* NSS_GMAC0_BASE */
> @@ -65,7 +66,7 @@ ipq8064_mdio_read(struct mii_bus *bus, int phy_addr, int reg_offset)
> ((reg_offset << MII_REG_SHIFT) & MII_REG_MASK);
>
> regmap_write(priv->base, MII_ADDR_REG_ADDR, miiaddr);
> - usleep_range(8, 10);
> + usleep_range(10, 13);
>
> err = ipq8064_mdio_wait_busy(priv);
> if (err)
> @@ -91,7 +92,14 @@ ipq8064_mdio_write(struct mii_bus *bus, int phy_addr, int reg_offset, u16 data)
> ((reg_offset << MII_REG_SHIFT) & MII_REG_MASK);
>
> regmap_write(priv->base, MII_ADDR_REG_ADDR, miiaddr);
> - usleep_range(8, 10);
> +
> + /* For the specific reg 31 extra time is needed or the next
> + * read will produce grabage data.
s/grabage/garbage/
> + */
> + if (reg_offset == 31)
> + usleep_range(30, 43);
> + else
> + usleep_range(10, 13);
This is just super weird, presumably register 31 needs to be conditional
to the PHY, or pseudo-PHY being driven here. Not that it would harm, but
waiting an extra 30 to 43 microseconds with a Marvell PHY or Broadcom
PHY or from another vendor would not be necessary.
>
> return ipq8064_mdio_wait_busy(priv);
> }
>
--
Florian
