Bug 13764

Summary: Unable to use wol (wake on lan) on Marvell Yukon 88E8056 (sky2)
Product: Drivers Reporter: Federico Simoncelli (federico.simoncelli)
Component: NetworkAssignee: Stephen Hemminger (stephen)
Status: VERIFIED CODE_FIX    
Severity: normal CC: akpm, anonymer5, c20858, federico.simoncelli, ironstorm, jisakiel, rjw
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: kernel-2.6.32-0.33.rc5.git1.fc13 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg
debug patch
dmesg-suspend-debug.out
lspci.out
lspci -vvv and dmesg from 2 runs
Dmesg output from pm_test run on Quadcore
Dmesg output from hibernate run on Quadcore
sky2-wol.patch
sky2: fix wol

Description Federico Simoncelli 2009-07-13 08:01:23 UTC
Description of problem:
I can configure the wol option for my Marvell Yukon 88E8056 (sky2 module):

# ethtool -s eth0 wol g
# ethtool eth0 | grep -i wake
        Supports Wake-on: pg
        Wake-on: g

But on shutdown the ethernet card is powered off too (the link led is off)
making impossible for the wake on lan to work.

Version-Release number of selected component (if applicable):

I've used two different sky2 kernel modules: the fedora kernel one and a
recompiled one from the last kernel version:

# modinfo sky2
filename:      
/lib/modules/2.6.29.5-191.fc11.x86_64/kernel/drivers/net/sky2.ko
version:        1.22
license:        GPL
author:         Stephen Hemminger <shemminger@linux-foundation.org>
description:    Marvell Yukon 2 Gigabit Ethernet driver
srcversion:     FC1DA01907B458FFDE30171

# modinfo sky2
filename:       /lib/modules/2.6.29.5-191.fc11.x86_64/updates/sky2/sky2.ko
version:        1.23
license:        GPL
author:         Stephen Hemminger <shemminger@linux-foundation.org>
description:    Marvell Yukon 2 Gigabit Ethernet driver
srcversion:     9E9002D9E332A1F2E2BFBB9


Steps to Reproduce:
1. ethtool -s eth0 wol g
2. shutdown -h now

Actual results:
The ethernet card led turns off.

Expected results:
The ethernet card should remain on (link led on) waiting for a magic packet.

Additional info:
Marvell Yukon 88E8056 info:

04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056
PCI-E Gigabit Ethernet Controller (rev 13)
       Subsystem: ABIT Computer Corp. Device 1084
       Flags: bus master, fast devsel, latency 0, IRQ 29
       Memory at fdefc000 (64-bit, non-prefetchable) [size=16K]
       I/O ports at ae00 [size=256]
       [virtual] Expansion ROM at fdd00000 [disabled] [size=128K]
       Capabilities: [48] Power Management version 3
       Capabilities: [50] Vital Product Data
       Capabilities: [5c] MSI: Mask- 64bit+ Count=1/1 Enable+
       Capabilities: [e0] Express Legacy Endpoint, MSI 00
       Capabilities: [100] Advanced Error Reporting
       Kernel driver in use: sky2
       Kernel modules: sky2

04:00.0 0200: 11ab:4364 (rev 13)

I still have a dual boot on this machine and configuring wol on windows works
perfectly as described here:

http://www.energystar.gov/index.cfm?c=power_mgt.pr_power_mgt_wol

I'd like to point out that there are two step to make it work:

1) Enable "Wake Up Capabilities"
2) Enable "Wake From Shutdown"

The second step is required to leave the ethernet card on even after windows
shutdown.

I also read somewhere that this issue might be related to acpi and it should be
solved using acpitool -W. Anyway I enabled everything but with no success:

# acpitool -w
  Device       S-state   Status   Sysfs node
 ---------------------------------------
 1. PCI0         S5     enabled   no-bus:pci0000:00
 2. PEX0         S5     enabled   pci:0000:00:1c.0
 3. PEX1         S5     enabled   pci:0000:00:1c.1
 4. PEX2         S5     enabled   pci:0000:00:1c.2
 5. PEX3         S5     enabled
 6. PEX4         S5     enabled
 7. PEX5         S5     enabled
 8. HUB0         S5     enabled   pci:0000:00:1e.0
 9. IGBE         S5     enabled
 10. USB0        S3     enabled   pci:0000:00:1d.0
 11. USB1        S3     enabled   pci:0000:00:1d.1
 12. USB2        S3     enabled   pci:0000:00:1d.2
 13. USB3        S3     enabled   pci:0000:00:1a.0
 14. USB4        S3     enabled   pci:0000:00:1a.1
 15. USB5        S3     enabled   pci:0000:00:1a.2
 16. EHC1        S3     enabled   pci:0000:00:1d.7
 17. EHC2        S3     enabled   pci:0000:00:1a.7
 18. AZAL        S5     enabled   pci:0000:00:1b.0
Comment 1 Federico Simoncelli 2009-07-13 11:22:37 UTC
According to my tests this doesn't seem to fix the problem:

--- sky2.c.orig	2009-07-13 13:16:56.192739689 +0200
+++ sky2.c	2009-07-13 13:17:10.407739353 +0200
@@ -4730,8 +4730,7 @@
 	if (wol)
 		sky2_power_aux(hw);
 
-	pci_enable_wake(pdev, PCI_D3hot, wol);
-	pci_enable_wake(pdev, PCI_D3cold, wol);
+	pci_wake_from_d3(pdev, wol);
 
 	pci_disable_device(pdev);
 	pci_set_power_state(pdev, PCI_D3hot);


Anyway I think it's required to have it fixed.

Ref:
http://lkml.indiana.edu/hypermail/linux/kernel/0808.2/0873.html
Comment 2 Andrew Morton 2009-07-13 21:29:25 UTC
Reassigned to Stephen.
Comment 3 Federico Simoncelli 2009-07-14 08:51:08 UTC
The same behavior is confirmed also with suspend.

Steps to Reproduce:
1. ethtool -s eth0 wol g
2. suspend

Actual results:
The ethernet card led turns off.

Expected results:
The ethernet card should remain on (link led on) waiting for the magic packet.

Trying to let wol work with suspend as first step is faster for test and debug purpose as it doesn't require a full shutdown/boot cycle.
Comment 4 Rafael J. Wysocki 2009-07-22 15:14:55 UTC
I think it will work if you enable wake-up using the /sys/devices/.../power/wakeup interface (i.e. echo 'enabled' to the /sys/devices/.../power/wakeup file of your device).

Can you attach a dmesg output from this machine, please?
Comment 5 Federico Simoncelli 2009-07-22 15:22:20 UTC
(In reply to comment #4)
> I think it will work if you enable wake-up using the
> /sys/devices/.../power/wakeup interface (i.e. echo 'enabled' to the
> /sys/devices/.../power/wakeup file of your device).
> 
> Can you attach a dmesg output from this machine, please?

The /sys/devices/.../power/wakeup is managed automatically by the module:

# ethtool eth0 | grep -i wake
        Supports Wake-on: pg
        Wake-on: d
# cat /sys/class/net/eth0/device/power/wakeup 
disabled
# ethtool -s eth0 wol g
# cat /sys/class/net/eth0/device/power/wakeup 
enabled
Comment 6 Federico Simoncelli 2009-07-22 15:26:53 UTC
Created attachment 22443 [details]
dmesg

dmesg output.
Comment 7 Rafael J. Wysocki 2009-07-22 21:26:17 UTC
Created attachment 22454 [details]
debug patch

Please try to suspend with this patch applied and post dmesg output generated right after that.
Comment 8 Federico Simoncelli 2009-07-22 21:59:41 UTC
Created attachment 22455 [details]
dmesg-suspend-debug.out

dmesg output after suspend with debug patch.

# dmesg-suspend-debug.out
sky2 0000:04:00.0: wol: 32
Comment 9 Rafael J. Wysocki 2009-07-22 22:35:40 UTC
The dmesg output you've just attached shows what the problem is.  Namely, the device has no ACPI context which usually is necessary to make WoL, and generally wake-up from a system sleep state, work.

Perhaps there is an option to use PCI Express PME interrupts for waking up your system, please check in the BIOS setup.
Comment 10 Federico Simoncelli 2009-07-22 22:46:44 UTC
Thanks for the hint, I'm going to check the bios asap. I'd like to point out (as I said in the description) that windows (vista) is able to make wol work with this very bios setup.
Comment 11 Federico Simoncelli 2009-07-22 23:10:29 UTC
Created attachment 22458 [details]
lspci.out

adding lspci -vvv output
Comment 12 Rafael J. Wysocki 2009-07-23 14:19:46 UTC
Well, perhaps Windows sets up PCIe PME interrupts as wake-up interrupts.  We don't do that at the moment.

Whatever does the wake-up, it surely is not ACPI.
Comment 13 Federico Simoncelli 2009-07-23 15:46:25 UTC
(In reply to comment #12)
> Well, perhaps Windows sets up PCIe PME interrupts as wake-up interrupts.  We
> don't do that at the moment.
> 
> Whatever does the wake-up, it surely is not ACPI.

The motherboard is an abit ip35:

http://file.abit.com.tw/pub/download/manual/english/ip35_ip35-e.zip

In the bios tab "Power Management Setup" the options are:

  CPI Suspend Type           S3(Suspend To RAM) Item Help
  - Resume By USB from S3    Enabled
  Power Button Function      Instant-Off
  Wake Up by PME# of PCI     Enabled
  Wake Up by WAKE# of PCIe   Enabled
  Wake Up by Onboard LAN     Enabled
  Wake Up by Alarm           Disabled
  - Date(of Month) Alarm      0
  - Time(hh:mm:ss) Alarm      0 : 0 : 0
  Power On Function          Button Only
  - KB Power On Password     Enter
  - Hot Key Power On         Ctrl-F1
  Restore On AC Power Loss   Power Off

Do you think the WAKE# option is the wake-up interrupt you were referring to? (PS. I'm using the Onboard LAN).
The wake-up interrupts are not supported by the sky2 module or generally by the kernel?
Do you think there is anything else I can try to make the wol work?
Comment 14 Rafael J. Wysocki 2009-07-23 17:31:17 UTC
The settings look fine and the messages printed by the kernel during suspend also look correct.  There's nothing obviously suspicious in there.

Obviously your network adapter is apparently not handled by ACPI, but don't know exactly _how_ it's handled under Vista.

The PCIe PME interrupts are independent of device drivers and the kernel doesn't use them as wake-up interrupts at all.

I have an Asus board with sky2-compatible adapter and it's sufficient to enable something like 'Wake Up by WAKE# of PCIe' for the WoL to work on it IIRC.
Comment 15 John Doe 2009-10-25 17:04:27 UTC
Has this been fixed or there is a workaround?
Comment 16 Federico Simoncelli 2009-11-02 07:48:38 UTC
I didn't find any fix or workaround yet.
Comment 17 Rafael J. Wysocki 2009-11-02 12:43:35 UTC
Please try 2.6.32-rc5 (or later).  There's an important PCI wake-up fix in there.
Comment 18 Garth Dahlstrom 2009-11-03 07:56:48 UTC
I tried 2.6.32-rc5 from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc5/

And saw no change. :(

ged@quadcore:~$ uname -a
Linux quadcore 2.6.32-020632rc5-generic #020632rc5 SMP Fri Oct 16 09:06:17 UTC 2009 x86_64 GNU/Linux

ged@quadcore:~$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
HUB0	  S5	 disabled  pci:0000:00:0a.0
XVR0	  S5	 disabled  pci:0000:00:0b.0
XVR1	  S5	 disabled  pci:0000:00:0c.0
XVR2	  S5	 disabled  pci:0000:00:0d.0
UAR1	  S5	 disabled  pnp:00:08
USB0	  S3	 disabled  pci:0000:00:04.0
USB2	  S3	 disabled  pci:0000:00:04.1
AZAD	  S5	 disabled  pci:0000:00:09.0
MMAC	  S5	 disabled
Comment 19 Federico Simoncelli 2009-11-03 08:26:15 UTC
Same result here with kernel-2.6.32-0.33.rc5.git1.fc13.
The wake-up still doesn't work.

Garth what motherboard do you have?
Can you attach your dmesg and lspci -vvv output thanks.
Comment 20 Rafael J. Wysocki 2009-11-03 09:37:50 UTC
Garth, /proc/acpi/wakeup is meaningless in this case.

Please attach dmesg including a suspend/resume cycle with WoL enabled (from 2.6.32-rc5).
Comment 21 Garth Dahlstrom 2009-11-03 18:26:12 UTC
Created attachment 23639 [details]
lspci -vvv and dmesg from 2 runs

I'm attaching lspci -vvv output from the machine (hostname "quadcore"), along with 2 dmesg runs and a diff -y of the dmesg runs (the machine has never and still can't suspend/resume, it suspends but fails to resume - blinking text cursor + solid hard drive light).

The motherboard is a eVGA 112-CK-NF77-A1 ( http://www.newegg.com/Product/Product.aspx?Item=N82E16813188021 ) - Nvidia chipset, Core2 Quad, with a Marvell Yukon Gig-e PCI-e onboard NIC.

Sorry my understanding (from looking a different Core2 Duo machine "mythtv" with different mobo+NIC that does do WoL) was without the /proc/acpi/wakeup entry, it wouldn't wake up no matter what ethtool says the WoL state is... here is the ethtool WoL wake settings:
root@quadcore:/tmp# ethtool eth0 | grep -i wake
	Supports Wake-on: pg
	Wake-on: g

"quadcore" doesn't respond to WoL either from a power-off start or from suspend btw.

Let me know if there's anything else I can provide or try to assist.

Cheers,

-G
Comment 22 Rafael J. Wysocki 2009-11-03 20:52:14 UTC
First, does hibernation work on this machine?

Second, please try to run

echo core > /sys/power/pm_test
echo mem > /sys/power/state

on this machine (that should simulate a suspend-resume cycle without actually suspending the system; it runs the suspend sequence, waits for 5 seconds and runs the resume sequence) and see if that works.
Comment 23 Garth Dahlstrom 2009-11-07 06:18:18 UTC
Created attachment 23686 [details]
Dmesg output from pm_test run on Quadcore

This is the dmesg from the pm_test...
Comment 24 Garth Dahlstrom 2009-11-07 06:19:33 UTC
Created attachment 23687 [details]
Dmesg output from hibernate run on Quadcore

Hibernate started from Gnome shutdown menu... looks like it crashes X down to ascii mode, but the machine stays up and running (can ssh into it).
Comment 25 Federico Simoncelli 2010-02-02 20:42:14 UTC
In the latest sk98lin driver (version 10.84.3.3) wake on lan works as expected.

I think we can assume now that the problem is in the sky2 driver and not in something else.

The sk98lin source code can be downloaded from:

http://www.marvell.com/support.html

# modinfo sk98lin

filename:       /lib/modules/2.6.31.12-174.2.3.fc12.x86_64/extra/sk98lin.ko
version:        10.84.3.3
license:        GPL
description:    Marvell/SysKonnect Yukon Ethernet Network Driver
author:         Mirko Lindner <support@marvell.com>
srcversion:     9A05D55A65EE118E772F30E

# ethtool eth0 | grep Wake
	Supports Wake-on: g
	Wake-on: g

From the sk98lin.txt file:

9  Wake on Lan Support
======================

The sk98lin supports wake up from suspend mode with MagicPacket.
Wake on Lan support is enabled by default. To disable it, use the ethtool.

NOTE 1: WOL support has to be enabled in the BIOS and in the kernel.

NOTE 2: Refer to the kernel documentation for additional requirements
        regarding WOL support.
Comment 26 Rafael J. Wysocki 2010-02-02 21:09:03 UTC
Any chance to test 2.6.33-rc6?  There are a couple of fixes in this area in there.
Comment 27 Federico Simoncelli 2010-02-03 15:12:57 UTC
I did a quick test:

# uname -r
2.6.33-0.26.rc6.git1.fc13.x86_64

# cat /sys/module/sky2/version 
1.26

# ethtool -s eth0 wol g
# ethtool eth0 | grep Wake
	Supports Wake-on: pg
	Wake-on: g

It's still not working.

Could you please check out the Marvell driver? Maybe you could quickly understand what is missing from sky2.

$ wget http://extranet.marvell.com/drivers/files/install_v10.84.3.3.tar.tar
$ tar -xvf install_v10.84.3.3.tar.tar
$ cd DriverInstall
$ tar -xvjf sk98lin.tar.bz2

$ grep -r WakeFrom .
./common/h/skgeinit.h:		SK_U32 WakeFromS5:1;
./common/h/skgeinit.h:	SK_BOOL	WakeFromShutdownEn;	/* Wake From Shutdown (S5) Enable */
./common/skgeinit.c:		pCfgData->WakeFromShutdownEn	= (SK_BOOL)pCfgVal->fields.WakeFromS5;
Comment 28 Federico Simoncelli 2010-02-04 19:18:44 UTC
In the latest sky2 version wol is still not working but I noticed something that might be relevant:

# cat /sys/module/sky2/version 
1.26
# echo -n core > /sys/power/pm_test
# ethtool -s eth0 wol d
# echo -n mem > /sys/power/state

The link led just turns off and on when the pc resumes.

# ethtool -s eth0 wol g
# echo -n mem > /sys/power/state

The link led turns off and on. After few seconds it turns off and on again when the pc resumes.

I'm not 100% sure but this might mean that it could be working.
What's the difference between the "echo -n mem > /sys/power/state" test and a real shutdown/suspend?

I noticed that in sk98lin a shutdown is treated as a suspend:

static void sk98lin_shutdown(struct pci_dev *pdev) {
        sk98lin_suspend(pdev, PMSG_SUSPEND);
}

Did anyone investigated further on what sk98lin is doing?
The functions sk98lin_suspend and SkEnableWOMagicPacket could reveal something.
Sadly I'm not sure I can fully understand them.
Comment 29 Federico Simoncelli 2010-02-09 14:35:53 UTC
The bug can be reproduced also on an ASUS P5N-E SLI.
Comment 30 Federico Simoncelli 2010-02-09 19:20:09 UTC
Created attachment 24976 [details]
sky2-wol.patch

I finally found the fix for this bug (patch attached).
The problem was quite silly: Y2_HW_WOL_ON and Y2_HW_WOL_OFF were used backward.
The hint came from the sk98lin driver (skge.c:1407):

static void SkEnableWOMagicPacket(
SK_AC         *pAC,      /* Adapter Control Context          */
SK_IOC         IoC,      /* I/O control context              */
SK_MAC_ADDR    MacAddr)  /* MacAddr expected in magic packet */
{
[...]
    SK_OUT16(IoC, B0_CTST, Y2_HW_WOL_OFF);
} /* SkEnableWOMagicPacket */

I don't know the reason (maybe initial mislabeling?) but you have to use the Y2_HW_WOL_OFF value to enable WOL.

According to the sk98lin code this fix isn't something specific to 88E8056: it's required for all Yukon adapters.
I really can't understand why nobody noticed it.
Who reported that WOL was successfully working before?

Please can anyone verify the patch, commit and close? Thanks.
Comment 31 Rafael J. Wysocki 2010-02-09 20:33:57 UTC
Hmm.  In my kernel sources (2.6.33-rc7) the relevant piece of code is:

	if (hw->chip_id == CHIP_ID_YUKON_EC_U ||
	    hw->chip_id == CHIP_ID_YUKON_EX ||
	    hw->chip_id == CHIP_ID_YUKON_FE_P)
		sky2_write32(hw, B0_CTST, wol ? Y2_HW_WOL_ON : Y2_HW_WOL_OFF);

	device_set_wakeup_enable(&hw->pdev->dev, wol);

so I guess the bug should not be present in that kernel?
Comment 32 Federico Simoncelli 2010-02-09 20:50:47 UTC
The bug is still present in the kernel.
Please read carefully comment #30.

If in doubt just patch the source:

  $ patch sky2.c < sky2-wol.patch
Comment 33 Rafael J. Wysocki 2010-02-09 21:48:35 UTC
Created attachment 24983 [details]
sky2: fix wol

So this patch should work on your box as well.  Can you try it, please?
Comment 34 Stephen Hemminger 2010-02-09 22:20:27 UTC
The Y2_HW_WOL_OXX bits control the "Plug in Go" functionality of the
chip. It looks like if this bit is set, then a different set of configuration parameters is loaded out of SPI flash when power transitions from Vmain to Vaux in D3.

The sky2 driver does not change or manage SPI flash directly, it is done by firmware or BIOS.

The vendor driver is a confusing mess and in some cases it does enable it, and other cases not.
Comment 35 Rafael J. Wysocki 2010-02-10 01:00:11 UTC
Well, so do you think the problem reported by Federico is a firmware/BIOS issue?
Comment 36 Stephen Hemminger 2010-02-10 03:24:11 UTC
It is a firmware/BIOS issue, but it probably can be worked around in the driver.
Comment 37 Federico Simoncelli 2010-02-10 08:48:37 UTC
Rafael I had no time to check if your fix actually works but I'm pretty sure it does since it basically swaps the Y2_HW_WOL_ON and Y2_HW_WOL_OFF values.

I think my fix is better because if we start to mess around swapping macro values and breaking the correspondence between sky2 and sk98lin we'll be soon lost: it was very helpful to relay on similar macros with similar values during the debug.

I'm also pretty sure it was not mislabeled:

  $ find -name \*.c | xargs grep -B 1 -n Y2_HW_WOL_O
  ./skge.c-1406-
  ./skge.c:1407: SK_OUT16(IoC, B0_CTST, Y2_HW_WOL_OFF);
  --
  ./skgeinit.c-2686- /* enable HW WOL */
  ./skgeinit.c:2687: SK_OUT16(IoC, B0_CTST, Y2_HW_WOL_ON);
  --
  ./skgeinit.c-3244- /* disable HW WOL */
  ./skgeinit.c:3245: SK_OUT16(IoC, B0_CTST, Y2_HW_WOL_OFF);

We could prefix a comment to make it clear:

/* IMPORTANT: to *enable* Wake-On-Lan you need to use Y2_HW_WOL_OFF */
sky2_write32(hw, B0_CTST, wol ? Y2_HW_WOL_OFF : Y2_HW_WOL_ON);

Stephen, I don't know the yukon firmware/BIOS details and I agree with you: the vendor driver is a confusing mess.
I disagree on the fact that the use of Y2_HW_WOL_O(N|FF) is confusing: it is used only 3 times and at the end of SkEnableWOMagicPacket it was clearly set to Y2_HW_WOL_OFF. I don't think it's a firmware/BIOS workaround, maybe it's just a required parameter to be set.
Comment 38 Stephen Hemminger 2010-02-10 16:07:54 UTC
I have the official documents on most of the chip variants, so the definition of the WOL bits is clear. What isn't clear is what the firmware does.
Comment 39 Federico Simoncelli 2010-02-12 10:59:55 UTC
So Stephen could you verify, commit and close?
Comment 40 Dirk Meier 2010-06-11 09:12:23 UTC
Can someone please commit the fix to the main tree?

I have the same problem with a Marvell 88E8071. I tried Rafael's patch on a 2.6.33 kernel and now it works.

I have also tried the stock Fedore 13 kernel (2.6.34) and the bug is still present.

It would be very kind if the fix would be in the main line.
Comment 41 Federico Simoncelli 2010-06-11 09:24:21 UTC
(In reply to comment #40)
> Can someone please commit the fix to the main tree?
> 
> I have the same problem with a Marvell 88E8071. I tried Rafael's patch on a
> 2.6.33 kernel and now it works.

Good to know that Rafael's patch is working too.
I still prefer mine as I explained in comment #37.

> Rafael's patch
> I have also tried the stock Fedore 13 kernel (2.6.34) and the bug is still
> present.

I confirm this, you can check:

http://bugzilla.redhat.com/show_bug.cgi?id=510693

It's 4 months that I'm rebuilding the patched sky2 module due the lack of interest in resolving this bug in main line.
Comment 42 Stephen Hemminger 2010-06-11 14:59:53 UTC
Fixed in 2.6.34

Author: stephen hemminger <shemminger@vyatta.com>  2010-02-11 22:57:59
Committer: David S. Miller <davem@davemloft.net>  2010-02-12 16:21:00
Parent: 8b05543129a5f216e08625e947a16b844bc4766d (sky2: fix sparse warning)
Child:  87b09f1f25cd1e01d7c50bf423c7fe33027d7511 (sky2: dont enable PME legacy mode)
Branches: master, remotes/origin/master
Follows: v2.6.33-rc5
Precedes: v2.6.34-rc1

    sky2: WoL changes
    
    Change Wake On Lan code to be similar to vendor driver. The definition
    of Y2_HW_WOL_ON is confusing; what it means is transition to firmware SPI
    setting when doing power change.
    
    Since same code is done for both shutdown and suspend, use common
    code path.
    
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
Comment 43 Federico Simoncelli 2010-09-02 16:55:47 UTC
I just tested kernel-2.6.34.6-47.fc13.x86_64 and WOL is now working as expected.