After the power-down bit is cleared, the chip internally triggers a
global reset. According to the KSZ9031 documentation, we have to wait at
least 1ms for the reset to finish.
If the chip is accessed during reset, read will return 0xffff, while
write will be ignored. Depending on the system performance and MDIO bus
speed, we may or may not run in to this issue.
This bug was discovered on an iMX6QP system with KSZ9031 PHY and
attached PHY interrupt line. If IRQ was used, the link status update was
lost. In polling mode, the link status update was always correct.
The investigation showed, that during a read-modify-write access, the
read returned 0xffff (while the chip was still in reset) and
corresponding write hit the chip _after_ reset and triggered (due to the
0xffff) another reset in an undocumented bit (register 0x1f, bit 1),
resulting in the next write being lost due to the new reset cycle.
This patch fixes the issue by adding a 1...2 ms sleep after the
genphy_resume().
Fixes: 836384d2501d ("net: phy: micrel: Add specific suspend")
Signed-off-by: Oleksij Rempel <[email protected]>
---
drivers/net/phy/micrel.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 2ec19e5540bff..05d20343b8161 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -25,6 +25,7 @@
#include <linux/micrel_phy.h>
#include <linux/of.h>
#include <linux/clk.h>
+#include <linux/delay.h>
/* Operation Mode Strap Override */
#define MII_KSZPHY_OMSO 0x16
@@ -952,6 +953,12 @@ static int kszphy_resume(struct phy_device *phydev)
genphy_resume(phydev);
+ /* After switching from power-down to normal mode, an internal global
+ * reset is automatically generated. Wait a minimum of 1 ms before
+ * read/write access to the PHY registers.
+ */
+ usleep_range(1000, 2000);
+
ret = kszphy_config_reset(phydev);
if (ret)
return ret;
--
2.26.0.rc2
On Fri, Apr 03, 2020 at 09:53:25AM +0200, Oleksij Rempel wrote:
> After the power-down bit is cleared, the chip internally triggers a
> global reset. According to the KSZ9031 documentation, we have to wait at
> least 1ms for the reset to finish.
>
> If the chip is accessed during reset, read will return 0xffff, while
> write will be ignored. Depending on the system performance and MDIO bus
> speed, we may or may not run in to this issue.
>
> This bug was discovered on an iMX6QP system with KSZ9031 PHY and
> attached PHY interrupt line. If IRQ was used, the link status update was
> lost. In polling mode, the link status update was always correct.
>
> The investigation showed, that during a read-modify-write access, the
> read returned 0xffff (while the chip was still in reset) and
> corresponding write hit the chip _after_ reset and triggered (due to the
> 0xffff) another reset in an undocumented bit (register 0x1f, bit 1),
> resulting in the next write being lost due to the new reset cycle.
>
> This patch fixes the issue by adding a 1...2 ms sleep after the
> genphy_resume().
>
> Fixes: 836384d2501d ("net: phy: micrel: Add specific suspend")
> Signed-off-by: Oleksij Rempel <[email protected]>
Hi Oleksij
Please in future set the subject to [PATCH net v1] to indicate this is
a fix.
Reviewed-by: Andrew Lunn <[email protected]>
Andrew
On 4/3/2020 12:53 AM, Oleksij Rempel wrote:
> After the power-down bit is cleared, the chip internally triggers a
> global reset. According to the KSZ9031 documentation, we have to wait at
> least 1ms for the reset to finish.
>
> If the chip is accessed during reset, read will return 0xffff, while
> write will be ignored. Depending on the system performance and MDIO bus
> speed, we may or may not run in to this issue.
>
> This bug was discovered on an iMX6QP system with KSZ9031 PHY and
> attached PHY interrupt line. If IRQ was used, the link status update was
> lost. In polling mode, the link status update was always correct.
>
> The investigation showed, that during a read-modify-write access, the
> read returned 0xffff (while the chip was still in reset) and
> corresponding write hit the chip _after_ reset and triggered (due to the
> 0xffff) another reset in an undocumented bit (register 0x1f, bit 1),
> resulting in the next write being lost due to the new reset cycle.
>
> This patch fixes the issue by adding a 1...2 ms sleep after the
> genphy_resume().
>
> Fixes: 836384d2501d ("net: phy: micrel: Add specific suspend")
> Signed-off-by: Oleksij Rempel <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
--
Florian
From: Oleksij Rempel <[email protected]>
Date: Fri, 3 Apr 2020 09:53:25 +0200
> After the power-down bit is cleared, the chip internally triggers a
> global reset. According to the KSZ9031 documentation, we have to wait at
> least 1ms for the reset to finish.
>
> If the chip is accessed during reset, read will return 0xffff, while
> write will be ignored. Depending on the system performance and MDIO bus
> speed, we may or may not run in to this issue.
>
> This bug was discovered on an iMX6QP system with KSZ9031 PHY and
> attached PHY interrupt line. If IRQ was used, the link status update was
> lost. In polling mode, the link status update was always correct.
>
> The investigation showed, that during a read-modify-write access, the
> read returned 0xffff (while the chip was still in reset) and
> corresponding write hit the chip _after_ reset and triggered (due to the
> 0xffff) another reset in an undocumented bit (register 0x1f, bit 1),
> resulting in the next write being lost due to the new reset cycle.
>
> This patch fixes the issue by adding a 1...2 ms sleep after the
> genphy_resume().
>
> Fixes: 836384d2501d ("net: phy: micrel: Add specific suspend")
> Signed-off-by: Oleksij Rempel <[email protected]>
Applied and queued up for -stable, thank you.