[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACVXFVMN85g2+B_-1kyTJ=kSDWD5vbSja-hjTHvy2dLk1YN6cw@mail.gmail.com>
Date: Tue, 11 Dec 2012 23:58:19 +0800
From: Ming Lei <ming.lei@...onical.com>
To: Oliver Neukum <oliver@...kum.org>
Cc: Steve Glendinning <steve@...well.net>,
Steve Glendinning <steve.glendinning@...well.net>,
netdev <netdev@...r.kernel.org>, linux-usb@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux PM List <linux-pm@...r.kernel.org>
Subject: Re: [PATCH][RFC] smsc95xx: enable dynamic autosuspend (RFC)
CC linux-power
On Tue, Dec 11, 2012 at 11:19 PM, Oliver Neukum <oliver@...kum.org> wrote:
> On Tuesday 11 December 2012 20:53:19 Ming Lei wrote:
>> In fact, I have test data which can show a much power save
>> on OMAP3 based beagle board plus asix usbnet device with
>> the periodic work. IMO, the power save after introducing periodic
>> timer depends on the arch or platform, there should be much power
>> save if the CPU power consumption is very less. So how about letting
>> module parameter switch on/off the periodic work?
>
> You could ask on linux-power and netdev. But there would be an
> obvious question: Why kernel space?
How does user space utility know one interface doesn't support remote
wakeup for link change? and how to do it in user space? Or could we
persuade user space guys to do it? Or could the previous user space
utility can support power save on these devices?
At least, one advantage of doing it in kernel space is that we can let
current and previous user space utility support power save on these
devices when the link is off.
Also, suppose user space utility may close interface automatically when
the link becomes off, some configurations(such as IP address) of the
network interface will be lost after it is brought up again next time once
the link becomes on. The problem might break some application.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists