[PATCH v7 0/5] um: suspend/resume support
Johannes Berg
johannes at sipsolutions.net
Thu Dec 3 05:14:40 EST 2020
On Thu, 2020-12-03 at 10:06 +0000, Anton Ivanov wrote:
>
> Works nicely and I will ACK them shortly.
:)
> I will see if I can add some WOL functionality to the vector drivers.
That might be nice.
> It is definitely possible for the ones which use a raw socket - you
> leave them as capable of generating a SIGIO, but load a "sleeptime"
> BPF filter which allows only the types of packets that are entitled to
> wake you up - WOL magic, ARP, unicast to your own MAC, etc. IIRC
> ethtool has a list of all the possible options. When you wake up, you
> swap back the old filter (if there was any).
Right, you can set the IRQ to allow wakeup using just the normal
irq_set_irq_wake() function, and then you get woken up on anything.
And with a BPF filter you can drop all the other packets, so you don't
get a full socket queue either (in the host) that would prevent
something from working.
Indeed there are more options than I thought there were:
wol p|u|m|b|a|g|s|f|d...
Sets Wake-on-LAN options. Not all devices support this. The argument to this option is a string
of characters specifying which options to enable.
p Wake on PHY activity
u Wake on unicast messages
m Wake on multicast messages
b Wake on broadcast messages
a Wake on ARP
g Wake on MagicPacket™
s Enable SecureOn™ password for MagicPacket™
f Wake on filter(s)
d Disable (wake on nothing). This option
clears all previous options.
p would be trivial, requiring only a call to irq_set_irq_wake(), u, m,
b, a, g and s would require BPF filters, and f (filter) is difficult,
you'd need to support RX-flow-spec stuff, apparently.
I'm trying to add support for virtio ... hmm. Actually p or u might be
very useful there for me, but it'd require changing the virtio-net spec
I guess ... Maybe I'll just do an out-of-band wake device for my system
:)
johannes
More information about the linux-um
mailing list