From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f193.google.com ([209.85.216.193]:49155 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755081AbdKIOlf (ORCPT ); Thu, 9 Nov 2017 09:41:35 -0500 MIME-Version: 1.0 In-Reply-To: References: <1510154134-1248-1-git-send-email-ulf.hansson@linaro.org> From: Geert Uytterhoeven Date: Thu, 9 Nov 2017 15:41:33 +0100 Message-ID: Subject: Re: [PATCH 0/3] PM / core: Invent a WAKEUP_POWERED driver flag To: Ulf Hansson Cc: "Rafael J . Wysocki" , Linux PM list , Kevin Hilman , Viresh Kumar , Geert Uytterhoeven , Simon Horman , Niklas Soderlund , Linux-Renesas Content-Type: text/plain; charset="UTF-8" Sender: linux-renesas-soc-owner@vger.kernel.org List-ID: Hi Ulf, On Thu, Nov 9, 2017 at 3:28 PM, Ulf Hansson wrote: > [...] > >>>> 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? The few Ethernet drivers I looked at change the state in their ethtool_ops.set_wol() callback, not during probe. This is to be configured from userspace using ethtool. >>>> 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? I don't know, I was just playing the devil's advocate ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds