* macb: probe of 10090000.ethernet failed with error -110 @ 2018-08-24 17:18 Atish Patra 2018-09-15 0:07 ` Atish Patra 0 siblings, 1 reply; 18+ messages in thread From: Atish Patra @ 2018-08-24 17:18 UTC (permalink / raw) To: linux-riscv Hi, I am not able to connect to the network on HiFiveUnleashed board (4/5 times) because of the following error. I believe the error is due to device Microsemi VSC8541 which is enabled CONFIG_MICROSEMI_PHY. ---------------------------------------------------------------------- macb 10090000.ethernet (unnamed net_device) (uninitialized): Could not attach to PHY macb: probe of 10090000.ethernet failed with error -110 ---------------------------------------------------------------------- I have all the sifive specific drivers built on top of 4.17. It works sometimes. My initial debugging points to following code path. macb_probe->phy_connect_direct->phy_attach_direct->phy_init_hw()-> genphy_soft_reset()->phy_poll_reset phy_poll_reset tries to do reset PHY by clearing the BMCR_RESET. int phy_init_hw(struct phy_device *phydev) { int ret = 0; /* Deassert the reset signal */ phy_device_reset(phydev, 0); if (!phydev->drv || !phydev->drv->config_init) return 0; if (phydev->drv->soft_reset) ret = phydev->drv->soft_reset(phydev); else ret = genphy_soft_reset(phydev); ... } static int phy_poll_reset(struct phy_device *phydev) { /* Poll until the reset bit clears (50ms per retry == 0.6 sec) */ unsigned int retries = 12; int ret; dump_stack(); do { msleep(50); ret = phy_read(phydev, MII_BMCR); if (ret < 0) return ret; } while (ret & BMCR_RESET && --retries); if (ret & BMCR_RESET) return -ETIMEDOUT; /* Some chips (smsc911x) may still need up to another 1ms after the * BMCR_RESET bit is cleared before they are usable. */ msleep(1); return 0; } It looks like genphy_soft_reset()->phy_poll_reset() timesout after trying out 0.6 seconds returning -ETIMEDOUT. I have tried to increase the timeout to 20 seconds. Still same timeout happens. I have verified the driver is getting registered. [ 5.960025] libphy: Microsemi VSC8541 SyncE: Registered new driver [ 6.455635] libphy: phy_init_hw: In phydev->drv name =[Microsemi VSC8541 SyncE] Has anybody seen this error earlier or know what can be possible reason for the timeout? Regards, Atish ^ permalink raw reply [flat|nested] 18+ messages in thread
* macb: probe of 10090000.ethernet failed with error -110 2018-08-24 17:18 macb: probe of 10090000.ethernet failed with error -110 Atish Patra @ 2018-09-15 0:07 ` Atish Patra 2019-04-10 9:50 ` Andreas Schwab 0 siblings, 1 reply; 18+ messages in thread From: Atish Patra @ 2018-09-15 0:07 UTC (permalink / raw) To: linux-riscv On 8/24/18 10:18 AM, Atish Patra wrote: > Hi, > I am not able to connect to the network on HiFiveUnleashed board (4/5 > times) because of the following error. I believe the error is due to > device Microsemi VSC8541 which is enabled CONFIG_MICROSEMI_PHY. > > ---------------------------------------------------------------------- > macb 10090000.ethernet (unnamed net_device) (uninitialized): Could not > attach to PHY > macb: probe of 10090000.ethernet failed with error -110 > ---------------------------------------------------------------------- > > I have all the sifive specific drivers built on top of 4.17. It works > sometimes. My initial debugging points to following code path. > > macb_probe->phy_connect_direct->phy_attach_direct->phy_init_hw()-> > genphy_soft_reset()->phy_poll_reset > > phy_poll_reset tries to do reset PHY by clearing the BMCR_RESET. > > int phy_init_hw(struct phy_device *phydev) > { > int ret = 0; > > /* Deassert the reset signal */ > phy_device_reset(phydev, 0); > > if (!phydev->drv || !phydev->drv->config_init) > return 0; > > if (phydev->drv->soft_reset) > ret = phydev->drv->soft_reset(phydev); > else > ret = genphy_soft_reset(phydev); > > ... > } > > static int phy_poll_reset(struct phy_device *phydev) > { > /* Poll until the reset bit clears (50ms per retry == 0.6 sec) */ > unsigned int retries = 12; > int ret; > > dump_stack(); > do { > msleep(50); > ret = phy_read(phydev, MII_BMCR); > if (ret < 0) > return ret; > } while (ret & BMCR_RESET && --retries); > if (ret & BMCR_RESET) > return -ETIMEDOUT; > > /* Some chips (smsc911x) may still need up to another 1ms after the > * BMCR_RESET bit is cleared before they are usable. > */ > msleep(1); > return 0; > } > > It looks like genphy_soft_reset()->phy_poll_reset() timesout after > trying out 0.6 seconds returning -ETIMEDOUT. I have tried to increase > the timeout to 20 seconds. Still same timeout happens. I have verified > the driver is getting registered. > > [ 5.960025] libphy: Microsemi VSC8541 SyncE: Registered new driver > [ 6.455635] libphy: phy_init_hw: In phydev->drv name =[Microsemi > VSC8541 SyncE] > > Has anybody seen this error earlier or know what can be possible reason > for the timeout? > > > Regards, > Atish > Here is probable cause for this issue and a temporary fix. FYI: I am no networking expert. So the following analysis and fix might be completely stupid and outrageous. The HighFive Unleashed board contains Microsemi 8541 PHY. Here is the spec: https://www.mouser.com/ds/2/523/Microsemi_VSC8541-01_Datasheet_10496_V40-1148034.pdf As per the spec, the PHY needs to be reset twice. However, 4.15 kernel did not have support for that. Thus, FSBL code in Unleashed is hacked to resolve it by resetting twice in their code (Thanks to Palmer for the hint). It looks like that kernel driver now supports resetting the signal one additional time. As it had been already reset twice in FSBL, PHY gets into incorrect state causing error mentioned in the below mail. The following simple HACK brings up networking in 4.19rc2 without any issues. diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c index 98f4b1f7..02c31f83 100644 --- a/drivers/net/phy/mdio_bus.c +++ b/drivers/net/phy/mdio_bus.c @@ -64,9 +64,6 @@ static int mdiobus_register_gpiod(struct mdio_device *mdiodev) mdiodev->reset = gpiod; - /* Assert the reset signal again */ - mdio_device_reset(mdiodev, 1); return 0; } The following upstream commit introduced the correct resetting of PHY devices. commit bafbdd52 Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Date: Mon Dec 4 13:35:05 2017 +0100 phylib: Add device reset GPIO support This fix proposed here is just a hack and should not merged into upstream code. Ideally, the fix should be done in FSBL code. Until, we have that from SiFive, this hack can be used as a temporary solution for anybody facing the same networking problem. Regards, Atish ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: macb: probe of 10090000.ethernet failed with error -110 2018-09-15 0:07 ` Atish Patra @ 2019-04-10 9:50 ` Andreas Schwab 0 siblings, 0 replies; 18+ messages in thread From: Andreas Schwab @ 2019-04-10 9:50 UTC (permalink / raw) To: Atish Patra Cc: Damien Le Moal, Christoph Hellwig, palmer, Howard.Hicks, Raju.Lakkaraju, Allan.Nielsen, linux-riscv On Sep 14 2018, Atish Patra <atish.patra@wdc.com> wrote: > This fix proposed here is just a hack and should not merged into upstream > code. Ideally, the fix should be done in FSBL code. So what should that be? I tried removing the second reset in the FSBL code, but that didn't change anything. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 18+ messages in thread
* macb: probe of 10090000.ethernet failed with error -110 @ 2018-11-28 10:10 Andreas Schwab 2018-11-28 10:10 ` Andreas Schwab 2018-11-28 18:15 ` Atish Patra 0 siblings, 2 replies; 18+ messages in thread From: Andreas Schwab @ 2018-11-28 10:10 UTC (permalink / raw) To: linux-riscv The PHY probing of the macb driver appears to be rather unreliable. Most of the time it doesn't work the first time, I have to reload the module several times to let it succeed. [ 40.530000] macb: GEM doesn't support hardware ptp. [ 40.530000] libphy: MACB_mii_bus: probed [ 41.450000] macb 10090000.ethernet (unnamed net_device) (uninitialized): Could not attach to PHY [ 41.510000] macb: probe of 10090000.ethernet failed with error -110 [ 1354.400000] macb: GEM doesn't support hardware ptp. [ 1354.410000] libphy: MACB_mii_bus: probed [ 1355.260000] macb 10090000.ethernet (unnamed net_device) (uninitialized): Could not attach to PHY [ 1355.300000] macb: probe of 10090000.ethernet failed with error -110 [ 1358.100000] macb: GEM doesn't support hardware ptp. [ 1358.110000] libphy: MACB_mii_bus: probed [ 1358.310000] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: attached PHY driver [Microsemi VSC8541 SyncE] (mii_bus:phy_addr=10090000.ethernet-ffffffff:00, irq=POLL) [ 1358.320000] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 at 0x10090000 irq 12 (70:b3:d5:92:f1:07) This is 4.20-rc4 on a HiFive-U. Andreas. -- Andreas Schwab, SUSE Labs, schwab at suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 18+ messages in thread
* macb: probe of 10090000.ethernet failed with error -110 2018-11-28 10:10 Andreas Schwab @ 2018-11-28 10:10 ` Andreas Schwab 2018-11-28 18:15 ` Atish Patra 1 sibling, 0 replies; 18+ messages in thread From: Andreas Schwab @ 2018-11-28 10:10 UTC (permalink / raw) To: Nicolas Ferre; +Cc: netdev, linux-riscv, linux-kernel The PHY probing of the macb driver appears to be rather unreliable. Most of the time it doesn't work the first time, I have to reload the module several times to let it succeed. [ 40.530000] macb: GEM doesn't support hardware ptp. [ 40.530000] libphy: MACB_mii_bus: probed [ 41.450000] macb 10090000.ethernet (unnamed net_device) (uninitialized): Could not attach to PHY [ 41.510000] macb: probe of 10090000.ethernet failed with error -110 [ 1354.400000] macb: GEM doesn't support hardware ptp. [ 1354.410000] libphy: MACB_mii_bus: probed [ 1355.260000] macb 10090000.ethernet (unnamed net_device) (uninitialized): Could not attach to PHY [ 1355.300000] macb: probe of 10090000.ethernet failed with error -110 [ 1358.100000] macb: GEM doesn't support hardware ptp. [ 1358.110000] libphy: MACB_mii_bus: probed [ 1358.310000] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: attached PHY driver [Microsemi VSC8541 SyncE] (mii_bus:phy_addr=10090000.ethernet-ffffffff:00, irq=POLL) [ 1358.320000] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 at 0x10090000 irq 12 (70:b3:d5:92:f1:07) This is 4.20-rc4 on a HiFive-U. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 18+ messages in thread
* macb: probe of 10090000.ethernet failed with error -110 2018-11-28 10:10 Andreas Schwab 2018-11-28 10:10 ` Andreas Schwab @ 2018-11-28 18:15 ` Atish Patra 2018-11-28 18:15 ` Atish Patra 2018-11-28 21:33 ` Florian Fainelli 1 sibling, 2 replies; 18+ messages in thread From: Atish Patra @ 2018-11-28 18:15 UTC (permalink / raw) To: linux-riscv On 11/28/18 2:11 AM, Andreas Schwab wrote: > The PHY probing of the macb driver appears to be rather unreliable. > Most of the time it doesn't work the first time, I have to reload the > module several times to let it succeed. > > [ 40.530000] macb: GEM doesn't support hardware ptp. > [ 40.530000] libphy: MACB_mii_bus: probed > [ 41.450000] macb 10090000.ethernet (unnamed net_device) (uninitialized): Could not attach to PHY > [ 41.510000] macb: probe of 10090000.ethernet failed with error -110 > [ 1354.400000] macb: GEM doesn't support hardware ptp. > [ 1354.410000] libphy: MACB_mii_bus: probed > [ 1355.260000] macb 10090000.ethernet (unnamed net_device) (uninitialized): Could not attach to PHY > [ 1355.300000] macb: probe of 10090000.ethernet failed with error -110 > [ 1358.100000] macb: GEM doesn't support hardware ptp. > [ 1358.110000] libphy: MACB_mii_bus: probed > [ 1358.310000] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: attached PHY driver [Microsemi VSC8541 SyncE] (mii_bus:phy_addr=10090000.ethernet-ffffffff:00, irq=POLL) > [ 1358.320000] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 at 0x10090000 irq 12 (70:b3:d5:92:f1:07) > > This is 4.20-rc4 on a HiFive-U. > > Andreas. > Here is my previous analysis on the issue. http://lists.infradead.org/pipermail/linux-riscv/2018-September/001503.html Not sure if you have tried the hack already. But here it is anyways. https://github.com/atishp04/riscv-linux/commit/aa230e7dc2ab01db5b630f427e57297ffc25c884 Regards, Atish ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: macb: probe of 10090000.ethernet failed with error -110 2018-11-28 18:15 ` Atish Patra @ 2018-11-28 18:15 ` Atish Patra 2018-11-28 21:33 ` Florian Fainelli 1 sibling, 0 replies; 18+ messages in thread From: Atish Patra @ 2018-11-28 18:15 UTC (permalink / raw) To: Andreas Schwab, Nicolas Ferre; +Cc: netdev, linux-riscv, linux-kernel On 11/28/18 2:11 AM, Andreas Schwab wrote: > The PHY probing of the macb driver appears to be rather unreliable. > Most of the time it doesn't work the first time, I have to reload the > module several times to let it succeed. > > [ 40.530000] macb: GEM doesn't support hardware ptp. > [ 40.530000] libphy: MACB_mii_bus: probed > [ 41.450000] macb 10090000.ethernet (unnamed net_device) (uninitialized): Could not attach to PHY > [ 41.510000] macb: probe of 10090000.ethernet failed with error -110 > [ 1354.400000] macb: GEM doesn't support hardware ptp. > [ 1354.410000] libphy: MACB_mii_bus: probed > [ 1355.260000] macb 10090000.ethernet (unnamed net_device) (uninitialized): Could not attach to PHY > [ 1355.300000] macb: probe of 10090000.ethernet failed with error -110 > [ 1358.100000] macb: GEM doesn't support hardware ptp. > [ 1358.110000] libphy: MACB_mii_bus: probed > [ 1358.310000] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: attached PHY driver [Microsemi VSC8541 SyncE] (mii_bus:phy_addr=10090000.ethernet-ffffffff:00, irq=POLL) > [ 1358.320000] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 at 0x10090000 irq 12 (70:b3:d5:92:f1:07) > > This is 4.20-rc4 on a HiFive-U. > > Andreas. > Here is my previous analysis on the issue. http://lists.infradead.org/pipermail/linux-riscv/2018-September/001503.html Not sure if you have tried the hack already. But here it is anyways. https://github.com/atishp04/riscv-linux/commit/aa230e7dc2ab01db5b630f427e57297ffc25c884 Regards, Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 18+ messages in thread
* macb: probe of 10090000.ethernet failed with error -110 2018-11-28 18:15 ` Atish Patra 2018-11-28 18:15 ` Atish Patra @ 2018-11-28 21:33 ` Florian Fainelli 2018-11-28 21:33 ` Florian Fainelli 2018-11-29 2:08 ` Palmer Dabbelt 1 sibling, 2 replies; 18+ messages in thread From: Florian Fainelli @ 2018-11-28 21:33 UTC (permalink / raw) To: linux-riscv +Andrew, Heiner, On 11/28/18 10:15 AM, Atish Patra wrote: > On 11/28/18 2:11 AM, Andreas Schwab wrote: >> The PHY probing of the macb driver appears to be rather unreliable. >> Most of the time it doesn't work the first time, I have to reload the >> module several times to let it succeed. >> >> [?? 40.530000] macb: GEM doesn't support hardware ptp. >> [?? 40.530000] libphy: MACB_mii_bus: probed >> [?? 41.450000] macb 10090000.ethernet (unnamed net_device) >> (uninitialized): Could not attach to PHY >> [?? 41.510000] macb: probe of 10090000.ethernet failed with error -110 >> [ 1354.400000] macb: GEM doesn't support hardware ptp. >> [ 1354.410000] libphy: MACB_mii_bus: probed >> [ 1355.260000] macb 10090000.ethernet (unnamed net_device) >> (uninitialized): Could not attach to PHY >> [ 1355.300000] macb: probe of 10090000.ethernet failed with error -110 >> [ 1358.100000] macb: GEM doesn't support hardware ptp. >> [ 1358.110000] libphy: MACB_mii_bus: probed >> [ 1358.310000] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: >> attached PHY driver [Microsemi VSC8541 SyncE] >> (mii_bus:phy_addr=10090000.ethernet-ffffffff:00, irq=POLL) >> [ 1358.320000] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 >> at 0x10090000 irq 12 (70:b3:d5:92:f1:07) >> >> This is 4.20-rc4 on a HiFive-U. >> >> Andreas. >> > > Here is my previous analysis on the issue. > http://lists.infradead.org/pipermail/linux-riscv/2018-September/001503.html > > Not sure if you have tried the hack already. But here it is anyways. > https://github.com/atishp04/riscv-linux/commit/aa230e7dc2ab01db5b630f427e57297ffc25c884 Andrew and I were discussing about this and we would recommend that you localize the workaround within the Vitesse PHY driver and within the driver's probe function. In order to avoid a chicken and egg problem though, you might have to change the PHY's compatible string in the Device Tree to include its PHY OUI, e.g: compatible = "ethernet-phy-1234.5678" which will force the OF layer registering MDIO/PHY devices to probe to the specific driver that matches that PHY. Let us know if this does not work, in which case we might have to introduce another DT property that indicate a "double reset" is required. -- Florian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: macb: probe of 10090000.ethernet failed with error -110 2018-11-28 21:33 ` Florian Fainelli @ 2018-11-28 21:33 ` Florian Fainelli 2018-11-29 2:08 ` Palmer Dabbelt 1 sibling, 0 replies; 18+ messages in thread From: Florian Fainelli @ 2018-11-28 21:33 UTC (permalink / raw) To: Atish Patra, Andreas Schwab, Nicolas Ferre Cc: netdev, linux-riscv, hkallweit1, linux-kernel, Andrew Lunn +Andrew, Heiner, On 11/28/18 10:15 AM, Atish Patra wrote: > On 11/28/18 2:11 AM, Andreas Schwab wrote: >> The PHY probing of the macb driver appears to be rather unreliable. >> Most of the time it doesn't work the first time, I have to reload the >> module several times to let it succeed. >> >> [ 40.530000] macb: GEM doesn't support hardware ptp. >> [ 40.530000] libphy: MACB_mii_bus: probed >> [ 41.450000] macb 10090000.ethernet (unnamed net_device) >> (uninitialized): Could not attach to PHY >> [ 41.510000] macb: probe of 10090000.ethernet failed with error -110 >> [ 1354.400000] macb: GEM doesn't support hardware ptp. >> [ 1354.410000] libphy: MACB_mii_bus: probed >> [ 1355.260000] macb 10090000.ethernet (unnamed net_device) >> (uninitialized): Could not attach to PHY >> [ 1355.300000] macb: probe of 10090000.ethernet failed with error -110 >> [ 1358.100000] macb: GEM doesn't support hardware ptp. >> [ 1358.110000] libphy: MACB_mii_bus: probed >> [ 1358.310000] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: >> attached PHY driver [Microsemi VSC8541 SyncE] >> (mii_bus:phy_addr=10090000.ethernet-ffffffff:00, irq=POLL) >> [ 1358.320000] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 >> at 0x10090000 irq 12 (70:b3:d5:92:f1:07) >> >> This is 4.20-rc4 on a HiFive-U. >> >> Andreas. >> > > Here is my previous analysis on the issue. > http://lists.infradead.org/pipermail/linux-riscv/2018-September/001503.html > > Not sure if you have tried the hack already. But here it is anyways. > https://github.com/atishp04/riscv-linux/commit/aa230e7dc2ab01db5b630f427e57297ffc25c884 Andrew and I were discussing about this and we would recommend that you localize the workaround within the Vitesse PHY driver and within the driver's probe function. In order to avoid a chicken and egg problem though, you might have to change the PHY's compatible string in the Device Tree to include its PHY OUI, e.g: compatible = "ethernet-phy-1234.5678" which will force the OF layer registering MDIO/PHY devices to probe to the specific driver that matches that PHY. Let us know if this does not work, in which case we might have to introduce another DT property that indicate a "double reset" is required. -- Florian _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 18+ messages in thread
* macb: probe of 10090000.ethernet failed with error -110 2018-11-28 21:33 ` Florian Fainelli 2018-11-28 21:33 ` Florian Fainelli @ 2018-11-29 2:08 ` Palmer Dabbelt 2018-11-29 2:08 ` Palmer Dabbelt ` (2 more replies) 1 sibling, 3 replies; 18+ messages in thread From: Palmer Dabbelt @ 2018-11-29 2:08 UTC (permalink / raw) To: linux-riscv On Wed, 28 Nov 2018 13:33:47 PST (-0800), f.fainelli at gmail.com wrote: > +Andrew, Heiner, > > On 11/28/18 10:15 AM, Atish Patra wrote: >> On 11/28/18 2:11 AM, Andreas Schwab wrote: >>> The PHY probing of the macb driver appears to be rather unreliable. >>> Most of the time it doesn't work the first time, I have to reload the >>> module several times to let it succeed. >>> >>> [?? 40.530000] macb: GEM doesn't support hardware ptp. >>> [?? 40.530000] libphy: MACB_mii_bus: probed >>> [?? 41.450000] macb 10090000.ethernet (unnamed net_device) >>> (uninitialized): Could not attach to PHY >>> [?? 41.510000] macb: probe of 10090000.ethernet failed with error -110 >>> [ 1354.400000] macb: GEM doesn't support hardware ptp. >>> [ 1354.410000] libphy: MACB_mii_bus: probed >>> [ 1355.260000] macb 10090000.ethernet (unnamed net_device) >>> (uninitialized): Could not attach to PHY >>> [ 1355.300000] macb: probe of 10090000.ethernet failed with error -110 >>> [ 1358.100000] macb: GEM doesn't support hardware ptp. >>> [ 1358.110000] libphy: MACB_mii_bus: probed >>> [ 1358.310000] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: >>> attached PHY driver [Microsemi VSC8541 SyncE] >>> (mii_bus:phy_addr=10090000.ethernet-ffffffff:00, irq=POLL) >>> [ 1358.320000] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 >>> at 0x10090000 irq 12 (70:b3:d5:92:f1:07) >>> >>> This is 4.20-rc4 on a HiFive-U. >>> >>> Andreas. >>> >> >> Here is my previous analysis on the issue. >> http://lists.infradead.org/pipermail/linux-riscv/2018-September/001503.html >> >> Not sure if you have tried the hack already. But here it is anyways. >> https://github.com/atishp04/riscv-linux/commit/aa230e7dc2ab01db5b630f427e57297ffc25c884 > > Andrew and I were discussing about this and we would recommend that you > localize the workaround within the Vitesse PHY driver and within the > driver's probe function. In order to avoid a chicken and egg problem > though, you might have to change the PHY's compatible string in the > Device Tree to include its PHY OUI, e.g: > > compatible = "ethernet-phy-1234.5678" which will force the OF layer > registering MDIO/PHY devices to probe to the specific driver that > matches that PHY. Let us know if this does not work, in which case we > might have to introduce another DT property that indicate a "double > reset" is required. If I understand what's going on correctly here, any instance of the VSC8541 phy has the unexpected feature where unmanaged mode is entered by following this particular reset sequence. The specific wording from the datasheet is https://www.mouser.com/ds/2/523/Microsemi_VSC8541-01_Datasheet_10496_V40-1148034.pdf 3.18.2 Unmanaged Applications To configure the device using unmanaged mode, perform the following steps: 1. Apply power. 2. Apply RefClk. 3. Release reset, drive high. Power and clock must be high before releasing reset. Note: For unmanaged mode operation, the NRESET pin must have two rising edges (logical 0-1-0-1 transition sequence) applied at this step. 4. Wait 15 ms minimum. 5. (Optional) For applications that gain register access to the device using the management interface, steps 6?10 can then be performed in order to modify default settings. which is where the double reset sequence comes from. For the HiFive Unleashed (a board with this phy) we perform this reset sequence in an early stage of the bootloader knows as the FSBL // VSC8541 PHY reset sequence; leave pull-down active for 2ms nsleep(2000000); // Set GPIO 12 (PHY NRESET) to OE=1 and OVAL=1 atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_VAL), PHY_NRESET); atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_EN), PHY_NRESET); nsleep(100); // Reset PHY again to enter unmanaged mode atomic_fetch_and(&GPIO_REG(GPIO_OUTPUT_VAL), ~PHY_NRESET); nsleep(100); atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_VAL), PHY_NRESET); nsleep(15000000); which you can see here https://github.com/sifive/freedom-u540-c000-bootloader/blob/master/fsbl/main.c#L273 This is all fine as long as Linux doesn't go and reset the phy again. Until bafbdd527d56 ("phylib: Add device reset GPIO support") was the case. After that commit I believe phylib is resetting the phy while attempting to enter unmanaged mode, which is now allowed in this particular chip. Since it appears the phy is not usually described by the device tree but is instead discovered by probing a MII-based ID register, it seems the best place to put this is within the phy driver itself. I find it's usually best to describe things with code, so I hacked up something like diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c index 7cae17517744..8e0a71ee6bab 100644 --- a/drivers/net/phy/mscc.c +++ b/drivers/net/phy/mscc.c @@ -1822,6 +1822,24 @@ static int vsc85xx_probe(struct phy_device *phydev) return vsc85xx_dt_led_modes_get(phydev, default_mode); } +static int vsc8541_reset(struct phy_device *phydev, int value) +{ + WARN_ON(value != 0 || value != 1); + mdio_device_reset(&phydev->mdio, value); + if (value == 1) { + /* The VSC8541 has an unexpected feature where a single reset + * rising edge can only be used to enter managed mode. For + * unmanaged mode a pair of reset rising edges is necessary. + * */ + mdio_device_reset(&phydev_mdio, 0); + mdio_device_reset(&phydev_mdio, 1); + + /* After this pair of reset rising edges we must wait at least + * 15ms before writing any phy registers. */ + msleep(15); + } +} + /* Microsemi VSC85xx PHYs */ static struct phy_driver vsc85xx_driver[] = { { @@ -1927,6 +1945,7 @@ static struct phy_driver vsc85xx_driver[] = { .get_sset_count = &vsc85xx_get_sset_count, .get_strings = &vsc85xx_get_strings, .get_stats = &vsc85xx_get_stats, + .reset = &vsc8541_reset, }, { .phy_id = PHY_ID_VSC8574, diff --git a/include/linux/phy.h b/include/linux/phy.h index 3ea87f774a76..b8962ff409e8 100644 --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -667,6 +667,10 @@ struct phy_driver { struct ethtool_tunable *tuna, const void *data); int (*set_loopback)(struct phy_device *dev, bool enable); + + /* An optional device-specific reset sequence */ + int (*reset)(struct phy_device *dev, + int value); }; #define to_phy_driver(d) container_of(to_mdio_common_driver(d), \ struct phy_driver, mdiodrv) @@ -970,7 +974,10 @@ int phy_reset_after_clk_enable(struct phy_device *phydev); static inline void phy_device_reset(struct phy_device *phydev, int value) { - mdio_device_reset(&phydev->mdio, value); + if (phydev->reset) + phydev->reset(phydev, value); + else + mdio_device_reset(&phydev->mdio, value); } #define phydev_err(_phydev, format, args...) \ Note that I haven't even compiled this, and that msleep() is almost certainly garbage. Am I missing something? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: macb: probe of 10090000.ethernet failed with error -110 2018-11-29 2:08 ` Palmer Dabbelt @ 2018-11-29 2:08 ` Palmer Dabbelt 2018-11-29 2:28 ` Andrew Lunn 2018-11-29 5:55 ` Andrew Lunn 2 siblings, 0 replies; 18+ messages in thread From: Palmer Dabbelt @ 2018-11-29 2:08 UTC (permalink / raw) To: f.fainelli, sergei.shtylyov Cc: andrew, netdev, nicolas.ferre, linux-kernel, atish.patra, schwab, linux-riscv, hkallweit1 On Wed, 28 Nov 2018 13:33:47 PST (-0800), f.fainelli@gmail.com wrote: > +Andrew, Heiner, > > On 11/28/18 10:15 AM, Atish Patra wrote: >> On 11/28/18 2:11 AM, Andreas Schwab wrote: >>> The PHY probing of the macb driver appears to be rather unreliable. >>> Most of the time it doesn't work the first time, I have to reload the >>> module several times to let it succeed. >>> >>> [ 40.530000] macb: GEM doesn't support hardware ptp. >>> [ 40.530000] libphy: MACB_mii_bus: probed >>> [ 41.450000] macb 10090000.ethernet (unnamed net_device) >>> (uninitialized): Could not attach to PHY >>> [ 41.510000] macb: probe of 10090000.ethernet failed with error -110 >>> [ 1354.400000] macb: GEM doesn't support hardware ptp. >>> [ 1354.410000] libphy: MACB_mii_bus: probed >>> [ 1355.260000] macb 10090000.ethernet (unnamed net_device) >>> (uninitialized): Could not attach to PHY >>> [ 1355.300000] macb: probe of 10090000.ethernet failed with error -110 >>> [ 1358.100000] macb: GEM doesn't support hardware ptp. >>> [ 1358.110000] libphy: MACB_mii_bus: probed >>> [ 1358.310000] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: >>> attached PHY driver [Microsemi VSC8541 SyncE] >>> (mii_bus:phy_addr=10090000.ethernet-ffffffff:00, irq=POLL) >>> [ 1358.320000] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 >>> at 0x10090000 irq 12 (70:b3:d5:92:f1:07) >>> >>> This is 4.20-rc4 on a HiFive-U. >>> >>> Andreas. >>> >> >> Here is my previous analysis on the issue. >> http://lists.infradead.org/pipermail/linux-riscv/2018-September/001503.html >> >> Not sure if you have tried the hack already. But here it is anyways. >> https://github.com/atishp04/riscv-linux/commit/aa230e7dc2ab01db5b630f427e57297ffc25c884 > > Andrew and I were discussing about this and we would recommend that you > localize the workaround within the Vitesse PHY driver and within the > driver's probe function. In order to avoid a chicken and egg problem > though, you might have to change the PHY's compatible string in the > Device Tree to include its PHY OUI, e.g: > > compatible = "ethernet-phy-1234.5678" which will force the OF layer > registering MDIO/PHY devices to probe to the specific driver that > matches that PHY. Let us know if this does not work, in which case we > might have to introduce another DT property that indicate a "double > reset" is required. If I understand what's going on correctly here, any instance of the VSC8541 phy has the unexpected feature where unmanaged mode is entered by following this particular reset sequence. The specific wording from the datasheet is https://www.mouser.com/ds/2/523/Microsemi_VSC8541-01_Datasheet_10496_V40-1148034.pdf 3.18.2 Unmanaged Applications To configure the device using unmanaged mode, perform the following steps: 1. Apply power. 2. Apply RefClk. 3. Release reset, drive high. Power and clock must be high before releasing reset. Note: For unmanaged mode operation, the NRESET pin must have two rising edges (logical 0-1-0-1 transition sequence) applied at this step. 4. Wait 15 ms minimum. 5. (Optional) For applications that gain register access to the device using the management interface, steps 6–10 can then be performed in order to modify default settings. which is where the double reset sequence comes from. For the HiFive Unleashed (a board with this phy) we perform this reset sequence in an early stage of the bootloader knows as the FSBL // VSC8541 PHY reset sequence; leave pull-down active for 2ms nsleep(2000000); // Set GPIO 12 (PHY NRESET) to OE=1 and OVAL=1 atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_VAL), PHY_NRESET); atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_EN), PHY_NRESET); nsleep(100); // Reset PHY again to enter unmanaged mode atomic_fetch_and(&GPIO_REG(GPIO_OUTPUT_VAL), ~PHY_NRESET); nsleep(100); atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_VAL), PHY_NRESET); nsleep(15000000); which you can see here https://github.com/sifive/freedom-u540-c000-bootloader/blob/master/fsbl/main.c#L273 This is all fine as long as Linux doesn't go and reset the phy again. Until bafbdd527d56 ("phylib: Add device reset GPIO support") was the case. After that commit I believe phylib is resetting the phy while attempting to enter unmanaged mode, which is now allowed in this particular chip. Since it appears the phy is not usually described by the device tree but is instead discovered by probing a MII-based ID register, it seems the best place to put this is within the phy driver itself. I find it's usually best to describe things with code, so I hacked up something like diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c index 7cae17517744..8e0a71ee6bab 100644 --- a/drivers/net/phy/mscc.c +++ b/drivers/net/phy/mscc.c @@ -1822,6 +1822,24 @@ static int vsc85xx_probe(struct phy_device *phydev) return vsc85xx_dt_led_modes_get(phydev, default_mode); } +static int vsc8541_reset(struct phy_device *phydev, int value) +{ + WARN_ON(value != 0 || value != 1); + mdio_device_reset(&phydev->mdio, value); + if (value == 1) { + /* The VSC8541 has an unexpected feature where a single reset + * rising edge can only be used to enter managed mode. For + * unmanaged mode a pair of reset rising edges is necessary. + * */ + mdio_device_reset(&phydev_mdio, 0); + mdio_device_reset(&phydev_mdio, 1); + + /* After this pair of reset rising edges we must wait at least + * 15ms before writing any phy registers. */ + msleep(15); + } +} + /* Microsemi VSC85xx PHYs */ static struct phy_driver vsc85xx_driver[] = { { @@ -1927,6 +1945,7 @@ static struct phy_driver vsc85xx_driver[] = { .get_sset_count = &vsc85xx_get_sset_count, .get_strings = &vsc85xx_get_strings, .get_stats = &vsc85xx_get_stats, + .reset = &vsc8541_reset, }, { .phy_id = PHY_ID_VSC8574, diff --git a/include/linux/phy.h b/include/linux/phy.h index 3ea87f774a76..b8962ff409e8 100644 --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -667,6 +667,10 @@ struct phy_driver { struct ethtool_tunable *tuna, const void *data); int (*set_loopback)(struct phy_device *dev, bool enable); + + /* An optional device-specific reset sequence */ + int (*reset)(struct phy_device *dev, + int value); }; #define to_phy_driver(d) container_of(to_mdio_common_driver(d), \ struct phy_driver, mdiodrv) @@ -970,7 +974,10 @@ int phy_reset_after_clk_enable(struct phy_device *phydev); static inline void phy_device_reset(struct phy_device *phydev, int value) { - mdio_device_reset(&phydev->mdio, value); + if (phydev->reset) + phydev->reset(phydev, value); + else + mdio_device_reset(&phydev->mdio, value); } #define phydev_err(_phydev, format, args...) \ Note that I haven't even compiled this, and that msleep() is almost certainly garbage. Am I missing something? _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 18+ messages in thread
* macb: probe of 10090000.ethernet failed with error -110 2018-11-29 2:08 ` Palmer Dabbelt 2018-11-29 2:08 ` Palmer Dabbelt @ 2018-11-29 2:28 ` Andrew Lunn 2018-11-29 2:28 ` Andrew Lunn 2018-11-29 3:01 ` Palmer Dabbelt 2018-11-29 5:55 ` Andrew Lunn 2 siblings, 2 replies; 18+ messages in thread From: Andrew Lunn @ 2018-11-29 2:28 UTC (permalink / raw) To: linux-riscv > This is all fine as long as Linux doesn't go and reset the phy again. Until > bafbdd527d56 ("phylib: Add device reset GPIO support") was the case. After > that commit I believe phylib is resetting the phy while attempting to enter > unmanaged mode, which is now allowed in this particular chip. > > Since it appears the phy is not usually described by the device tree but is > instead discovered by probing a MII-based ID register, it seems the best > place to put this is within the phy driver itself. I find it's usually best > to describe things with code, so I hacked up something like Talking to Florian, i was under the impression that you could not even discover the device when its reset state what wrong. You could not read the ID registers. Your suggested change assumed you can discover the device. Is this true? Thanks Andrew ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: macb: probe of 10090000.ethernet failed with error -110 2018-11-29 2:28 ` Andrew Lunn @ 2018-11-29 2:28 ` Andrew Lunn 2018-11-29 3:01 ` Palmer Dabbelt 1 sibling, 0 replies; 18+ messages in thread From: Andrew Lunn @ 2018-11-29 2:28 UTC (permalink / raw) To: Palmer Dabbelt Cc: f.fainelli, sergei.shtylyov, netdev, nicolas.ferre, linux-kernel, atish.patra, schwab, linux-riscv, hkallweit1 > This is all fine as long as Linux doesn't go and reset the phy again. Until > bafbdd527d56 ("phylib: Add device reset GPIO support") was the case. After > that commit I believe phylib is resetting the phy while attempting to enter > unmanaged mode, which is now allowed in this particular chip. > > Since it appears the phy is not usually described by the device tree but is > instead discovered by probing a MII-based ID register, it seems the best > place to put this is within the phy driver itself. I find it's usually best > to describe things with code, so I hacked up something like Talking to Florian, i was under the impression that you could not even discover the device when its reset state what wrong. You could not read the ID registers. Your suggested change assumed you can discover the device. Is this true? Thanks Andrew _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 18+ messages in thread
* macb: probe of 10090000.ethernet failed with error -110 2018-11-29 2:28 ` Andrew Lunn 2018-11-29 2:28 ` Andrew Lunn @ 2018-11-29 3:01 ` Palmer Dabbelt 2018-11-29 3:01 ` Palmer Dabbelt 1 sibling, 1 reply; 18+ messages in thread From: Palmer Dabbelt @ 2018-11-29 3:01 UTC (permalink / raw) To: linux-riscv On Wed, 28 Nov 2018 18:28:58 PST (-0800), andrew at lunn.ch wrote: >> This is all fine as long as Linux doesn't go and reset the phy again. Until >> bafbdd527d56 ("phylib: Add device reset GPIO support") was the case. After >> that commit I believe phylib is resetting the phy while attempting to enter >> unmanaged mode, which is now allowed in this particular chip. >> >> Since it appears the phy is not usually described by the device tree but is >> instead discovered by probing a MII-based ID register, it seems the best >> place to put this is within the phy driver itself. I find it's usually best >> to describe things with code, so I hacked up something like > > Talking to Florian, i was under the impression that you could not even > discover the device when its reset state what wrong. You could not > read the ID registers. > > Your suggested change assumed you can discover the device. Is this > true? Sorry, I can't tell that from reading the code. Since our bootloader resets the phy into unmanaged mode I think that just deasserting reset should be OK, but I don't have much confidence in that -- once I run into one unexpected feature I start to expect more :) It looks like there's already an expectation that at least the phy ID registers can be read between falling and rising edges of a reset, as that's how the fixups are handled. Since the error message that shows up with a single (single as far as Linux is concerned, triple since a cold boot) reset rising edge still lists the phy by name I think that probing is working well enough, but I wouldn't be surprised if there's something in the middle that's gone wrong. It's possible registering a fixup that does the double reset can get us through the probing sequence. Maybe Atish or Paul can help out? I'm a bit embarrassed to admit that I can't actually figure out how to boot the board any more, it's been a year since it's been my primary target and since I just to arch/riscv stuff now I rely them to test on the board... ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: macb: probe of 10090000.ethernet failed with error -110 2018-11-29 3:01 ` Palmer Dabbelt @ 2018-11-29 3:01 ` Palmer Dabbelt 0 siblings, 0 replies; 18+ messages in thread From: Palmer Dabbelt @ 2018-11-29 3:01 UTC (permalink / raw) To: andrew, Atish Patra, Paul Walmsley Cc: f.fainelli, sergei.shtylyov, netdev, nicolas.ferre, linux-kernel, atish.patra, schwab, linux-riscv, hkallweit1 On Wed, 28 Nov 2018 18:28:58 PST (-0800), andrew@lunn.ch wrote: >> This is all fine as long as Linux doesn't go and reset the phy again. Until >> bafbdd527d56 ("phylib: Add device reset GPIO support") was the case. After >> that commit I believe phylib is resetting the phy while attempting to enter >> unmanaged mode, which is now allowed in this particular chip. >> >> Since it appears the phy is not usually described by the device tree but is >> instead discovered by probing a MII-based ID register, it seems the best >> place to put this is within the phy driver itself. I find it's usually best >> to describe things with code, so I hacked up something like > > Talking to Florian, i was under the impression that you could not even > discover the device when its reset state what wrong. You could not > read the ID registers. > > Your suggested change assumed you can discover the device. Is this > true? Sorry, I can't tell that from reading the code. Since our bootloader resets the phy into unmanaged mode I think that just deasserting reset should be OK, but I don't have much confidence in that -- once I run into one unexpected feature I start to expect more :) It looks like there's already an expectation that at least the phy ID registers can be read between falling and rising edges of a reset, as that's how the fixups are handled. Since the error message that shows up with a single (single as far as Linux is concerned, triple since a cold boot) reset rising edge still lists the phy by name I think that probing is working well enough, but I wouldn't be surprised if there's something in the middle that's gone wrong. It's possible registering a fixup that does the double reset can get us through the probing sequence. Maybe Atish or Paul can help out? I'm a bit embarrassed to admit that I can't actually figure out how to boot the board any more, it's been a year since it's been my primary target and since I just to arch/riscv stuff now I rely them to test on the board... _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 18+ messages in thread
* macb: probe of 10090000.ethernet failed with error -110 2018-11-29 2:08 ` Palmer Dabbelt 2018-11-29 2:08 ` Palmer Dabbelt 2018-11-29 2:28 ` Andrew Lunn @ 2018-11-29 5:55 ` Andrew Lunn 2018-11-29 5:55 ` Andrew Lunn 2018-11-29 11:55 ` Andreas Schwab 2 siblings, 2 replies; 18+ messages in thread From: Andrew Lunn @ 2018-11-29 5:55 UTC (permalink / raw) To: linux-riscv > diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c > index 7cae17517744..8e0a71ee6bab 100644 > --- a/drivers/net/phy/mscc.c > +++ b/drivers/net/phy/mscc.c > @@ -1822,6 +1822,24 @@ static int vsc85xx_probe(struct phy_device *phydev) > return vsc85xx_dt_led_modes_get(phydev, default_mode); > } > +static int vsc8541_reset(struct phy_device *phydev, int value) > +{ > + WARN_ON(value != 0 || value != 1); > + mdio_device_reset(&phydev->mdio, value); > + if (value == 1) { > + /* The VSC8541 has an unexpected feature where a single reset > + * rising edge can only be used to enter managed mode. For > + * unmanaged mode a pair of reset rising edges is necessary. > + * */ > + mdio_device_reset(&phydev_mdio, 0); > + mdio_device_reset(&phydev_mdio, 1); > + > + /* After this pair of reset rising edges we must wait at least > + * 15ms before writing any phy registers. */ > + msleep(15); > + } > +} > + > /* Microsemi VSC85xx PHYs */ > static struct phy_driver vsc85xx_driver[] = { > { > @@ -1927,6 +1945,7 @@ static struct phy_driver vsc85xx_driver[] = { > .get_sset_count = &vsc85xx_get_sset_count, > .get_strings = &vsc85xx_get_strings, > .get_stats = &vsc85xx_get_stats, > + .reset = &vsc8541_reset, So if we assume you can identify the PHY using its ID registers, you can put this reset code into the soft_reset call. That gets called first before anything else. There is no need to add a new function to phy_driver. Andrew ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: macb: probe of 10090000.ethernet failed with error -110 2018-11-29 5:55 ` Andrew Lunn @ 2018-11-29 5:55 ` Andrew Lunn 2018-11-29 11:55 ` Andreas Schwab 1 sibling, 0 replies; 18+ messages in thread From: Andrew Lunn @ 2018-11-29 5:55 UTC (permalink / raw) To: Palmer Dabbelt Cc: f.fainelli, sergei.shtylyov, netdev, nicolas.ferre, linux-kernel, atish.patra, schwab, linux-riscv, hkallweit1 > diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c > index 7cae17517744..8e0a71ee6bab 100644 > --- a/drivers/net/phy/mscc.c > +++ b/drivers/net/phy/mscc.c > @@ -1822,6 +1822,24 @@ static int vsc85xx_probe(struct phy_device *phydev) > return vsc85xx_dt_led_modes_get(phydev, default_mode); > } > +static int vsc8541_reset(struct phy_device *phydev, int value) > +{ > + WARN_ON(value != 0 || value != 1); > + mdio_device_reset(&phydev->mdio, value); > + if (value == 1) { > + /* The VSC8541 has an unexpected feature where a single reset > + * rising edge can only be used to enter managed mode. For > + * unmanaged mode a pair of reset rising edges is necessary. > + * */ > + mdio_device_reset(&phydev_mdio, 0); > + mdio_device_reset(&phydev_mdio, 1); > + > + /* After this pair of reset rising edges we must wait at least > + * 15ms before writing any phy registers. */ > + msleep(15); > + } > +} > + > /* Microsemi VSC85xx PHYs */ > static struct phy_driver vsc85xx_driver[] = { > { > @@ -1927,6 +1945,7 @@ static struct phy_driver vsc85xx_driver[] = { > .get_sset_count = &vsc85xx_get_sset_count, > .get_strings = &vsc85xx_get_strings, > .get_stats = &vsc85xx_get_stats, > + .reset = &vsc8541_reset, So if we assume you can identify the PHY using its ID registers, you can put this reset code into the soft_reset call. That gets called first before anything else. There is no need to add a new function to phy_driver. Andrew _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: macb: probe of 10090000.ethernet failed with error -110 2018-11-29 5:55 ` Andrew Lunn 2018-11-29 5:55 ` Andrew Lunn @ 2018-11-29 11:55 ` Andreas Schwab 1 sibling, 0 replies; 18+ messages in thread From: Andreas Schwab @ 2018-11-29 11:55 UTC (permalink / raw) To: Andrew Lunn Cc: f.fainelli, sergei.shtylyov, netdev, Palmer Dabbelt, nicolas.ferre, linux-kernel, atish.patra, linux-riscv, hkallweit1 On Nov 29 2018, Andrew Lunn <andrew@lunn.ch> wrote: > So if we assume you can identify the PHY using its ID registers, you > can put this reset code into the soft_reset call. That gets called > first before anything else. There is no need to add a new function to > phy_driver. I've tried the following, but it made things only worse, with the probing not working at all. Andreas. diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c index 7cae175177..65baf31331 100644 --- a/drivers/net/phy/mscc.c +++ b/drivers/net/phy/mscc.c @@ -1822,6 +1822,23 @@ static int vsc85xx_probe(struct phy_device *phydev) return vsc85xx_dt_led_modes_get(phydev, default_mode); } +static int vsc8541_soft_reset(struct phy_device *phydev) +{ + /* The VSC8541 has an unexpected feature where a single reset + * rising edge can only be used to enter managed mode. For + * unmanaged mode a pair of reset rising edges is necessary. + */ + mdio_device_reset(&phydev->mdio, 0); + mdio_device_reset(&phydev->mdio, 1); + + /* After this pair of reset rising edges we must wait at least + * 15ms before writing any phy registers. + */ + msleep(15); + + return genphy_soft_reset(phydev); +} + /* Microsemi VSC85xx PHYs */ static struct phy_driver vsc85xx_driver[] = { { @@ -1908,7 +1925,7 @@ static struct phy_driver vsc85xx_driver[] = { .phy_id_mask = 0xfffffff0, .features = PHY_GBIT_FEATURES, .flags = PHY_HAS_INTERRUPT, - .soft_reset = &genphy_soft_reset, + .soft_reset = &vsc8541_soft_reset, .config_init = &vsc85xx_config_init, .config_aneg = &vsc85xx_config_aneg, .aneg_done = &genphy_aneg_done, -- 2.19.2 -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-04-10 9:50 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-24 17:18 macb: probe of 10090000.ethernet failed with error -110 Atish Patra 2018-09-15 0:07 ` Atish Patra 2019-04-10 9:50 ` Andreas Schwab 2018-11-28 10:10 Andreas Schwab 2018-11-28 10:10 ` Andreas Schwab 2018-11-28 18:15 ` Atish Patra 2018-11-28 18:15 ` Atish Patra 2018-11-28 21:33 ` Florian Fainelli 2018-11-28 21:33 ` Florian Fainelli 2018-11-29 2:08 ` Palmer Dabbelt 2018-11-29 2:08 ` Palmer Dabbelt 2018-11-29 2:28 ` Andrew Lunn 2018-11-29 2:28 ` Andrew Lunn 2018-11-29 3:01 ` Palmer Dabbelt 2018-11-29 3:01 ` Palmer Dabbelt 2018-11-29 5:55 ` Andrew Lunn 2018-11-29 5:55 ` Andrew Lunn 2018-11-29 11:55 ` Andreas Schwab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).