On 07.04.2021 03:43, Joakim Zhang wrote:
>
> Hi Heiner,
>
>> -----Original Message-----
>> From: Heiner Kallweit <hkallwe...@gmail.com>
>> Sent: 2021年4月7日 2:22
>> To: Joakim Zhang <qiangqing.zh...@nxp.com>; christian.me...@t2data.com;
>> and...@lunn.ch; li...@armlinux.org.uk; da...@davemloft.net;
>> k...@kernel.org; Russell King - ARM Linux <li...@armlinux.org.uk>
>> Cc: netdev@vger.kernel.org; linux-ker...@vger.kernel.org; dl-linux-imx
>> <linux-...@nxp.com>; Florian Fainelli <f.faine...@gmail.com>
>> Subject: Re: [PATCH] net: phy: fix PHY possibly unwork after MDIO bus resume
>> back
>>
>> On 06.04.2021 13:42, Heiner Kallweit wrote:
>>> On 06.04.2021 12:07, Joakim Zhang wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Heiner Kallweit <hkallwe...@gmail.com>
>>>>> Sent: 2021年4月6日 14:29
>>>>> To: Joakim Zhang <qiangqing.zh...@nxp.com>;
>>>>> christian.me...@t2data.com; and...@lunn.ch; li...@armlinux.org.uk;
>>>>> da...@davemloft.net; k...@kernel.org
>>>>> Cc: netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
>>>>> dl-linux-imx <linux-...@nxp.com>
>>>>> Subject: Re: [PATCH] net: phy: fix PHY possibly unwork after MDIO
>>>>> bus resume back
>>>>>
>>>>> On 06.04.2021 04:07, Joakim Zhang wrote:
>>>>>>
>>>>>> Hi Heiner,
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Heiner Kallweit <hkallwe...@gmail.com>
>>>>>>> Sent: 2021年4月5日 20:10
>>>>>>> To: christian.me...@t2data.com; Joakim Zhang
>>>>>>> <qiangqing.zh...@nxp.com>; and...@lunn.ch; li...@armlinux.org.uk;
>>>>>>> da...@davemloft.net; k...@kernel.org
>>>>>>> Cc: netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
>>>>>>> dl-linux-imx <linux-...@nxp.com>
>>>>>>> Subject: Re: [PATCH] net: phy: fix PHY possibly unwork after MDIO
>>>>>>> bus resume back
>>>>>>>
>>>>>>> On 05.04.2021 10:43, Christian Melki wrote:
>>>>>>>> On 4/5/21 12:48 AM, Heiner Kallweit wrote:
>>>>>>>>> On 04.04.2021 16:09, Heiner Kallweit wrote:
>>>>>>>>>> On 04.04.2021 12:07, Joakim Zhang wrote:
>>>>>>>>>>> commit 4c0d2e96ba055 ("net: phy: consider that suspend2ram
>> may
>>>>>>>>>>> cut off PHY power") invokes phy_init_hw() when MDIO bus
>>>>>>>>>>> resume, it will soft reset PHY if PHY driver implements soft_reset
>> callback.
>>>>>>>>>>> commit 764d31cacfe4 ("net: phy: micrel: set soft_reset
>>>>>>>>>>> callback to genphy_soft_reset for KSZ8081") adds soft_reset for
>> KSZ8081.
>>>>>>>>>>> After these two patches, I found i.MX6UL 14x14 EVK which
>>>>>>>>>>> connected to KSZ8081RNB doesn't work any more when system
>>>>> resume
>>>>>>>>>>> back, MAC
>>>>>>> driver is fec_main.c.
>>>>>>>>>>>
>>>>>>>>>>> It's obvious that initializing PHY hardware when MDIO bus
>>>>>>>>>>> resume back would introduce some regression when PHY
>>>>>>>>>>> implements soft_reset. When I
>>>>>>>>>>
>>>>>>>>>> Why is this obvious? Please elaborate on why a soft reset
>>>>>>>>>> should break something.
>>>>>>>>>>
>>>>>>>>>>> am debugging, I found PHY works fine if MAC doesn't support
>>>>>>>>>>> suspend/resume or phy_stop()/phy_start() doesn't been called
>>>>>>>>>>> during suspend/resume. This let me realize, PHY state machine
>>>>>>>>>>> phy_state_machine() could do something breaks the PHY.
>>>>>>>>>>>
>>>>>>>>>>> As we known, MAC resume first and then MDIO bus resume when
>>>>>>>>>>> system resume back from suspend. When MAC resume, usually it
>>>>>>>>>>> will invoke
>>>>>>>>>>> phy_start() where to change PHY state to PHY_UP, then trigger
>>>>>>>>>>> the
>>>>>>>>>>> stat> machine to run now. In phy_state_machine(), it will
>>>>>>>>>>> start/config auto-nego, then change PHY state to PHY_NOLINK,
>>>>>>>>>>> what to next is periodically check PHY link status. When MDIO
>>>>>>>>>>> bus resume, it will initialize PHY hardware, including
>>>>>>>>>>> soft_reset, what would soft_reset affect seems various from
>> different PHYs.
>>>>>>>>>>> For KSZ8081RNB, when it in PHY_NOLINK state and then perform a
>>>>>>>>>>> soft reset,
>>>>>>> it will never complete auto-nego.
>>>>>>>>>>
>>>>>>>>>> Why? That would need to be checked in detail. Maybe chip errata
>>>>>>>>>> documentation provides a hint.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The KSZ8081 spec says the following about bit BMCR_PDOWN:
>>>>>>>>>
>>>>>>>>> If software reset (Register 0.15) is used to exit power-down
>>>>>>>>> mode (Register 0.11 = 1), two software reset writes (Register
>>>>>>>>> 0.15 = 1) are required. The first write clears power-down mode;
>>>>>>>>> the second write resets the chip and re-latches the pin strapping pin
>> values.
>>>>>>>>>
>>>>>>>>> Maybe this causes the issue you see and genphy_soft_reset()
>>>>>>>>> isn't appropriate for this PHY. Please re-test with the KSZ8081
>>>>>>>>> soft reset following the spec comment.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Interesting. Never expected that behavior.
>>>>>>>> Thanks for catching it. Skimmed through the datasheets/erratas.
>>>>>>>> This is what I found (micrel.c):
>>>>>>>>
>>>>>>>> 10/100:
>>>>>>>> 8001 - Unaffected?
>>>>>>>> 8021/8031 - Double reset after PDOWN.
>>>>>>>> 8041 - Errata. PDOWN broken. Recommended do not use. Unclear if
>>>>>>>> reset solves the issue since errata says no error after reset but
>>>>>>>> is also claiming that only toggling PDOWN (may) or power will help.
>>>>>>>> 8051 - Double reset after PDOWN.
>>>>>>>> 8061 - Double reset after PDOWN.
>>>>>>>> 8081 - Double reset after PDOWN.
>>>>>>>> 8091 - Double reset after PDOWN.
>>>>>>>>
>>>>>>>> 10/100/1000:
>>>>>>>> Nothing in gigabit afaics.
>>>>>>>>
>>>>>>>> Switches:
>>>>>>>> 8862 - Not affected?
>>>>>>>> 8863 - Errata. PDOWN broken. Reset will not help. Workaround exists.
>>>>>>>> 8864 - Not affected?
>>>>>>>> 8873 - Errata. PDOWN broken. Reset will not help. Workaround exists.
>>>>>>>> 9477 - Errata. PDOWN broken. Will randomly cause link failure on
>>>>>>>> adjacent links. Do not use.
>>>>>>>>
>>>>>>>> This certainly explains a lot.
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This patch changes PHY state to PHY_UP when MDIO bus resume
>>>>>>>>>>> back, it should be reasonable after PHY hardware
>>>>>>>>>>> re-initialized. Also give state machine a chance to start/config
>> auto-nego again.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If the MAC driver calls phy_stop() on suspend, then
>>>>>>>>>> phydev->suspended is true and mdio_bus_phy_may_suspend()
>>>>>>>>>> phydev->returns
>>>>>>>>>> false. As a consequence
>>>>>>>>>> phydev->suspended_by_mdio_bus is false and
>>>>>>>>>> phydev->mdio_bus_phy_resume()
>>>>>>>>>> skips the PHY hw initialization.
>>>>>>>>>> Please also note that mdio_bus_phy_suspend() calls
>>>>>>>>>> phy_stop_machine() that sets the state to PHY_UP.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Forgot that MDIO bus suspend is done before MAC driver suspend.
>>>>>>>>> Therefore disregard this part for now.
>>>>>>>>>
>>>>>>>>>> Having said that the current argumentation isn't convincing.
>>>>>>>>>> I'm not aware of such issues on other systems, therefore it's
>>>>>>>>>> likely that something is system-dependent.
>>>>>>>>>>
>>>>>>>>>> Please check the exact call sequence on your system, maybe it
>>>>>>>>>> provides a hint.
>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Joakim Zhang <qiangqing.zh...@nxp.com>
>>>>>>>>>>> ---
>>>>>>>>>>> drivers/net/phy/phy_device.c | 7 +++++++
>>>>>>>>>>> 1 file changed, 7 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/net/phy/phy_device.c
>>>>>>>>>>> b/drivers/net/phy/phy_device.c index
>>>>>>>>>>> cc38e326405a..312a6f662481
>>>>>>>>>>> 100644
>>>>>>>>>>> --- a/drivers/net/phy/phy_device.c
>>>>>>>>>>> +++ b/drivers/net/phy/phy_device.c
>>>>>>>>>>> @@ -306,6 +306,13 @@ static __maybe_unused int
>>>>>>> mdio_bus_phy_resume(struct device *dev)
>>>>>>>>>>> ret = phy_resume(phydev);
>>>>>>>>>>> if (ret < 0)
>>>>>>>>>>> return ret;
>>>>>>>>>>> +
>>>>>>>>>>> + /* PHY state could be changed to PHY_NOLINK from MAC
>>>>>>>>>>> +controller
>>>>>>> resume
>>>>>>>>>>> + * rounte with phy_start(), here change to PHY_UP after
>>>>>>> re-initializing
>>>>>>>>>>> + * PHY hardware, let PHY state machine to start/config
>>>>>>>>>>> +auto-nego
>>>>>>> again.
>>>>>>>>>>> + */
>>>>>>>>>>> + phydev->state = PHY_UP;
>>>>>>>>>>> +
>>>>>>>>>>> no_resume:
>>>>>>>>>>> if (phydev->attached_dev && phydev->adjust_link)
>>>>>>>>>>> phy_start_machine(phydev);
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> This is a quick draft of the modified soft reset for KSZ8081.
>>>>>>> Some tests would be appreciated.
>>>>>>>
>>>>>>
>>>>>> I test this patch at my side, unfortunately, it still can't work.
>>>>>>
>>>>>> I have not found what soft reset would affect in 8081 spec, is
>>>>>> there ang common Description for different PHYs?
>>>>>>
>>>>>
>>>>> You can check the clause 22 spec: 802.3 22.2.4.1.1
>>>>>
>>>>> Apart from that you can check BMCR value and which modes your PHY
>>>>> advertises after a soft reset. If the PHY indeed wouldn't restart
>>>>> aneg after a soft reset, then it would be the only one with this
>>>>> behavior I know. And I'd wonder why there aren't more such reports.
>>>>
>>>> Hi Heiner,
>>>>
>>>> We have reasons to believe it is a weird behavior of KSZ8081. I have
>>>> another two PHYs at my side, AR8031 and RTL8211FD, they can work fine if
>> soft_reset implemented.
>>>>
>>>> As commit message described, phy_start() would change PHY state to
>> PHY_UP finally to PHY_NOLINK when MAC resume.
>>>> After MDIO bus resume back, it will periodically check link status. I did
>>>> below
>> code change to dump all PHY registers.
>>>>
>>>> --- a/drivers/net/phy/phy.c
>>>> +++ b/drivers/net/phy/phy.c
>>>> @@ -35,7 +35,7 @@
>>>> #include <net/genetlink.h>
>>>> #include <net/sock.h>
>>>>
>>>> -#define PHY_STATE_TIME HZ
>>>> +#define PHY_STATE_TIME (10 * HZ)
>>>>
>>>> #define PHY_STATE_STR(_state) \
>>>> case PHY_##_state: \
>>>> @@ -738,6 +738,28 @@ static int phy_check_link_status(struct phy_device
>> *phydev)
>>>> if (err)
>>>> return err;
>>>>
>>>> + printk("offset 0x00 data = %0x\n", phy_read(phydev, 0x00));
>>>> + printk("offset 0x01 data = %0x\n", phy_read(phydev, 0x01));
>>>> + printk("offset 0x02 data = %0x\n", phy_read(phydev, 0x02));
>>>> + printk("offset 0x03 data = %0x\n", phy_read(phydev, 0x03));
>>>> + printk("offset 0x04 data = %0x\n", phy_read(phydev, 0x04));
>>>> + printk("offset 0x05 data = %0x\n", phy_read(phydev, 0x05));
>>>> + printk("offset 0x06 data = %0x\n", phy_read(phydev, 0x06));
>>>> + printk("offset 0x07 data = %0x\n", phy_read(phydev, 0x07));
>>>> + printk("offset 0x08 data = %0x\n", phy_read(phydev, 0x08));
>>>> + printk("offset 0x09 data = %0x\n", phy_read(phydev, 0x09));
>>>> + printk("offset 0x10 data = %0x\n", phy_read(phydev, 0x10));
>>>> + printk("offset 0x11 data = %0x\n", phy_read(phydev, 0x11));
>>>> + printk("offset 0x15 data = %0x\n", phy_read(phydev, 0x15));
>>>> + printk("offset 0x16 data = %0x\n", phy_read(phydev, 0x16));
>>>> + printk("offset 0x17 data = %0x\n", phy_read(phydev, 0x17));
>>>> + printk("offset 0x18 data = %0x\n", phy_read(phydev, 0x18));
>>>> + printk("offset 0x1b data = %0x\n", phy_read(phydev, 0x1b));
>>>> + printk("offset 0x1c data = %0x\n", phy_read(phydev, 0x1c));
>>>> + printk("offset 0x1d data = %0x\n", phy_read(phydev, 0x1d));
>>>> + printk("offset 0x1e data = %0x\n", phy_read(phydev, 0x1e));
>>>> + printk("offset 0x1f data = %0x\n", phy_read(phydev, 0x1f));
>>>> + printk("\n\n");
>>>> if (phydev->link && phydev->state != PHY_RUNNING) {
>>>> phy_check_downshift(phydev);
>>>> phydev->state = PHY_RUNNING;
>>>>
>>>> After MDIO bus resume back, results as below:
>>>>
>>>> [ 119.545383] offset 0x00 data = 1100 [ 119.549237] offset 0x01
>>>> data = 7849 [ 119.563125] offset 0x02 data = 22 [ 119.566810]
>>>> offset 0x03 data = 1560 [ 119.570597] offset 0x04 data = 85e1 [
>>>> 119.588016] offset 0x05 data = 0 [ 119.592891] offset 0x06 data = 4
>>>> [ 119.596452] offset 0x07 data = 2001 [ 119.600233] offset 0x08
>>>> data = 0 [ 119.617864] offset 0x09 data = 0 [ 119.625990] offset
>>>> 0x10 data = 0 [ 119.629576] offset 0x11 data = 0 [ 119.642735]
>>>> offset 0x15 data = 0 [ 119.646332] offset 0x16 data = 202 [
>>>> 119.650030] offset 0x17 data = 5c02 [ 119.668054] offset 0x18 data =
>>>> 801 [ 119.672997] offset 0x1b data = 0 [ 119.676565] offset 0x1c
>>>> data = 0 [ 119.680084] offset 0x1d data = 0 [ 119.698031] offset
>>>> 0x1e data = 20 [ 119.706246] offset 0x1f data = 8190 [ 119.709984]
>>>> [ 119.709984] [ 120.182120] offset 0x00 data = 100 [ 120.185894]
>>>> offset 0x01 data = 784d [ 120.189681] offset 0x02 data = 22 [
>>>> 120.206319] offset 0x03 data = 1560 [ 120.210171] offset 0x04 data =
>>>> 8061 [ 120.225353] offset 0x05 data = 0 [ 120.228948] offset 0x06
>>>> data = 4 [ 120.242936] offset 0x07 data = 2001 [ 120.246792] offset
>>>> 0x08 data = 0 [ 120.250313] offset 0x09 data = 0 [ 120.266748]
>>>> offset 0x10 data = 0 [ 120.270335] offset 0x11 data = 0 [
>>>> 120.284167] offset 0x15 data = 0 [ 120.287760] offset 0x16 data =
>>>> 202 [ 120.301031] offset 0x17 data = 3c02 [ 120.313209] offset 0x18
>>>> data = 801 [ 120.316983] offset 0x1b data = 0 [ 120.320513] offset
>>>> 0x1c data = 1 [ 120.336589] offset 0x1d data = 0 [ 120.340184]
>>>> offset 0x1e data = 115 [ 120.355357] offset 0x1f data = 8190 [
>>>> 120.359112] [ 120.359112] [ 129.785396] offset 0x00 data = 1100 [
>>>> 129.789252] offset 0x01 data = 7849 [ 129.809951] offset 0x02 data =
>>>> 22 [ 129.815018] offset 0x03 data = 1560 [ 129.818845] offset 0x04
>>>> data = 85e1 [ 129.835808] offset 0x05 data = 0 [ 129.839398] offset
>>>> 0x06 data = 4 [ 129.854514] offset 0x07 data = 2001 [ 129.858371]
>>>> offset 0x08 data = 0 [ 129.873357] offset 0x09 data = 0 [
>>>> 129.876954] offset 0x10 data = 0 [ 129.880472] offset 0x11 data = 0
>>>> [ 129.896450] offset 0x15 data = 0 [ 129.900038] offset 0x16 data =
>>>> 202 [ 129.915041] offset 0x17 data = 5c02 [ 129.918889] offset 0x18
>>>> data = 801 [ 129.932735] offset 0x1b data = 0 [ 129.946830] offset
>>>> 0x1c data = 0 [ 129.950424] offset 0x1d data = 0 [ 129.964585]
>>>> offset 0x1e data = 0 [ 129.968192] offset 0x1f data = 8190 [
>>>> 129.972938] [ 129.972938] [ 130.425125] offset 0x00 data = 100 [
>>>> 130.428889] offset 0x01 data = 784d [ 130.442671] offset 0x02 data =
>>>> 22 [ 130.446360] offset 0x03 data = 1560 [ 130.450142] offset 0x04
>>>> data = 8061 [ 130.467207] offset 0x05 data = 0 [ 130.470789] offset
>>>> 0x06 data = 4 [ 130.485071] offset 0x07 data = 2001 [ 130.488934]
>>>> offset 0x08 data = 0 [ 130.504320] offset 0x09 data = 0 [
>>>> 130.507911] offset 0x10 data = 0 [ 130.520950] offset 0x11 data = 0
>>>> [ 130.532865] offset 0x15 data = 0 [ 130.536461] offset 0x16 data =
>>>> 202 [ 130.540156] offset 0x17 data = 3c02 [ 130.557218] offset 0x18
>>>> data = 801 [ 130.560987] offset 0x1b data = 0 [ 130.575158] offset
>>>> 0x1c data = 1 [ 130.578754] offset 0x1d data = 0 [ 130.593543]
>>>> offset 0x1e data = 115 [ 130.597312] offset 0x1f data = 8190
>>>>
>>>> We can see that BMCR and BMSR changes from 0x1100,0x7849 to
>> 0x100,0x784d (BMCR[12] bit and BMSR[2]), and loop it.
>>>> Above process is auto-nego enabled, link is down, auto-nego is disabled,
>>>> link
>> is up. And auto-nego complete bit is always 0.
>>>>
>>>> PHY seems become unstable if soft reset after start/config auto-nego. I
>>>> also
>> want to fix it in micrel driver, but failed.
>>>>
>>>
>>> Waiting for ANEG_COMPLETE to be set wouldn't be a good option. Aneg
>>> may never complete for different reasons, e.g. no physical link. And
>>> even if we use a timeout this may add unwanted delays.
>>>
>>>> Do you have any other insights that can help me further locate the issue?
>> Thanks.
>>>>
>>>
>>> I think current MAC/PHY PM handling isn't perfect. Often we have the
>>> following
>>> scenario:
>>>
>>> *suspend*
>>> 1. PHY is suspended (mdio_bus_phy_suspend) 2. MAC suspend callback
>>> (typically involving phy_stop())
>>>
>>> *resume*
>>> 1. MAC resume callback (typically involving phy_start()) 2. PHY is
>>> resumed (mdio_bus_phy_resume), incl. calling phy_init_hw()
>>>
>>> Calling phy_init_hw() after phy_start() doesn't look right.
>>> It seems to work in most cases, but there's a certain risk that
>>> phy_init_hw() overwrites something, e.g. the advertised modes.
>>> I think we have two valid scenarios:
>>>
>>> 1. phylib PM callbacks are used, then the MAC driver shouldn't
>>> touch the PHY in its PM callbacks, especially not call
>>> phy_stop/phy_start.
>>>
>>> 2. MAC PM callbacks take care also of the PHY. Then I think we would
>>> need a flag at the phy_device telling it to make the PHY PM
>>> callbacks a no-op.
>>>
>>> Andrew, Russell: What do you think?
>>>
>>>> Best Regards,
>>>> Joakim Zhang
>>>>
>>>> [...]
>>>>
>>> Heiner
>>>
>>
>> Based on scenario 1 you can also try the following.
>>
>> diff --git a/drivers/net/ethernet/freescale/fec_main.c
>> b/drivers/net/ethernet/freescale/fec_main.c
>> index 3db882322..cdf9160fc 100644
>> --- a/drivers/net/ethernet/freescale/fec_main.c
>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>> @@ -3805,7 +3805,6 @@ static int __maybe_unused fec_suspend(struct
>> device *dev)
>> if (netif_running(ndev)) {
>> if (fep->wol_flag & FEC_WOL_FLAG_ENABLE)
>> fep->wol_flag |= FEC_WOL_FLAG_SLEEP_ON;
>> - phy_stop(ndev->phydev);
>> napi_disable(&fep->napi);
>> netif_tx_lock_bh(ndev);
>> netif_device_detach(ndev);
>> @@ -3864,7 +3863,6 @@ static int __maybe_unused fec_resume(struct
>> device *dev)
>> netif_device_attach(ndev);
>> netif_tx_unlock_bh(ndev);
>> napi_enable(&fep->napi);
>> - phy_start(ndev->phydev);
>> }
>> rtnl_unlock();
>
> As I described in commit message:
>
> "When I am debugging, I found PHY works fine if MAC doesn't support
> suspend/resume or phy_stop()/phy_start() doesn't been called during
> suspend/resume. This let me realize, PHY state machine phy_state_machine()
> could do something breaks the PHY."
>
> So I have tried your above code change before, and it works. But it is a very
> common phenomenon that MAC suspend/resume invokes phy_stop/start or
> phylink_stop/start, and it's been around for a long time.
>
> As the scenarios you list, it is indeed unreasonable to soft reset or config
> PHY after calling phy_start_aneg() in state machine. PHY state should be
> PHY_UP after calling phy_init_hw(), It seems more reasonable.
>
> Best Regards,
> Joakim Zhang
>> --
>> 2.31.1
>>
>
Following is a draft patch for scenario 1:
Make PHY PM a no-op if MAC manages PHY PM.
Can you give it a try?
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index a009d1769..73d29fd5e 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -273,6 +273,9 @@ static __maybe_unused int mdio_bus_phy_suspend(struct
device *dev)
{
struct phy_device *phydev = to_phy_device(dev);
+ if (phydev->mac_managed_pm)
+ return 0;
+
/* We must stop the state machine manually, otherwise it stops out of
* control, possibly with the phydev->lock held. Upon resume, netdev
* may call phy routines that try to grab the same lock, and that may
@@ -294,6 +297,9 @@ static __maybe_unused int mdio_bus_phy_resume(struct device
*dev)
struct phy_device *phydev = to_phy_device(dev);
int ret;
+ if (phydev->mac_managed_pm)
+ return 0;
+
if (!phydev->suspended_by_mdio_bus)
goto no_resume;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 8e2cf84b2..46702af18 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -567,6 +567,7 @@ struct phy_device {
unsigned loopback_enabled:1;
unsigned downshifted_rate:1;
unsigned is_on_sfp_module:1;
+ unsigned mac_managed_pm:1;
unsigned autoneg:1;
/* The most recently read link state */
--
2.31.1
diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index 3db882322..70aea9c27 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2048,6 +2048,8 @@ static int fec_enet_mii_probe(struct net_device *ndev)
fep->link = 0;
fep->full_duplex = 0;
+ phy_dev->mac_managed_pm = 1;
+
phy_attached_info(phy_dev);
return 0;
@@ -3864,6 +3866,7 @@ static int __maybe_unused fec_resume(struct device *dev)
netif_device_attach(ndev);
netif_tx_unlock_bh(ndev);
napi_enable(&fep->napi);
+ phy_init_hw(ndev->phydev);
phy_start(ndev->phydev);
}
rtnl_unlock();
--
2.31.1
