[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070129093645.3c2d30df@freekitty>
Date: Mon, 29 Jan 2007 09:36:45 -0800
From: Stephen Hemminger <shemminger@...l.org>
To: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix /sys/device/.../power/state regression
On Fri, 26 Jan 2007 19:02:37 -0800
David Brownell <david-b@...bell.net> wrote:
> On Friday 26 January 2007 5:19 pm, Matthew Garrett wrote:
> > On Fri, Jan 26, 2007 at 04:42:56PM -0800, David Brownell wrote:
> > > On Friday 26 January 2007 3:15 pm, Matthew Garrett wrote:
> > > > It's certainly the case that fixing those drivers would result in a
> > > > better long-term situation - however, nobody currently seems to have any
> > > > interest in doing so...
> > >
> > > And the way these things work, unfortunately, is that merging your patch
> > > would ensure nobody ever gets such interest. Removing that "state" file
> > > (and its bogus infrastructure) has already taken a few years too long.
> >
> > I'd argue that the onus is on those who wish to remove the interface to
> > ensure that equivalent functionality exists first.
>
> Are you now arguing that "rmmod $DRIVER" doesn't suffice for what you
> were wanting to do? If so, why? What's the delta in power usage?
For the case that started the discussion (wireless network devices).
The expected behavior is that the device remains in a low power state
until it enabled (set to up). If really smart a wired network device
can also stay in low power state until carrier is detected. There are
also other network device states (dormant, lower layer down), not currently
in use that could also be useful.
The point is that using the /sys/device/.../power/state file
is not the right way to handle network devices. Power usage should
correlate to device status, not be controlled differently.
--
Stephen Hemminger <shemminger@...ux-foundation.org>
-
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