- 16 Jul, 2008 40 commits
-
-
Bob Moore authored
Some BIOSs erroneously reverse the _PRT SourceName and the SourceIndex. Detect and repair this problem. MS ACPI also allows and repairs this problem, thus ACPICA must also. Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Lin Ming <ming.m.lin@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Bob Moore authored
Update version to 20080514 Signed-off-by:
-
Bob Moore authored
Mostly MODULE_NAME and printf format strings. Signed-off-by:
-
Bob Moore authored
Remove pointer cast warnings and fix for a debug printf. Signed-off-by:
-
Bob Moore authored
From lint. Signed-off-by:
-
Bob Moore authored
No longer needed; replaced mostly with u32, but also acpi_size where a type that changes 32/64 bit on 32/64-bit platforms is required. v2: Fix a cast of a 32-bit int to a pointer in ACPI to avoid a compiler warning. from David Howells Signed-off-by:
-
Bob Moore authored
Added NULL fields to the exception string arrays to eliminate the -1 subtraction on the SubStatus field. Signed-off-by:
-
Jan Beulich authored
Changed ACPI_MODULE_NAME and ACPI_FUNCTION_NAME to use arrays of strings instead of pointers to static strings. Jan Beulich and Bob Moore. Signed-off-by:
-
Bob Moore authored
Fixes problem where the new method argument count validation mechanism will enter an infinite loop when a GPE method is dispatched. Problem fixed be removing the obsolete code that passes GPE block information to the notify handler via the control method parameter pointer. Signed-off-by:
-
Bob Moore authored
Error if too few arguments, warning if too many. This applies only to external programmatic control method execution, not method-to-method calls within the AML. Signed-off-by:
-
Randy Dunlap authored
fujitsu-laptop uses input_* functions, so it should depend on INPUT. drivers/built-in.o: In function `acpi_fujitsu_add': fujitsu-laptop.c:(.text+0xaaec7): undefined reference to `input_allocate_device' fujitsu-laptop.c:(.text+0xaaf39): undefined reference to `input_register_device' fujitsu-laptop.c:(.text+0xab025): undefined reference to `input_free_device' drivers/built-in.o: In function `acpi_fujitsu_notify': fujitsu-laptop.c:(.text+0xab0d8): undefined reference to `input_event' fujitsu-laptop.c:(.text+0xab0e5): undefined reference to `input_event' fujitsu-laptop.c:(.text+0xab0f5): undefined reference to `input_event' fujitsu-laptop.c:(.text+0xab102): undefined reference to `input_event' drivers/built-in.o: In function `acpi_fujitsu_hotkey_notify': fujitsu-laptop.c:(.text+0xab261): undefined reference to `input_event' drivers/built-in.o:fujitsu-laptop.c:(.text+0xab26e): more undefined references to `input_event' follow drivers/built-in.o: In function `acpi_fujitsu_hotkey_add': fujitsu-laptop.c:(.text+0xab49c): undefined reference to `input_allocate_device' fujitsu-laptop.c:(.text+0xab51a): undefined reference to `input_register_device' fujitsu-laptop.c:(.text+0xab5e4): undefined reference to `input_free_device' make[1]: *** [.tmp_vmlinux1] Error 1 Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Jonathan Woithe <jwoithe@physics.adelaide.edu.au> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Rafael J. Wysocki authored
We can avoid taking the BKL in snapshot_ioctl() if pm_mutex is used to prevent the ioctls from being executed concurrently. In addition, although it is only possible to open /dev/snapshot once, the task which has done that may spawn a child that will inherit the open descriptor, so in theory they can call snapshot_write(), snapshot_read() and snapshot_release() concurrently. pm_mutex can also be used for mutual exclusion in such cases. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Alan Cox authored
Push BKL down into ioctl handlers - snapshot device. Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Rafael J. Wysocki authored
The freezer currently attempts to distinguish kernel threads from user space tasks by checking if their mm pointer is unset and it does not send fake signals to kernel threads. However, there are kernel threads, mostly related to networking, that behave like user space tasks and may want to be sent a fake signal to be frozen. Introduce the new process flag PF_FREEZER_NOSIG that will be set by default for all kernel threads and make the freezer only send fake signals to the tasks having PF_FREEZER_NOSIG unset. Provide the set_freezable_with_signal() function to be called by the kernel threads that want to be sent a fake signal for freezing. This patch should not change the freezer's observable behavior. Signed-off-by:
-
Johannes Berg authored
This revamps the apm-emulation code to get suspend notifications regardless of what way pm_suspend() was invoked, whether via the apm ioctl or via /sys/power/state. Also do some code cleanup and add comments while at it. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Rafael J. Wysocki authored
Remove the obsolete workaround for a Toshiba Satellite 4030cdt S1 problem from drivers/acpi/sleep/main.c . Signed-off-by:
-
Rafael J. Wysocki authored
Since the second argument of acpi_pci_choose_state() and platform_pci_choose_state() is never used, remove it. Signed-off-by:
-
David Brownell authored
Get rid of a superfluous acpi_pm_device_sleep_state() parameter. The only legitimate value of that parameter must be derived from the first parameter, which is what all the callers already do. (However, this does not address the fact that ACPI still doesn't set up those flags.) Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Len Brown authored
Signed-off-by:
-
Vegard Nossum authored
Ingo Molnar wrote: > -tip auto-testing started triggering this spinlock corruption message > yesterday: > > [ 3.976213] calling acpi_rtc_init+0x0/0xd3 > [ 3.980213] ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread F7C50000 could not acquire Mutex [3] [20080321] > [ 3.992213] BUG: spinlock bad magic on CPU#0, swapper/1 > [ 3.992213] lock: c2508dc4, .magic: 00000000, .owner: swapper/1, .owner_cpu: 0 This is apparently because some parts of ACPI, including mutexes, are not initialized when acpi=off is passed to the kernel. Reported-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by:
-
Carlos Corbacho authored
It doesn't make much sense these days. Signed-off-by:
Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by:
-
Carlos Corbacho authored
Add a debugfs file for showing the full results of the method we use to detect devices on WMID laptops. This should be useful in the case that a Linux user gets an Acer laptop with 3G support (and/ or people who enjoy ripping their wireless cards out) so we can get some feedback on how this value changes in these cases. (At the moment, we always enable the wireless and 3G control. In the case of the former, this is fairly safe. In the case of the latter though, trying to toggle this device if it doesn't exist on a laptop causes ACPI warnings/ errors). To summarise: If you have an Acer laptop with a built in 3G card, please report back the value from this file. Signed-off-by:
-
Carlos Corbacho authored
The AMW0 (V1) device detection method doesn't work properly on this laptop, so disable it, and for other laptops that may have this problem, by switching on a strange GUID. Signed-off-by:
-
Carlos Corbacho authored
This laptop needs a different EC quirk from the standard Acer one to read the wireless status. Signed-off-by:
-
Carlos Corbacho authored
If the framebuffer has requested blanking, turn the backlight down. Also offer the user the option to do this. Reported-by:
Michal Pecio <michal.pecio@gmail.com> Signed-off-by:
-
Carlos Corbacho authored
A newer BIOS for these laptops adds ACPI-WMI support to them. However, it does not add support for the backlight via the EC, and we have no way to detect this on older machines, so blacklist it from them. Signed-off-by:
-
Carlos Corbacho authored
This should have been removed when the colour was removed from the LED device name. Signed-off-by:
-
Adrian Bunk authored
make the needlessly global cm_{g,s}etv[] static. Signed-off-by:Adrian Bunk <bunk@kernel.org> Signed-off-by:
-
Vegard Nossum authored
Reorder the mutex names to match the preceding #defines Signed-off-by:
-
Bob Moore authored
Implemented another change for the GPE disable. We now perform a read-change-write of the enable register instead of simply writing out the cached enable mask. This will prevent inadvertent enabling of GPEs if a rogue GPE is received during initialization (before GPE handlers are installed.) http://bugzilla.kernel.org/show_bug.cgi?id=6217Signed-off-by:
-
Cezary Jackiewicz authored
Signed-off-by:
Cezary Jackiewicz <cezary.jackiewicz@gmail.com> Signed-off-by:
-
Randy Dunlap authored
Fix printk format warning: linux-next-20080617/drivers/acpi/processor_throttling.c:1258: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' Signed-off-by:
-
Yi Yang authored
http://bugzilla.kernel.org/show_bug.cgi?id=9704 When echo some invalid values to /proc/acpi/processor/*/throttling, there isn't any error info returned, on the contray, it sets throttling value to some T* successfully, obviously, this is incorrect, a correct way should be to let it fail and return error info. This patch fixed the aforementioned issue, it also enables /proc/acpi/processor/*/throttling to accept such values as 't0' and 'T0', it also strictly limits /proc/acpi/processor/*/throttling only to accept "*", "t*" and "T*", "*" is the throttling state value the processor can support, current, it is 0 - 7. Before applying this patch, the test result is below: [root@localhost acpi]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T1 state available: T0 to T7 states: T0: 100% *T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost acpi]# echo "1xxxxxx" > /proc/acpi/processor/CPU0/throttling [root@localhost acpi]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T1 state available: T0 to T7 states: T0: 100% *T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost acpi]# echo "0" > /proc/acpi/processor/CPU0/throttling [root@localhost acpi]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost acpi]# cd / [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost /]# echo "T0" > /proc/acpi/processor/CPU0/throttling [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost /]# echo "T7" > /proc/acpi/processor/CPU0/throttling [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost /]# echo "T100" > /proc/acpi/processor/CPU0/throttling [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost /]# echo "xxx" > /proc/acpi/processor/CPU0/throttling [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost /]# echo "2xxxx" > /proc/acpi/processor/CPU0/throttling [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T2 state available: T0 to T7 states: T0: 100% T1: 87% *T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost /]# echo "" > /proc/acpi/processor/CPU0/throttling [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost /]# echo "7777" > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost /]# echo "7xxx" > /proc/acpi/processor/CPU0/throttling [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T7 state available: T0 to T7 states: T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% *T7: 12% [root@localhost /]# After applying this patch, the test result is below: [root@localhost linux-2.6.24-rc6]# echo > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# echo "" > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# echo "0" > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# echo "t0" > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# echo "T0" > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [root@localhost linux-2.6.24-rc6]# echo "T7" > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T7 state available: T0 to T7 states: T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% *T7: 12% [root@localhost linux-2.6.24-rc6]# echo "T8" > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# vi drivers/acpi/processor_throttling.c [root@localhost linux-2.6.24-rc6]# echo "T8" > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# echo "t7" > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# echo "t70" > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# echo "70" > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# echo "7000" > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# echo "70" > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# echo "xxx" > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# echo > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# echo -n > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# echo -n "" > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# echo $? 0 [root@localhost linux-2.6.24-rc6]# echo -n "" > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T7 state available: T0 to T7 states: T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% *T7: 12% [root@localhost linux-2.6.24-rc6]# echo -n "" > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T7 state available: T0 to T7 states: T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% *T7: 12% [root@localhost linux-2.6.24-rc6]# echo t0 > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# echo T0 > /proc/acpi/processor/CPU0/throttling [root@localhost linux-2.6.24-rc6]# echo Tt0 > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# echo T > /proc/acpi/processor/CPU0/throttling -bash: echo: write error: Invalid argument [root@localhost linux-2.6.24-rc6]# Signed-off-by:
Yi Yang <yi.y.yang@intel.com> Signed-off-by:
-
Yi Yang authored
Under /proc/acpi, there is a fan control interface, a user can set 0 or 3 to /proc/acpi/fan/*/state, 0 denotes D0 state, 3 denotes D3 state, but in current implementation, a user can set a fan to D1 state by any char excluding '1', '2' and '3'. For example: [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: off [root@localhost acpi]# echo "" > /proc/acpi/fan/C31B/state [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: on [root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: off [root@localhost acpi]# echo "xxxxx" > /proc/acpi/fan/C31B/state [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: on Obviously, such inputs as "" and "xxxxx" are invalid for fan state. This patch fixes this issue, it strictly limits fan state only to accept 0, 1, 2 and 3, any other inputs are invalid. Before applying this patch, the test result is: [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: off [root@localhost acpi]# echo "" > /proc/acpi/fan/C31B/state [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: on [root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: off [root@localhost acpi]# echo "xxxxx" > /proc/acpi/fan/C31B/state [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: on [root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: off [root@localhost acpi]# echo "3x" > /proc/acpi/fan/C31B/state [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: off [root@localhost acpi]# echo "-1x" > /proc/acpi/fan/C31B/state [root@localhost acpi]# cat /proc/acpi/fan/C31B/state status: on [root@localhost acpi]# After applying this patch, the test result is: [root@localhost ~]# cat /proc/acpi/fan/C31B/state status: off [root@localhost ~]# echo "" > /proc/acpi/fan/C31B/state -bash: echo: write error: Invalid argument [root@localhost ~]# cat /proc/acpi/fan/C31B/state status: off [root@localhost ~]# echo "3" > /proc/acpi/fan/C31B/state [root@localhost ~]# cat /proc/acpi/fan/C31B/state status: off [root@localhost ~]# echo "xxxxx" > /proc/acpi/fan/C31B/state -bash: echo: write error: Invalid argument [root@localhost ~]# cat /proc/acpi/fan/C31B/state status: off [root@localhost ~]# echo "-1x" > /proc/acpi/fan/C31B/state -bash: echo: write error: Invalid argument [root@localhost ~]# cat /proc/acpi/fan/C31B/state status: off [root@localhost ~]# echo "0" > //proc/acpi/fan/C31B/state [root@localhost ~]# cat /proc/acpi/fan/C31B/state status: on [root@localhost ~]# echo "4" > //proc/acpi/fan/C31B/state -bash: echo: write error: Invalid argument [root@localhost ~]# cat /proc/acpi/fan/C31B/state status: on [root@localhost ~]# echo "3" > //proc/acpi/fan/C31B/state [root@localhost ~]# cat /proc/acpi/fan/C31B/state status: off [root@localhost ~]# echo "0" > //proc/acpi/fan/C31B/state [root@localhost ~]# cat /proc/acpi/fan/C31B/state status: on [root@localhost ~]# echo "3x" > //proc/acpi/fan/C31B/state -bash: echo: write error: Invalid argument [root@localhost ~]# Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Alok N Kataria authored
http://bugzilla.kernel.org/show_bug.cgi?id=9772Signed-off-by:
Alok N Kataria <akataria@vmware.com> Signed-off-by:
-
Jonathan Woithe authored
Add additional capabilities to the Fujitsu-laptop driver. * Brightness hotkey actions are sent to userspace. This can be disabled using a module parameter if it causes issues with models which handle these keys transparently in the BIOS. * Actions of additional hotkeys found on some Fujitsu models (eg: the suspend key and the dedicated "power on passphrase" keys) are broadcast to userspace. * An alternative brightness control method used by some Fujitsu models (for example, the S6410) is now supported, enabling software brightness controls on models using this method. * DMI-based module aliases are configured for the S6410 and S7020. * The current LCD brightness after booting should now be reflected in the standard backlight interface sysfs file (previously it was always set to 0). The platform brightness sysfs interface has always been fine. Thanks go to Peter Gruber who provided a significant portion of this code and tested various iterations of the patch on his S6410. Signed-off-by:
Peter Gruber <nokos@gmx.net> Signed-off-by:
-
Mike Travis authored
Change processors from an array sized by NR_CPUS to a per_cpu variable. Signed-off-by:
Mike Travis <travis@sgi.com> Signed-off-by:
-
Cezary Jackiewicz authored
This is driver for Compal Laptop: FL90/IFL90, based on MSI driver. This driver exports a few files in /sys/devices/platform/compal-laptop/: lcd_level - screen brightness: contains a single integer in the range 0..7 (rw) wlan - wlan subsystem state: contains 0 or 1 (rw) bluetooth - bluetooth subsystem state: contains 0 or 1 (rw) raw - raw value taken from embedded controller register (ro) In addition to these platform device attributes the driver registers itself in the Linux backlight control subsystem and is available to userspace under /sys/class/backlight/compal-laptop/. Signed-off-by:
-
Zhang Rui authored
Sys I/F under acpi device node and sysdev device node are both needed for cpu hot-removal. User space need this link so that they know they are poking the sys I/F for the same cpu. http://bugzilla.kernel.org/show_bug.cgi?id=9772Signed-off-by:
-
Zhang Rui authored
The ACPI device node for the cpu has already been unregistered when acpi_processor_handle_eject is called. Thus we should offline the cpu and continue, rather than a failure here. http://bugzilla.kernel.org/show_bug.cgi?id=9772Signed-off-by:
-
