From mboxrd@z Thu Jan 1 00:00:00 1970 From: Len Brown Subject: Re: Linux ACPI processor driver patch: user-definable power state limit Date: 05 Nov 2004 14:45:07 -0500 Message-ID: <1099683907.13837.1353.camel@d845pe> References: <200410112335.19159.jos.delbar@ugent.be> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200410112335.19159.jos.delbar-Cru1EgDzd7c@public.gmane.org> Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Jos Delbar Cc: ACPI Developers , Robert Moore , James P Ketrenos List-Id: linux-acpi@vger.kernel.org Jos, I agree with you that a single parameter is simpler. Another thing we need to address -- with either scheme -- is that the parameter must be set in the kernel, not in the processor modules. This is because it is necessary for modules, such as ipw2100 to be able to disable c3 automatically when they detect that it is interfering with their operation. so we'd export a function from the base kernel for modules to set the limit, and we'd simply export the value of acpi_cstate_limit for processor.c to observe at run-time. int acpi_set_cstate_limit(int limit) int acpi_cstate_limit; I think it can return the old limit so that the caller can potentially un-do its call, or perhaps setting the limit to 0 should simply mean clear any limit. cheers, -Len ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click