[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201003062225.09514.rjw@sisk.pl>
Date: Sat, 6 Mar 2010 22:25:09 +0100
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Alan Stern <stern@...land.harvard.edu>
Cc: "Linux-pm mailing list" <linux-pm@...ts.linux-foundation.org>,
linux-input@...r.kernel.org, linux-hotplug@...r.kernel.org,
USB list <linux-usb@...r.kernel.org>,
Kernel development list <linux-kernel@...r.kernel.org>,
NetDev <netdev@...r.kernel.org>
Subject: Re: Problems with remote-wakeup settings
On Saturday 06 March 2010, Alan Stern wrote:
> On Sat, 6 Mar 2010, Rafael J. Wysocki wrote:
>
> > > It's not difficult in theory to tie together the WoL setting and the
> > > wakeup flag:
> > >
> > > If ethtool changes the WoL setting, the driver's ioctl handler
> > > should make the corresponding change to the wakeup flag.
> > >
> > > If ethtool queries the WoL setting, the ioctl handler should
> > > check the wakeup flag. If the flag is off, it should report
> > > that WoL is disabled; if the flag is on, it should report that
> > > WoL is enabled. (The same check should be made in the suspend
> > > routine.)
> >
> > That's done this way already in all drivers I know, but we need a hook
> > from wake_store() back to the driver.
>
> What for? wake_store() can't be called during a sleep transition
> (because tasks are frozen) or while the system is asleep. And if it is
> called at any other time, the driver doesn't need to know until either
> its ioctl handler or its suspend method runs.
Right.
That means, though, that the network adapter drivers' "get WoL" routines
should check should_wakeup too. They don't do that right now, but IMO it's
reasonable to request that they be modified.
Adding netdev to the Cc list.
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists