Skip to contentSkip to conversation

New: WOL for E100 Doesn't Work Anymore

Bugme-new In review Andrew Morton 3 participants 11 messages Oct 28, 2008 – Nov 7, 2008 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

#1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 17 lines · On Sun, 26 Oct 2008 21:56:35 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11865

           Summary: WOL for E100 Doesn't Work Anymore
           Product: Drivers
           Version: 2.5
     KernelVersion: 2.6.27
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Network
        AssignedTo: [email protected]
        ReportedBy: [email protected]
Quoted 1 line

Latest working kernel version: 2.6.27

This should read 2.6.26. It is a regression.

Quoted 12 lines

Earliest failing kernel version: 2.6.27
Distribution: Gentoo
Hardware Environment: 2x750P3 1G RAM w/

00:14.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)

Problem Description:
As of kernel version 2.6.27, WOL has stopped working. The box no longer powers on after the magic packet has been sent. Rebooting using kernel-2.6.26*, WOL *does* work!

Quoted 8 lines

Steps to reproduce:
(Not needed. Self Explanatory.)

I noticed 3 lines of code in e100.c added/modified since 2.6.26*, however, I reversed 2 lines of code to 2.6.26 and the other line was just added an additional pointer, for which I left alone. Recompiled, rebooted and WOL still didn't work using 2.6.27. I'm guessing, the source of this bug lies elsewhere.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

#2 lore raw
Quoted 22 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 16 lines · On Sun, 26 Oct 2008 21:56:35 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11865

Summary: WOL for E100 Doesn't Work Anymore
Product: Drivers Version: 2.5
KernelVersion: 2.6.27
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Network
AssignedTo: [email protected]
ReportedBy: [email protected]

Quoted 15 lines
Quoted 1 line

Latest working kernel version: 2.6.27

This should read 2.6.26. It is a regression.

Quoted 11 lines

Earliest failing kernel version: 2.6.27
Distribution: Gentoo
Hardware Environment: 2x750P3 1G RAM w/

00:14.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)

Problem Description:
As of kernel version 2.6.27, WOL has stopped working. The box no longer powers on after the magic packet has been sent. Rebooting using kernel-2.6.26*, WOL *does* work!

what does cat /proc/acpi/wakeup say? (if you have legacy acpi procfs)

Quoted 10 lines
Quoted 10 lines

Steps to reproduce:
(Not needed. Self Explanatory.)

I noticed 3 lines of code in e100.c added/modified since 2.6.26*, however, I reversed 2 lines of code to 2.6.26 and the other line was just added an additional pointer, for which I left alone. Recompiled, rebooted and WOL still didn't work using 2.6.27. I'm guessing, the source of this bug lies elsewhere.

I think there is an outstanding patch set to "make device use the new power management api"
http://marc.info/?l=linux-netdev&m=121874992800468&w=2

It doesn't appear this patch was in 2.6.27, I'm not sure why not, but I am relatively afraid that lots of devices ability to wake up got busted in 2.6.27.

#3 lore raw
Quoted 52 lines · Jesse
Quoted 22 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 16 lines · On Sun, 26 Oct 2008 21:56:35 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11865

Summary: WOL for E100 Doesn't Work Anymore
Product: Drivers Version: 2.5
KernelVersion: 2.6.27
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Network
AssignedTo: [email protected]
ReportedBy: [email protected]

Quoted 15 lines
Quoted 1 line

Latest working kernel version: 2.6.27

This should read 2.6.26. It is a regression.

Quoted 11 lines

Earliest failing kernel version: 2.6.27
Distribution: Gentoo
Hardware Environment: 2x750P3 1G RAM w/

00:14.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)

Problem Description:
As of kernel version 2.6.27, WOL has stopped working. The box no longer powers on after the magic packet has been sent. Rebooting using kernel-2.6.26*, WOL *does* work!

what does cat /proc/acpi/wakeup say? (if you have legacy acpi procfs)

Quoted 10 lines
Quoted 10 lines

Steps to reproduce:
(Not needed. Self Explanatory.)

I noticed 3 lines of code in e100.c added/modified since 2.6.26*, however, I reversed 2 lines of code to 2.6.26 and the other line was just added an additional pointer, for which I left alone. Recompiled, rebooted and WOL still didn't work using 2.6.27. I'm guessing, the source of this bug lies elsewhere.

Quoted 3 lines

I think there is an outstanding patch set to "make device use the new power management api"
http://marc.info/?l=linux-netdev&m=121874992800468&w=2

There were three patches like this, one against sky2 and the others for e100 and skge. The sky2 one has been merged, the other two are in the Jeff's tree AFAICS.

Quoted 3 lines

It doesn't appear this patch was in 2.6.27, I'm not sure why not, but I am relatively afraid that lots of devices ability to wake up got busted in 2.6.27.

Well, unfortunately the maintainers of the networking code were not very interested in these patches, although I had sent them well before 2.6.27 for the first time.

Generally, the sky2 commit at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d731d77c9794bb0a264f58d35949a1ab6dcc41c
illustrates what needs to be done for other NICs supporting WOL (the key part is to call device_set_wakeup_enable() with appropriate arguments whenever WOL is enabled/disabled and using for the initialization).

I'm going to do this over time for all of the drivers, but if anyone can help, please do so.

Thanks,
Rafael

#4 lore raw
Quoted 8 lines · Rafael J. Wysocki
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

00:14.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)

Problem Description:
As of kernel version 2.6.27, WOL has stopped working. The box no longer powers on after the magic packet has been sent. Rebooting using kernel-2.6.26*, WOL *does* work!

Quoted 7 lines
Quoted 3 lines

I think there is an outstanding patch set to "make device use the new power management api"
http://marc.info/?l=linux-netdev&m=121874992800468&w=2

There were three patches like this, one against sky2 and the others for e100 and skge. The sky2 one has been merged, the other two are in the Jeff's tree AFAICS.

why did you pick those three drivers? I'm glad you picked e100 as one of the ones to make the change to, but there are a lot of other drivers that support wake on lan, and are probably now broken.

Quoted 8 lines
Quoted 3 lines

It doesn't appear this patch was in 2.6.27, I'm not sure why not, but I am relatively afraid that lots of devices ability to wake up got busted in 2.6.27.

Well, unfortunately the maintainers of the networking code were not very interested in these patches, although I had sent them well before 2.6.27
for the first time.

unless I am mistaken the reason we have drivers in the kernel is that so when API changes are made to the kernel the driver is pulled along with it. As I understand it, your changes to the core API should have been rejected until the drivers that used power management APIs were updated too, otherwise we just get generic user breakage.

Would you have asked for our help directly (CC:) we probably can/could help with our drivers.

Quoted 2 lines

Generally, the sky2 commit at

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi
t;h=9d731d77c9794bb0a264f58d35949a1ab6dcc41c

Quoted 7 lines

illustrates what needs to be done for other NICs supporting WOL (the key part is to call device_set_wakeup_enable() with appropriate arguments whenever
WOL is enabled/disabled and using for the initialization).

I'm going to do this over time for all of the drivers, but if anyone can help, please do so.

While that is a worthy goal, I don't think it is okay to have regressions until you have time to fix them. This is a pretty big change in a subtly difficult area to both get right and to test.

Your work is appeciated, I just didn't realize it would break all devices that didn't implement it.

I'm open to corrections to my point of view above. Jesse

#5 lore raw
Quoted 16 lines · On Tuesday, 4 of November 2008, [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11865

------- Comment #5 from [email protected] 2008-11-03 16:48 -------

Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines
Quoted 7 lines
Quoted 7 lines

00:14.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)

Problem Description:
As of kernel version 2.6.27, WOL has stopped working. The box no longer powers on after the magic packet has been sent. Rebooting using kernel-2.6.26*, WOL *does* work!

I think there is an outstanding patch set to "make device use the new power management api"
http://marc.info/?l=linux-netdev&m=121874992800468&w=2

Quoted 5 lines
Quoted 3 lines

There were three patches like this, one against sky2 and the others for e100 and skge. The sky2 one has been merged, the other two are in the Jeff's tree AFAICS.

why did you pick those three drivers?

I could test them myself at that time.

Quoted 3 lines

I'm glad you picked e100 as one of the ones to make the change to, but there are a lot of other drivers that support wake on lan, and are probably now broken.

Well, many of them wouldn't work due to the missing ACPI support and the changes in question were necessary to add that support. Also, there were _no_ problem reports related to this until now, except for the sky2 case that was immediately handled.

Quoted 9 lines
Quoted 8 lines
Quoted 3 lines

It doesn't appear this patch was in 2.6.27, I'm not sure why not, but I am relatively afraid that lots of devices ability to wake up got busted in 2.6.27.

Well, unfortunately the maintainers of the networking code were not very interested in these patches, although I had sent them well before 2.6.27
for the first time.

Quoted 5 lines

unless I am mistaken the reason we have drivers in the kernel is that so when API changes are made to the kernel the driver is pulled along with it. As I understand it, your changes to the core API should have been rejected until the drivers that used power management APIs were updated too, otherwise we just get generic user breakage.

Unfortunately, I had to fix some damage that had been caused by someone else before and I wanted to send fixes for all of the drivers once the first batch of my patches (sky2, e100, skge, tg3 - I forgot about this one, it's already in) had been accepted, but that hasn't really happened yet.

Quoted 2 lines

Would you have asked for our help directly (CC:) we probably can/could help with our drivers.

Sorry about that, my fault.

Quoted 9 lines
Quoted 2 lines

Generally, the sky2 commit at

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi
t;h=9d731d77c9794bb0a264f58d35949a1ab6dcc41c

Quoted 5 lines

illustrates what needs to be done for other NICs supporting WOL (the key part is to call device_set_wakeup_enable() with appropriate arguments whenever
WOL is enabled/disabled and using for the initialization).

Quoted 6 lines
Quoted 2 lines

I'm going to do this over time for all of the drivers, but if anyone can help, please do so.

While that is a worthy goal, I don't think it is okay to have regressions until you have time to fix them. This is a pretty big change in a subtly difficult area to both get right and to test.

This isn't really "until I have time to fix them", but "until my fixes are accepted" thing. I _really_ care about regressions, but in this case I failed to make people realize the importance of the patches I was sending.

Moreover, I wasn't quite sure how many systems would _really_ be broken, because many of them didn't work anyway (despite the support in the drivers), as I said above. For this reason, I thought I would fix problems as soon as they were reported, but there was only one report before this one.

Quoted 2 lines

Your work is appeciated, I just didn't realize it would break all devices that didn't implement it.

In fact it doesn't really break them, you can write 'enabled' to /sys/devices/.../power/wakeup of the device in question and it will work.

Quoted 1 line

I'm open to corrections to my point of view above.

Well, before those changes WOL didn't work on any of my machines and now it works on all of them (except for one that hasn't been tested) - with the already merged patches and the two waiting for merging.

Sorry about the problems caused, I'm willing to fix them ASAP.

Thanks,
Rafael

#6 lore raw

cover WOL fixes for e1000e, e1000 and igb (was: Re: [Bugme-new] [Bug 11865] New: WOL for E100 Doesn't Work Anymore)

On Tuesday, 4 of November 2008, Rafael J. Wysocki wrote:
[--snip--]

Quoted 7 lines
Quoted 3 lines

Your work is appeciated, I just didn't realize it would break all devices that didn't implement it.

In fact it doesn't really break them, you can write 'enabled' to /sys/devices/.../power/wakeup of the device in question and it will work.

Quoted 7 lines
Quoted 1 line

I'm open to corrections to my point of view above.

Well, before those changes WOL didn't work on any of my machines and now it works on all of them (except for one that hasn't been tested) - with the already merged patches and the two waiting for merging.

Sorry about the problems caused, I'm willing to fix them ASAP.

BTW, WOL fixes for e1000e, e1000 and igb follow.

Thanks,
Rafael

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

#7 lore raw

PATCH 1/3 e1000e: Use device_set_wakeup_enable

Author: Rafael J. Wysocki <[email protected]>
Subject: e1000e: Use device_set_wakeup_enable

Since dev->power.should_wakeup bit is used by the PCI core to decide whether the device should wake up the system from sleep states, set/unset this bit whenever WOL is enabled/disabled using e1000_set_wol(). Accordingly, use device_can_wakeup() for checking if wake-up is supported by the device.

---
 drivers/net/e1000e/ethtool.c |    8 ++++++--
 drivers/net/e1000e/netdev.c  |    1 +
 2 files changed, 7 insertions(+), 2 deletions(-)
drivers/net/e1000e/ethtool.c +6 -2
Index: linux-2.6/drivers/net/e1000e/ethtool.c
===================================================================
@@ -1713,7 +1713,8 @@ static void e1000_get_wol(struct net_dev
 	wol->supported = 0;
 	wol->wolopts = 0;
 
-	if (!(adapter->flags & FLAG_HAS_WOL))
+	if (!(adapter->flags & FLAG_HAS_WOL) ||
+	    !device_can_wakeup(&adapter->pdev->dev))
 		return;
 
 	wol->supported = WAKE_UCAST | WAKE_MCAST |
@@ -1751,7 +1752,8 @@ static int e1000_set_wol(struct net_devi
 	if (wol->wolopts & WAKE_MAGICSECURE)
 		return -EOPNOTSUPP;
 
-	if (!(adapter->flags & FLAG_HAS_WOL))
+	if (!(adapter->flags & FLAG_HAS_WOL) ||
+	    !device_can_wakeup(&adapter->pdev->dev))
 		return wol->wolopts ? -EOPNOTSUPP : 0;
 
 	/* these settings will always override what we currently have */
@@ -1770,6 +1772,8 @@ static int e1000_set_wol(struct net_devi
 	if (wol->wolopts & WAKE_ARP)
 		adapter->wol |= E1000_WUFC_ARP;
 
+	device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
+
 	return 0;
 }
 
drivers/net/e1000e/netdev.c +1 -0
Index: linux-2.6/drivers/net/e1000e/netdev.c
===================================================================
@@ -4970,6 +4970,7 @@ static int __devinit e1000_probe(struct
 
 	/* initialize the wol settings based on the eeprom settings */
 	adapter->wol = adapter->eeprom_wol;
+	device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
 
 	/* reset the hardware with the new settings */
 	e1000e_reset(adapter);

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

#8 lore raw

PATCH 2/3 e1000: Use device_set_wakeup_enable

In reply to Rafael J. Wysocki

Author: Rafael J. Wysocki <[email protected]>
Subject: e1000: Use device_set_wakeup_enable

Since dev->power.should_wakeup bit is used by the PCI core to decide whether the device should wake up the system from sleep states, set/unset this bit whenever WOL is enabled/disabled using e1000_set_wol(). Accordingly, use device_can_wakeup() for checking if wake-up is supported by the device.

---
 drivers/net/e1000/e1000_ethtool.c |    8 ++++++--
 drivers/net/e1000/e1000_main.c    |    1 +
 2 files changed, 7 insertions(+), 2 deletions(-)
drivers/net/e1000/e1000_ethtool.c +6 -2
Index: linux-2.6/drivers/net/e1000/e1000_ethtool.c
===================================================================
@@ -1774,7 +1774,8 @@ static void e1000_get_wol(struct net_dev
 
 	/* this function will set ->supported = 0 and return 1 if wol is not
 	 * supported by this hardware */
-	if (e1000_wol_exclusion(adapter, wol))
+	if (e1000_wol_exclusion(adapter, wol) ||
+	    !device_can_wakeup(&adapter->pdev->dev))
 		return;
 
 	/* apply any specific unsupported masks here */
@@ -1811,7 +1812,8 @@ static int e1000_set_wol(struct net_devi
 	if (wol->wolopts & (WAKE_PHY | WAKE_ARP | WAKE_MAGICSECURE))
 		return -EOPNOTSUPP;
 
-	if (e1000_wol_exclusion(adapter, wol))
+	if (e1000_wol_exclusion(adapter, wol) ||
+	    !device_can_wakeup(&adapter->pdev->dev))
 		return wol->wolopts ? -EOPNOTSUPP : 0;
 
 	switch (hw->device_id) {
@@ -1838,6 +1840,8 @@ static int e1000_set_wol(struct net_devi
 	if (wol->wolopts & WAKE_MAGIC)
 		adapter->wol |= E1000_WUFC_MAG;
 
+	device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
+
 	return 0;
 }
 
drivers/net/e1000/e1000_main.c +1 -0
Index: linux-2.6/drivers/net/e1000/e1000_main.c
===================================================================
@@ -1179,6 +1179,7 @@ static int __devinit e1000_probe(struct
 
 	/* initialize the wol settings based on the eeprom settings */
 	adapter->wol = adapter->eeprom_wol;
+	device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
 
 	/* print bus type/speed/width info */
 	DPRINTK(PROBE, INFO, "(PCI%s:%s:%s) ",

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

#9 lore raw

PATCH 3/3 igb: Use device_set_wakeup_enable

In reply to Rafael J. Wysocki

Author: Rafael J. Wysocki <[email protected]>
Subject: igb: Use device_set_wakeup_enable

Since dev->power.should_wakeup bit is used by the PCI core to decide whether the device should wake up the system from sleep states, set/unset this bit whenever WOL is enabled/disabled using igb_set_wol(). Accordingly, use device_can_wakeup() for checking if wake-up is supported by the device.

---
 drivers/net/igb/igb_ethtool.c |    8 ++++++--
 drivers/net/igb/igb_main.c    |    1 +
 2 files changed, 7 insertions(+), 2 deletions(-)
drivers/net/igb/igb_ethtool.c +6 -2
Index: linux-2.6/drivers/net/igb/igb_ethtool.c
===================================================================
@@ -1776,7 +1776,8 @@ static void igb_get_wol(struct net_devic
 
 	/* this function will set ->supported = 0 and return 1 if wol is not
 	 * supported by this hardware */
-	if (igb_wol_exclusion(adapter, wol))
+	if (igb_wol_exclusion(adapter, wol) ||
+	    !device_can_wakeup(&adapter->pdev->dev))
 		return;
 
 	/* apply any specific unsupported masks here */
@@ -1805,7 +1806,8 @@ static int igb_set_wol(struct net_device
 	if (wol->wolopts & (WAKE_PHY | WAKE_ARP | WAKE_MAGICSECURE))
 		return -EOPNOTSUPP;
 
-	if (igb_wol_exclusion(adapter, wol))
+	if (igb_wol_exclusion(adapter, wol) ||
+	    !device_can_wakeup(&adapter->pdev->dev))
 		return wol->wolopts ? -EOPNOTSUPP : 0;
 
 	switch (hw->device_id) {
@@ -1825,6 +1827,8 @@ static int igb_set_wol(struct net_device
 	if (wol->wolopts & WAKE_MAGIC)
 		adapter->wol |= E1000_WUFC_MAG;
 
+	device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
+
 	return 0;
 }
 
drivers/net/igb/igb_main.c +1 -0
Index: linux-2.6/drivers/net/igb/igb_main.c
===================================================================
@@ -1244,6 +1244,7 @@ static int __devinit igb_probe(struct pc
 
 	/* initialize the wol settings based on the eeprom settings */
 	adapter->wol = adapter->eeprom_wol;
+	device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
 
 	/* reset the hardware with the new settings */
 	igb_reset(adapter);

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

#10 lore raw

RE: [PATCH 0/3] WOL fixes for e1000e, e1000 and igb (was: Re: [Bugme-new] [Bug 11865] New: WOL for E100 Doesn't Work Anymore)

In reply to Rafael J. Wysocki
Quoted 12 lines · Rafael J. Wysocki

On Tuesday, 4 of November 2008, Rafael J. Wysocki wrote:
[--snip--]

Quoted 10 lines
Quoted 3 lines

Your work is appeciated, I just didn't realize it would break all devices that didn't implement it.

In fact it doesn't really break them, you can write 'enabled' to /sys/devices/.../power/wakeup of the device in question and it will work.

Quoted 1 line

I'm open to corrections to my point of view above.

Quoted 7 lines
Quoted 5 lines

Well, before those changes WOL didn't work on any of my machines and now it works on all of them (except for one that hasn't been tested)
- with the already merged patches and the two waiting for merging.

Sorry about the problems caused, I'm willing to fix them ASAP.

BTW, WOL fixes for e1000e, e1000 and igb follow.

Awesome! Thanks, we are testing them now and will ack/push upstream in a couple of days (for sure by end of week)

So do you have a count of how many other drivers would need this fix (regardless of when you'll get to them)

#11 lore raw

Re: [PATCH 0/3] WOL fixes for e1000e, e1000 and igb (was: Re: [Bugme-new] [Bug 11865] New: WOL for E100 Doesn't Work Anymore)

Quoted 19 lines · Jesse
Quoted 18 lines · Rafael J. Wysocki

On Tuesday, 4 of November 2008, Rafael J. Wysocki wrote:
[--snip--]

Quoted 15 lines
Quoted 3 lines

Your work is appeciated, I just didn't realize it would break all devices that didn't implement it.

In fact it doesn't really break them, you can write 'enabled' to /sys/devices/.../power/wakeup of the device in question and it will work.

Quoted 1 line

I'm open to corrections to my point of view above.

Well, before those changes WOL didn't work on any of my machines and now it works on all of them (except for one that hasn't been tested)
- with the already merged patches and the two waiting for merging.

Sorry about the problems caused, I'm willing to fix them ASAP.

Quoted 7 lines
Quoted 1 line

BTW, WOL fixes for e1000e, e1000 and igb follow.

Awesome! Thanks, we are testing them now and will ack/push upstream in a couple of days (for sure by end of week)

So do you have a count of how many other drivers would need this fix (regardless of when you'll get to them).

Well, about 20, not including the ones which are OK now and for which patches have been sent.