On Wed, 20 Dec 2006 16:51:39 +0100
Arjan van de Ven <[email protected]> wrote:
>
> > Yeah, I guess that's a problem. From a user perspective, the
> > functionality is only really useful if the latency is very small. I
> > think where possible we'd want to power down the chip while keeping the
> > phy up, but it would be nice to know how much power that would actually
> > cost us.
>
>
> I'm no expert but afaik the PHY is the power hungry part, the rest is
> peanuts. So if we can get the PHY to sleep most of the time that would
> be great.
>
There are two different problems:
1) Behavior seems to be different depending on device driver
author. We should document the expected semantics better.
IMHO:
When device is down, it should:
a) use as few resources as possible:
- not grab memory for buffers
- not assign IRQ unless it could get one
- turn off all power consumption possible
b) allow setting parameters like speed/duplex/autonegotiation,
ring buffers, ... with ethtool, and remember the state
c) not accept data coming in, and drop packets queued
When device is up, it should:
a) Start negotiation if needed
b) Not bring up carrier till it is ready
c) Allow reconfiguration
Wake on Lan should be disabled by default, until changed.
2) Network device infrastructure should make it easier for devices:
bring interface down on suspend and bring it up after resume
(if it was running when suspended). This would allow many devices to
have no suspend/resume hook; except those that have some better power
control over hardware.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
