On 11.07.2018 22:55, Andrew Lunn wrote: >> +/** >> + * phy_speed_down - set speed to lowest speed supported by both link >> partners >> + * @phydev: the phy_device struct >> + * @sync: perform action synchronously >> + * >> + * Description: Typically used to save energy when waiting for a WoL packet >> + */ >> +int phy_speed_down(struct phy_device *phydev, bool sync) > > This sync parameter needs some more thought. I'm not sure it is safe. > > How does a PHY trigger a WoL wake up? I guess some use the interrupt > pin. How does a PHY indicate auto-neg has completed? It triggers an > interrupt. So it seems like there is a danger here we suspend, and > then wake up 2 seconds later when auto-neg has completed. > > I'm not sure we can safely suspend until auto-neg has completed. > >> +/** >> + * phy_speed_up - (re)set advertised speeds to all supported speeds >> + * @phydev: the phy_device struct >> + * @sync: perform action synchronously >> + * >> + * Description: Used to revert the effect of phy_speed_down >> + */ >> +int phy_speed_up(struct phy_device *phydev, bool sync) > > And here, i'm thinking the opposite. A MAC driver needs to be ready > for the PHY state to change at any time. So why do we need to wait? > Just let the normal mechanisms inform the MAC when the link is up. > I see your points, thanks for the feedback. In my case WoL triggers a PCI PME and the code works as expected, but I agree this may be different in other setups (external PHY).
The sync parameter was inspired by following comment from Florian: "One thing that bothers me a bit is that this should ideally be offered as both blocking and non-blocking options" So let's see which comments he may have before preparing a v2. > Andrew > Heiner
