On Dec 10 21:40, Francois Romieu wrote:
> Corinna Vinschen <vinsc...@redhat.com> :
> [...]
> > 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).
>
> [...]
> > 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
pgpdp6cN6Fxeq.pgp
Description: PGP signature
