From: Yuval Mintz <Yuval.Mintz@cavium.com>
To: <davem@davemloft.net>, <netdev@vger.kernel.org>
Cc: Yuval Mintz <Yuval.Mintz@cavium.com>
Subject: [PATCH net-next 01/10] qede: Allow WoL to activate by default
Date: Sun, 21 May 2017 12:10:52 +0300 [thread overview]
Message-ID: <1495357860-28280-2-git-send-email-Yuval.Mintz@cavium.com> (raw)
In-Reply-To: <1495357860-28280-1-git-send-email-Yuval.Mintz@cavium.com>
When management firmware declares that the device is WoL-capable,
the default driver behavior would be to allow the management firmware
to take the decision of whether it's actually needed or not.
Problem is ethtool interface doesn't have a 'default' kind
of option, and user would see the interface WoL as disabled,
which doesn't accurately reflect the actual configuration.
More-so, if the user actually wants to explicitly disable WoL he'd have
to first enable it [otherwise ethtool would block the command].
Instead of allowing management to make the decision, enable WoL by
default on all devices capable of it.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qede/qede_main.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 38b77bb..4a46052 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -618,6 +618,12 @@ static struct qede_dev *qede_alloc_etherdev(struct qed_dev *cdev,
memset(&edev->stats, 0, sizeof(edev->stats));
memcpy(&edev->dev_info, info, sizeof(*info));
+ /* As ethtool doesn't have the ability to show WoL behavior as
+ * 'default', if device supports it declare it's enabled.
+ */
+ if (edev->dev_info.common.wol_support)
+ edev->wol_enabled = true;
+
INIT_LIST_HEAD(&edev->vlan_list);
return edev;
--
1.9.3
next prev parent reply other threads:[~2017-05-21 9:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-21 9:10 [PATCH net-next 00/10] qed/qede updates Yuval Mintz
2017-05-21 9:10 ` Yuval Mintz [this message]
2017-05-21 9:10 ` [PATCH net-next 02/10] qede: Honor user request for Tx buffers Yuval Mintz
2017-05-21 9:10 ` [PATCH net-next 03/10] qede: Add missing Status-block free Yuval Mintz
2017-05-21 9:10 ` [PATCH net-next 04/10] qede: Don't use an internal MAC field Yuval Mintz
2017-05-21 9:10 ` [PATCH net-next 05/10] qed: Revise alloc/setup/free flow Yuval Mintz
2017-05-21 9:10 ` [PATCH net-next 06/10] qed: Correct print in iscsi error-flow Yuval Mintz
2017-05-21 9:10 ` [PATCH net-next 07/10] qede: qedr closure after setting state Yuval Mintz
2017-05-21 9:10 ` [PATCH net-next 08/10] qed: Fix setting of Management bitfields Yuval Mintz
2017-05-21 9:11 ` [PATCH net-next 09/10] qede: Support 1G advertisment Yuval Mintz
2017-05-21 17:01 ` [PATCH net-next 00/10] qed/qede updates David Miller
2017-05-23 6:46 ` Mintz, Yuval
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=1495357860-28280-2-git-send-email-Yuval.Mintz@cavium.com \
--to=yuval.mintz@cavium.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/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