linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Kubecek <mkubecek@suse.cz>
To: netdev@vger.kernel.org
Cc: Chen Yu <yu.c.chen@intel.com>,
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Auke Kok <auke-jan.h.kok@intel.com>,
	Jeff Garzik <jeff@garzik.org>,
	intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org,
	Len Brown <len.brown@intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Shevchenko, Andriy" <andriy.shevchenko@intel.com>,
	"Neftin, Sasha" <sasha.neftin@intel.com>,
	"Lifshits, Vitaly" <vitaly.lifshits@intel.com>,
	Stable@vger.kernel.org
Subject: Re: [PATCH 2/2] e1000e: Make WOL info in ethtool consistent with device wake up ability
Date: Thu, 21 May 2020 21:23:42 +0200	[thread overview]
Message-ID: <20200521192342.GE8771@lion.mk-sys.cz> (raw)
In-Reply-To: <725bad2f3ce7f7b7f1667d53b6527dc059f9e419.1590081982.git.yu.c.chen@intel.com>

On Fri, May 22, 2020 at 01:59:13AM +0800, Chen Yu wrote:
> Currently the ethtool shows that WOL(Wake On Lan) is enabled
> even if the device wakeup ability has been disabled via sysfs:
>   cat /sys/devices/pci0000:00/0000:00:1f.6/power/wakeup
>    disabled
> 
>   ethtool eno1
>   ...
>   Wake-on: g
> 
> Fix this in ethtool to check if the user has explicitly disabled the
> wake up ability for this device.

Wouldn't this lead to rather unexpected and inconsistent behaviour when
the wakeup is disabled? As you don't touch the set_wol handler, I assume
it will still allow setting enabled modes as usual so that you get e.g.

  ethtool -s eth0 wol g   # no error or warning, returns 0
  ethtool eth0            # reports no modes enabled

The first command would set the enabled wol modes but that would be
hidden from user and even the netlink notification would claim something
different. Another exampe (with kernel and ethtool >= 5.6):

  ethtool -s eth0 wol g
  ethtool -s eth0 wol +m

resulting in "mg" if device wakeup is enabled but "m" when it's disabled
(but the latter would be hidden from user and only revealed when you
enable the device wakeup).

This is a general problem discussed recently for EEE and pause
autonegotiation: if setting A can be effectively used only when B is
enabled, should we hide actual setting of A from userspace when B is
disabled or even reset the value of A whenever B gets toggled or rather
allow setting A and B independently? AFAICS the consensus seemed to be
that A should be allowed to be set and queried independently of the
value of B.

Michal

> Fixes: 6ff68026f475 ("e1000e: Use device_set_wakeup_enable")
> Reported-by: Len Brown <len.brown@intel.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: <Stable@vger.kernel.org>
> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> ---
>  drivers/net/ethernet/intel/e1000e/ethtool.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c b/drivers/net/ethernet/intel/e1000e/ethtool.c
> index 1d47e2503072..0cccd823ff24 100644
> --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
> @@ -1891,7 +1891,7 @@ static void e1000_get_wol(struct net_device *netdev,
>  	wol->wolopts = 0;
>  
>  	if (!(adapter->flags & FLAG_HAS_WOL) ||
> -	    !device_can_wakeup(&adapter->pdev->dev))
> +	    !device_may_wakeup(&adapter->pdev->dev))
>  		return;
>  
>  	wol->supported = WAKE_UCAST | WAKE_MCAST |
> -- 
> 2.17.1
> 

  reply	other threads:[~2020-05-21 19:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-21 17:58 [PATCH 0/2] Make WOL of e1000e consistent with sysfs device wakeup Chen Yu
2020-05-21 17:59 ` [PATCH 1/2] e1000e: Do not wake up the system via WOL if device wakeup is disabled Chen Yu
2020-06-15 18:51   ` Brown, Aaron F
2020-06-16  7:01     ` Chen Yu
2020-05-21 17:59 ` [PATCH 2/2] e1000e: Make WOL info in ethtool consistent with device wake up ability Chen Yu
2020-05-21 19:23   ` Michal Kubecek [this message]
2020-05-23  9:09     ` Chen Yu
2020-05-24 21:06       ` Michal Kubecek
2020-05-25 16:12         ` Chen Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200521192342.GE8771@lion.mk-sys.cz \
    --to=mkubecek@suse.cz \
    --cc=Stable@vger.kernel.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=auke-jan.h.kok@intel.com \
    --cc=davem@davemloft.net \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jeff@garzik.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=kuba@kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=sasha.neftin@intel.com \
    --cc=vitaly.lifshits@intel.com \
    --cc=yu.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).