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

On Dec 10 21:40, Francois Romieu wrote:

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

quoted

I could do this (after I could lay my hands on such a board, that is),
but I'm not convinced that this makes a lot of sense for two reasons.

Ok, let's get this change applied. Whatever happens should not be
hard to manage (I'm thinking about other boards or BIOSes relying on the
current - broken as it can be - behavior to work correctly).

[...]

quoted

1.  There is no global change in behaviour.  The usual way to handle the
    WoL flags is to set the affected method flags and additionally set
    LanWake if any of the method flags is set.  The fact that the method
    flags don't enable WoL without also settting the LanWake flag is
    documented.

I see no such thing in "7.5 Power Management Function" of the 8168c
registers datasheet. While Config3 states Magic Packet and Link Up
dependencies on Config1.PMEn, it says nothing about Config5.LanWake.

On old 8169 chipsets LanWake is autoloaded from EEPROM.

Plausible for Config5.{B, M, U}WF ? Ok.

Documented ? I am genuinely curious to know where.

Ok, I reread the documentation I have, and I got that wrong it seems.
Apparently the LanWake flag enables or disables the LANWAKE/LANWAKEB pin
only but not the other possible PM events.

So, self-NACKed.

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?


Corinna