lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 20 Dec 2006 14:49:06 -0800
From:	Stephen Hemminger <shemminger@...l.org>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Network drivers that don't suspend on interface down

On Wed, 20 Dec 2006 16:51:39 +0100
Arjan van de Ven <arjan@...radead.org> 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 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