Re: [PATCH v2] r8169: Don't claim WoL works if LanWake flag is not set

On Dec 11 01:06, Francois Romieu wrote:

Corinna Vinschen [off-list ref] :
[...]

quoted

It's still a bit weird.  On the machines I tested this on, if I disable
LanWake and shutdown the machine, I can send, e.g., MagicPackets as much
as I like, the machined don't come up.  Isn't it a bit misleading then
if ethtool reports that some WoL method is enabled but it doesn't work?

Of course it is. :o(

I'm fine with Config5.LanWake changes if you have empirical evidences that
it helps.

We have terse - outdated ? - documentation and some hint from
http://marc.info/?l=linux-netdev&m=137654699802446. I'm unable to figure
what an/the adequate change could be, especially a low level chance of
regression one.

I think the problem here is that LanWake only switches off aspects of
the WoL capability which can't be reflected in a reliable way to the
kernel.  That's certainly one reason for the driver to enable/disable
LanWake always in lock-step with PMEnable.

So I wonder if we shouldn't just add some code to rtl_init_one (or
create a new function called from rtl_init_one) which checks the WoL
flags and if the PmConfig and LanWake flags are set inconsistently
(aka "differently") then set them to an equal value, either 0 (no WoL
method enabled) or 1 (any WoL method enabled).

Does that make sense?


Thanks,
Corinna