On Wed, 20 Dec 2006 16:51:39 +0100
Arjan van de Ven [off-list ref] wrote:

quoted

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.