From: Tristram Ha <[email protected]>
KSZ8061 needs to write to a MMD register at driver initialization to fix
an errata. This worked in 4.14 kernel but not in newer kernels. The
issue is the main phylib code no longer resets PHY at the very beginning.
Calling phy resuming code later will reset the chip if it is already
powered down at the beginning. This wipes out the MMD register write.
Solution is to implement a phy resume function for KSZ8061 to take care
of this problem.
Fixes: 232ba3a51cc2 ("net: phy: Micrel KSZ8061: link failure after cable connect")
Signed-off-by: Tristram Ha <[email protected]>
---
drivers/net/phy/micrel.c | 42 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 2b8f8b7f1517..618e532ee5d7 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -866,6 +866,17 @@ static int ksz8061_config_init(struct phy_device *phydev)
{
int ret;
+ /* Chip can be powered down by the bootstrap code. */
+ ret = phy_read(phydev, MII_BMCR);
+ if (ret < 0)
+ return ret;
+ if (ret & BMCR_PDOWN) {
+ ret = phy_write(phydev, MII_BMCR, ret & ~BMCR_PDOWN);
+ if (ret < 0)
+ return ret;
+ usleep_range(1000, 2000);
+ }
+
ret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_DEVID1, 0xB61A);
if (ret)
return ret;
@@ -2085,6 +2096,35 @@ static int kszphy_resume(struct phy_device *phydev)
return 0;
}
+static int ksz8061_resume(struct phy_device *phydev)
+{
+ int ret;
+
+ /* This function can be called twice when the Ethernet device is on. */
+ ret = phy_read(phydev, MII_BMCR);
+ if (ret < 0)
+ return ret;
+ if (!(ret & BMCR_PDOWN))
+ return 0;
+
+ genphy_resume(phydev);
+ usleep_range(1000, 2000);
+
+ /* Re-program the value after chip is reset. */
+ ret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_DEVID1, 0xB61A);
+ if (ret)
+ return ret;
+
+ /* Enable PHY Interrupts */
+ if (phy_interrupt_is_valid(phydev)) {
+ phydev->interrupts = PHY_INTERRUPT_ENABLED;
+ if (phydev->drv->config_intr)
+ phydev->drv->config_intr(phydev);
+ }
+
+ return 0;
+}
+
static int kszphy_probe(struct phy_device *phydev)
{
const struct kszphy_type *type = phydev->drv->driver_data;
@@ -5339,7 +5379,7 @@ static struct phy_driver ksphy_driver[] = {
.config_intr = kszphy_config_intr,
.handle_interrupt = kszphy_handle_interrupt,
.suspend = kszphy_suspend,
- .resume = kszphy_resume,
+ .resume = ksz8061_resume,
}, {
.phy_id = PHY_ID_KSZ9021,
.phy_id_mask = 0x000ffffe,
--
2.34.1
On Tue, 2024-05-28 at 14:37 -0700, [email protected] wrote:
> From: Tristram Ha <[email protected]>
>
> KSZ8061 needs to write to a MMD register at driver initialization to fix
> an errata. This worked in 4.14 kernel but not in newer kernels. The
> issue is the main phylib code no longer resets PHY at the very beginning.
> Calling phy resuming code later will reset the chip if it is already
> powered down at the beginning. This wipes out the MMD register write.
> Solution is to implement a phy resume function for KSZ8061 to take care
> of this problem.
>
> Fixes: 232ba3a51cc2 ("net: phy: Micrel KSZ8061: link failure after cable connect")
As the blamed commit belongs to 5.0 and the changelog hints anything
after 4.14 is broken, it looks like there is an inconsistency. Please
fix the changelog or the tag.
Thanks,
Paolo
> Subject: Re: [PATCH net] net: phy: Micrel KSZ8061: fix errata solution not taking effect
> problem
>
> On Tue, 2024-05-28 at 14:37 -0700, [email protected] wrote:
> > From: Tristram Ha <[email protected]>
> >
> > KSZ8061 needs to write to a MMD register at driver initialization to fix
> > an errata. This worked in 4.14 kernel but not in newer kernels. The
> > issue is the main phylib code no longer resets PHY at the very beginning.
> > Calling phy resuming code later will reset the chip if it is already
> > powered down at the beginning. This wipes out the MMD register write.
> > Solution is to implement a phy resume function for KSZ8061 to take care
> > of this problem.
> >
> > Fixes: 232ba3a51cc2 ("net: phy: Micrel KSZ8061: link failure after cable connect")
>
> As the blamed commit belongs to 5.0 and the changelog hints anything
> after 4.14 is broken, it looks like there is an inconsistency. Please
> fix the changelog or the tag.
A customer reported this problem and said they were using 4.14 and cited
this commit, so I assumed it was added in that kernel. Indeed 4.19
kernel has this code, so it was probably backported.
I will update the comment.