[...] >>> The Ethernet driver can still call device_set_wakeup_enable(... , false) >>> to control this. If WoL is disabled by the user (or deemed not usable, see >>> below), it already does so. >> >> I don't think that API is intended to be used like that and I wonder >> if it even works as expected. >> >> Quoting the doc: >> "If device wakeup mechanisms are enabled or disabled directly by >> drivers, they also should use :c:func:`device_may_wakeup()` to decide what to do >> during a system sleep transition. Device drivers, however, are not expected to >> call :c:func:`device_set_wakeup_enable()` directly in any case." >> >> Rafael, can you comment on this? > > There are ca. 100 callers in drivers. Yeah, but those doesn't normally use it to toggle the setting, but instead only to set a default value during ->probe() or whatever initialization code that runs. I think that makes a big difference, doesn't it? > >>> In addition, keeping WoL enabled for cases 1 and 2 may be desirable >>> (e.g allow wake-up if a cable is plugged in during system suspend and >>> a magic packet is received afterwards), depending on the hardware. >>> But the driver can already control that through device_set_wakeup_enable(). >> >> Ehh, that sounds weird. :-) If the Ethernet interface is down, how >> would such packet be received? > > It depends on your meaning of "up". My interpretation is that "up" means > ready to handle packets between physical media and the Linux networking stack. > > So even when "down", the actual Ethernet controller may still be able to > receive a magic packet if WoL is enabled. The magic packet is really a > magic packet not intended to be transmitted to the networking stack, but > merely serves as a wakeup signal. I see! So, in the end this seems like a combination of what the HW supports and what the user policy is set to. Out of curiosity, can you tell how those Renesas Ethernet devices works in this regards? Anyway, thanks for clarifying! Kind regards Uffe
