netdev - Re: [linux-pm] [RFC] Runtime power management on ipw2100

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]

Message-Id: <1170234787.6746.22.camel@amit-laptop>
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