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  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, 31 Jan 2007 11:13:07 +0200
From:	Amit Kucheria <amit.kucheria@...ia.com>
To:	ext Matthew Garrett <mjg59@...f.ucam.org>
Cc:	ipw2100-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
	linux-pm@...ts.osdl.org
Subject: Re: [linux-pm] [RFC] Runtime power management on ipw2100

On Wed, 2007-01-31 at 07:52 +0000, ext Matthew Garrett wrote:
> Based on previous discussions, I've implemented a rough attempt at 
> providing some level of basic runtime power management on the ipw2100 
> chipset. This patch does the following:
> 
> 1) On load, it initialises the hardware and then quiesces it again
> 2) On interface up, it powers the hardware back up
> 3) On interface down, it powers the hardware down and puts the chip in 
> D3
> 4) It attempts to behave correctly over suspend/resume - ie, if the 
> interface was down beforehand, it will ensure that the chip is powered 
> down

This isn't quite runtime power management in my way of thinking. I sort
of expected this to be a fundamental characteristic of well-behaved
drivers, but then I don't have too much experience with PCI on x86
platforms.

With runtime power management, I would try to put the device into low
power states when it is UP. That's what drivers on the OMAP platform
(N800, 770) do.

What is the latency in changing between different PCI power states for
peripherals?

Would it be possible e.g. to put the peripheral into a low power state
after each Tx/Rx (with reasonable hyteresis)?

<snip>

> The situation is slightly more complicated for wired interfaces. As 
> previously discussed, we potentially want three interface states (on, 
> low power, off) with the intermediate one powering down as much of the 
> hardware as possible while still implementing link detection.

And this low power state is what the HW should be in all the time,
except when it has work to do.

Regards,
Amit
-
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