The __rtl8169_get_wol function returns the state of the various WoL
method bits (MagicPaket, Unicast, etc.). While the PMEnable bit is
tested at entry, the function doesn't check the LanWake flag. Even if
any one of the WoL bits is set, WoL is deactivated as a whole if LanWake
isn't set. The return value from __rtl8169_get_wol doesn't reflect
that.
Unfortunately BIOS exist (HP T620) which set the MagicPaket bit to 1 but
the LanWake flag to 0 when switching on WoL in the BIOS. On those
machines, ethtool wrongly claims that WoL via MagicPaket is activated
while in fact it isn't, unless you explicitely called
This patch is supposed to fix this behaviour. If LanWake is 0, the
function now returns 0. Thus ethtool correctly reports "Wake-on: d".
The patch is against Dave's net-next tree.
Signed-off-by: Corinna Vinschen <vinsc...@redhat.com>
---
drivers/net/ethernet/realtek/r8169.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 79ef799..813ad2b 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1705,6 +1705,10 @@ static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
if (!(options & PMEnable))
return 0;
+ options = RTL_R8(Config5);
+ if (!(options & LanWake))
+ return 0;
+
options = RTL_R8(Config3);
if (options & LinkUp)
wolopts |= WAKE_PHY;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
