Date:	Fri, 5 Mar 2010 23:34:08 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
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>
Subject: Re: Problems with remote-wakeup settings

On Fri, 5 Mar 2010, Rafael J. Wysocki wrote:

> > So the problem is that subsystems can't usefully set the can_wakeup 
> > flag before doing either device_initialize() or device_register().  
> > This can be fixed easily by removing the call in device_initialize().
> 
> PCI depends on the flag being unset when pci_pm_init(dev) is called.
> 
> If that's still valid after removing the call in device_initialize(), I'm fine
> with the removal.

It should still be valid.  After all, there's nothing else to set the
flag except for other parts of the PCI core.


> > Agreed, ethtool and sysfs should affect the same flags.
> 
> Yeah, but.  Right now, if the setting is changed via sysfs, it doesn't modify
> the WoL setting as visible by ethtool.

> > I don't understand.  Do you mean there's no way to update the
> > _device's_ WoL setting when the sysfs attribute is changed?
> 
> There's no code for that, that's the problem.
> 
> > The device's WoL setting matters only at suspend time.  So the network
> > driver's suspend routine ought to test device_may_wakeup() to see
> > whether or not WoL should be enabled.  Maybe this can be centralized 
> > somewhere in the network stack.
> 
> Maybe.  The problem is people expect wakeup to work once WoL has been set
> with the help of ethtool and they expect it to work if the WoL is set by
> default.

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.)

> > And also IMO, enabling WoL by default is very questionable.  But that's 
> > a separate matter.
> 
> That's been a common practice for years in the network adapter land and I don't
> think we're able to change that now.  Besides, if the WoL is set to g by
> default, which also is common, that doesn't really lead to any problems.

All right, we can declare that network drivers are allowed to enable
WoL by default (like keyboard drivers).  There shouldn't be any problem
provided they initialize the wakeup setting before registering the
network interface, so that the initialization doesn't override any 
action by udev.

> > That's the real question.  Ideally, drivers won't touch should_wakeup.  
> > How do we get there from here?
> 
> The WoL problem is still in the way, exactly because it can be set using
> ethtool.
> 
> IMO, we should set should_wakeup if the WoL is set via ethtool.  We also should
> unset the WoL if should_wakeup is unset via sysfs (we're missing that piece
> right now).   Generally speaking, it should work transparently both ways.

As I described above.

> Now, if the driver's policy is to set WoL to g, for example, by default, how is
> this different from setting it via ethtool?

Well, clearly there's a difference if the user _doesn't_ run ethtool.  
Apart from that, it's okay.

Alan Stern

--
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