Netdev List
 help / color / mirror / Atom feed
From: Andy Gospodarek <andy@greyhouse.net>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Andy Gospodarek <andy@greyhouse.net>,
	"Ronciak, John" <john.ronciak@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
	"Allan, Bruce W" <bruce.w.allan@intel.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>,
	"stable@kernel.org" <stable@kernel.org>
Subject: Re: [PATCH] igb/e1000e/e1000/e100: make wol usable
Date: Wed, 22 Jul 2009 15:34:00 -0400	[thread overview]
Message-ID: <20090722193400.GN8515@gospo.rdu.redhat.com> (raw)
In-Reply-To: <5f2db9d90907212025k31c3a941v5fd1be9ed171e4c1@mail.gmail.com>

On Tue, Jul 21, 2009 at 08:25:31PM -0700, Alexander Duyck wrote:
> My understanding was that the can_wakeup was supposed to be
> initialized by pci_pm_init or platform_pci_wakeup_init based on the
> pci-e capabilities.  Is this not the case?  It seems like this is
> where you should be looking to determine why the the can_wakeup isn't
> being initialized correctly.
> 
> The patch below won't solve the problem either.  The problem is that
> the can_wakeup value is being disabled when the EEPROM doesn't support
> WOL.

The lack of EEPROM support for this was not the problem at all.
Ultimately it turns out that can_wakeup is set in pci_pm_init, so calls
to device_init_wakeup and device_set_wakeup_capable should not be needed
in any driver.

> If you have to do this in the drivers, then my suggestion is to take a
> look at how ixgbe is doing it.  You essentially need to initialize
> can_wakeup to true, and then set the should_wakeup attribute based on
> the EEPROM setting or via ethtool.  This way you can still toggle the
> should_wakeup option without being blocked by the EEPROM disabling it.

The first patch does exactly that (and ixgbe was part of my inspiration
for it).  Since can_wakeup and should_wakeup are both set in
device_init_wakeup it's a suitable alternative in driver probe
functions, but probably not ideal when drivers check for
device_can_wakeup in their ethtool set_wol functions.

Anyway, I knew I would find a bug or unnecessary code between e1000e and
friends or ixgbe, so it looks like ixgbe has an unnecessary call to
device_init_wakeup.  Feel free to consider this patch as an alternative.



[PATCH] ixgbe: remove unnecessary call to device_init_wakeup

Calls to device_init_wakeup should not be necessary in drivers that use
device_set_wakeup_enable since pci_pm_init will set the can_wakeup flag
for the device when initialized.

I can't test this since I don't have any of the 82599 KX4 interfaces
(the only ones capable of WOL), but I did instrument ixgbe_probe and
know that can_wakeup=1 when device_init_wakeup is removed.

Signed-off-by: Andy Gospodarek <andy@greyhouse.net>

---

 ixgbe_main.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 79f60e8..2f15abf 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -5640,7 +5640,6 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
 		adapter->wol = 0;
 		break;
 	}
-	device_init_wakeup(&adapter->pdev->dev, true);
 	device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
 
 	/* pick up the PCI bus settings for reporting later */


  parent reply	other threads:[~2009-07-22 19:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-21 21:01 [PATCH] igb/e1000e/e1000/e100: make wol usable Andy Gospodarek
2009-07-21 21:59 ` Ronciak, John
2009-07-22  2:27   ` Andy Gospodarek
2009-07-22  3:25     ` Alexander Duyck
2009-07-22  3:56       ` David Miller
2009-07-22 19:34       ` Andy Gospodarek [this message]
2009-07-22 20:00         ` Waskiewicz Jr, Peter P
2009-07-22 23:43         ` Waskiewicz Jr, Peter P
2009-07-23 18:06           ` David Miller

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=20090722193400.GN8515@gospo.rdu.redhat.com \
    --to=andy@greyhouse.net \
    --cc=alexander.duyck@gmail.com \
    --cc=bruce.w.allan@intel.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.ronciak@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=peter.p.waskiewicz.jr@intel.com \
    --cc=stable@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