Files
rockchip-kernel/include/linux
Lukas Wunner 1758bde2e4 net: phy: Don't trigger state machine while in suspend
Upon system sleep, mdio_bus_phy_suspend() stops the phy_state_machine(),
but subsequent interrupts may retrigger it:

They may have been left enabled to facilitate wakeup and are not
quiesced until the ->suspend_noirq() phase.  Unwanted interrupts may
hence occur between mdio_bus_phy_suspend() and dpm_suspend_noirq(),
as well as between dpm_resume_noirq() and mdio_bus_phy_resume().

Retriggering the phy_state_machine() through an interrupt is not only
undesirable for the reason given in mdio_bus_phy_suspend() (freezing it
midway with phydev->lock held), but also because the PHY may be
inaccessible after it's suspended:  Accesses to USB-attached PHYs are
blocked once usb_suspend_both() clears the can_submit flag and PHYs on
PCI network cards may become inaccessible upon suspend as well.

Amend phy_interrupt() to avoid triggering the state machine if the PHY
is suspended.  Signal wakeup instead if the attached net_device or its
parent has been configured as a wakeup source.  (Those conditions are
identical to mdio_bus_phy_may_suspend().)  Postpone handling of the
interrupt until the PHY has resumed.

Before stopping the phy_state_machine() in mdio_bus_phy_suspend(),
wait for a concurrent phy_interrupt() to run to completion.  That is
necessary because phy_interrupt() may have checked the PHY's suspend
status before the system sleep transition commenced and it may thus
retrigger the state machine after it was stopped.

Likewise, after re-enabling interrupt handling in mdio_bus_phy_resume(),
wait for a concurrent phy_interrupt() to complete to ensure that
interrupts which it postponed are properly rerun.

The issue was exposed by commit 1ce8b37241 ("usbnet: smsc95xx: Forward
PHY interrupts to PHY driver to avoid polling"), but has existed since
forever.

Fixes: 541cd3ee00 ("phylib: Fix deadlock on resume")
Link: https://lore.kernel.org/netdev/a5315a8a-32c2-962f-f696-de9a26d30091@samsung.com/
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: stable@vger.kernel.org # v2.6.33+
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/b7f386d04e9b5b0e2738f0125743e30676f309ef.1656410895.git.lukas@wunner.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-29 20:38:52 -07:00
..
2022-05-10 16:03:52 +08:00
2022-04-20 12:59:50 +05:30
2022-05-22 20:44:29 +01:00
2022-03-23 19:58:38 +01:00
2022-06-08 14:04:14 -04:00
2022-05-20 15:29:00 -07:00
2022-03-11 19:15:03 -08:00
2022-04-22 12:32:03 +02:00
2022-03-15 10:32:44 +01:00
2022-05-16 13:37:59 -07:00
2022-03-16 15:13:36 -07:00
2022-06-03 06:52:57 -07:00
2022-05-13 07:20:18 -07:00
2022-03-02 22:44:49 -08:00
2022-02-28 23:26:27 -08:00
2022-02-19 19:23:53 -08:00
2022-02-14 15:43:15 +01:00
2022-03-18 09:47:04 +01:00
2022-05-02 14:06:20 -06:00
2022-06-06 09:52:17 +09:00
2022-05-03 16:09:03 -04:00
2022-04-21 07:36:56 -04:00
2022-05-19 14:08:53 -07:00
2022-03-21 12:57:38 -04:00
2022-05-13 07:20:17 -07:00
2022-04-28 23:16:14 -07:00
2022-05-12 10:29:41 -07:00
2022-04-28 16:31:10 +02:00
2022-04-01 14:40:44 -04:00
2022-05-17 13:32:46 -04:00
2022-02-09 09:24:40 -05:00
2022-02-09 08:04:44 +01:00
2022-02-09 08:04:44 +01:00
2022-04-05 10:24:38 +02:00
2022-04-19 10:19:02 -07:00
2022-06-10 11:29:48 +02:00
2022-03-08 14:33:36 -06:00
2022-03-17 20:16:29 -07:00
2022-03-23 19:58:41 +01:00
2022-05-22 21:03:01 +01:00
2022-04-07 12:53:54 +02:00
2022-02-24 15:04:51 +00:00
2022-06-02 10:15:05 -07:00
2022-05-08 01:33:08 -07:00
2022-02-25 09:36:06 +01:00
2022-04-11 19:18:27 -06:00
2022-03-22 15:57:11 -07:00
2022-05-24 08:41:18 -06:00
2022-05-31 12:45:10 -04:00
2022-06-13 09:54:52 -07:00