On 24.05.2022 03:08, Andrew Lunn wrote: >> @@ -976,6 +977,25 @@ static irqreturn_t phy_interrupt(int irq, void *phy_dat) >> struct phy_driver *drv = phydev->drv; >> irqreturn_t ret; >> >> + if (IS_ENABLED(CONFIG_PM_SLEEP) && >> + (phydev->mdio.dev.power.is_prepared || >> + phydev->mdio.dev.power.is_suspended)) { >> + struct net_device *netdev = phydev->attached_dev; >> + >> + if (netdev) { >> + struct device *parent = netdev->dev.parent; >> + >> + if (netdev->wol_enabled) >> + pm_system_wakeup(); >> + else if (device_may_wakeup(&netdev->dev)) >> + pm_wakeup_dev_event(&netdev->dev, 0, true); >> + else if (parent && device_may_wakeup(parent)) >> + pm_wakeup_dev_event(parent, 0, true); >> + } >> + >> + return IRQ_HANDLED; > I'm not sure you can just throw the interrupt away. There have been > issues with WoL, where the WoL signal has been applied to a PMC, not > an actual interrupt. Yet the PHY driver assumes it is an > interrupt. And in order for WoL to work correctly, it needs the > interrupt handler to be called. We said the hardware is broken, WoL > cannot work for that setup. > > Here you have correct hardware, but you are throwing the interrupt > away, which will have the same result. So i think you need to abort > the suspend, get the bus working again, and call the interrupt > handler. If this is a WoL interrupt you are supposed to be waking up > anyway. This hardware doesn't support wake-on-lan. It looks somehow that it manages to throw an interrupt just a moment before the power regulator for the whole usb bus is cut off. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland