Bob Moore [Tue, 10 Jun 2008 06:21:05 +0000 (14:21 +0800)]
ACPICA: Fix for invalid large array index on 64-bit systems
This problem was introduced in 20080514 as a result of the
elimination of the acpi_native_uint type. Code uses a negative
array index, which should be eliminated.
Bob Moore [Tue, 10 Jun 2008 06:16:47 +0000 (14:16 +0800)]
ACPICA: Workaround for reversed _PRT entries from BIOS
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.
Bob Moore [Tue, 10 Jun 2008 04:38:10 +0000 (12:38 +0800)]
ACPICA: Fix for hang on GPE method invocation
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.
Bob Moore [Tue, 10 Jun 2008 04:25:42 +0000 (12:25 +0800)]
ACPICA: Add argument count checking to control method invocation via acpi_evaluate_object
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.
Randy Dunlap [Fri, 27 Jun 2008 02:27:21 +0000 (22:27 -0400)]
fujitsu-laptop: depends on INPUT
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
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.
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.
Johannes Berg [Wed, 11 Jun 2008 20:03:10 +0000 (22:03 +0200)]
APM emulation: Notify about all suspend events, not just APM invoked ones (v2)
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.
David Brownell [Wed, 4 Jun 2008 23:15:40 +0000 (01:15 +0200)]
ACPI PM: acpi_pm_device_sleep_state() cleanup
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.)
Carlos Corbacho [Sat, 21 Jun 2008 08:09:53 +0000 (09:09 +0100)]
acer-wmi: Add debugfs file for device detection
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.
Carlos Corbacho [Sat, 21 Jun 2008 08:09:48 +0000 (09:09 +0100)]
acer-wmi: Disable device autodetection on Fujitsu Siemens Amilo Li2732
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.
Carlos Corbacho [Sat, 21 Jun 2008 08:09:22 +0000 (09:09 +0100)]
acer-wmi: Blacklist backlight on Acer Aspire 1520 & 1360 series
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.
Bob Moore [Fri, 13 Jun 2008 00:28:55 +0000 (08:28 +0800)]
Make GPE disable more robust
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.)
Yi Yang [Sat, 14 Jun 2008 04:54:37 +0000 (00:54 -0400)]
ACPI: fix processor throttling set error
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:
Yi Yang [Sat, 14 Jun 2008 04:52:06 +0000 (00:52 -0400)]
ACPI: fix acpi fan state set error
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'.
Jonathan Woithe [Wed, 11 Jun 2008 00:44:56 +0000 (10:14 +0930)]
Fujitsu-laptop update
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.
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/.
create sysfs link from acpi device to sysdev for cpu
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=9772
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=9772
"/sys/devices/LNXSYSTM:00/.../eject" is used to evaluate _EJx method
and eject a device in user space.
But system hangs when poking the "eject" file because that
the device hot-removal code invoke the driver .remove method which will
try to remove the "eject" file as a result.
Queues the hot-removal function for deferred execution in this patch.
http://bugzilla.kernel.org/show_bug.cgi?id=9772
Merge branch 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6
* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6: (44 commits)
hwmon: (w83l786ng) Convert to a new-style i2c driver
hwmon: (w83l785ts) Convert to a new-style i2c driver
hwmon: (w83793) Convert to a new-style i2c driver
hwmon: (w83792d) Convert to a new-style i2c driver
hwmon: (w83791d) Convert to a new-style i2c driver
hwmon: (thmc50) Convert to a new-style i2c driver
hwmon: (smsc47m192) Convert to a new-style i2c driver
hwmon: (max6650) Convert to a new-style i2c driver
hwmon: (max1619) Convert to a new-style i2c driver
hwmon: (lm93) Convert to a new-style i2c driver
hwmon: (lm92) Convert to a new-style i2c driver
hwmon: (lm90) Convert to a new-style i2c driver
hwmon: (lm87) Convert to a new-style i2c driver
hwmon: (lm83) Convert to a new-style i2c driver
hwmon: (lm80) Convert to a new-style i2c driver
hwmon: (lm77) Convert to a new-style i2c driver
hwmon: (lm63) Convert to a new-style i2c driver
hwmon: (gl520sm) Convert to a new-style i2c driver
hwmon: (gl518sm) Convert to a new-style i2c driver
hwmon: (fscpos) Convert to a new-style i2c driver
...
Randy Dunlap [Wed, 16 Jul 2008 13:52:00 +0000 (08:52 -0500)]
Fix compile issues in fs/compat_ioctl.c when CONFIG_BLOCK is disabled
Fix fs/compat_ioctl.c to handle CONFIG_BLOCK=n, CONFIG_SCSI=n to avoid
build errors:
In file included from include/scsi/scsi.h:12,
from fs/compat_ioctl.c:71:
include/scsi/scsi_cmnd.h:27:25: warning: "BLK_MAX_CDB" is not defined
include/scsi/scsi_cmnd.h:28:3: error: #error MAX_COMMAND_SIZE can not be bigger than BLK_MAX_CDB
In file included from include/scsi/scsi.h:12,
from fs/compat_ioctl.c:71:
include/scsi/scsi_cmnd.h: In function 'scsi_bidi_cmnd':
include/scsi/scsi_cmnd.h:182: error: implicit declaration of function 'blk_bidi_rq'
include/scsi/scsi_cmnd.h:183: error: dereferencing pointer to incomplete type
include/scsi/scsi_cmnd.h: In function 'scsi_in':
include/scsi/scsi_cmnd.h:189: error: dereferencing pointer to incomplete type
Kumar Gala [Wed, 16 Jul 2008 13:39:12 +0000 (08:39 -0500)]
powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
If we don't enable FS_ENET we get build issues:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
Crosscompiling on a Fedora 9 machine running gcc 4.3.0 as its host compiler
and gcc 3.4.6 for the mips-linux target results in the following build
error:
$ make malta_defconfig
$ make
cc1: error: unrecognized command line option "-fno-stack-protector"
scripts/kconfig/conf -s arch/mips/Kconfig
cc1: error: unrecognized command line option "-fno-stack-protector"
The arch Makefile is included too late so the host compiler is feature
tested, not the crosscompiler as intended and thus the Makefile applies
adds -fno-stack-protector to crosscompiler's flags which fails for gcc
3.4.6. The bug was introduced by e06b8b98da071f7dd78fb7822991694288047df0
in 2.6.25; 35bb5b1e0e84cfa1a8906f7e6a77f391ff315791 did add more flags
testing before the arch Makefile inclusion.
Elias Oltmanns [Wed, 16 Jul 2008 18:33:48 +0000 (20:33 +0200)]
IDE: Report errors during drive reset back to user space
Make sure that each error condition during the execution of an
HDIO_DRIVE_RESET ioctl is actually reported to the calling process.
Also, unify the exit path of reset_pollfunc() when returning ide_stopped
since the need of ->port_ops->reset_poll() to be treated specially has
vanished (way back, it seems).
Elias Oltmanns [Wed, 16 Jul 2008 18:33:48 +0000 (20:33 +0200)]
Update documentation of HDIO_DRIVE_RESET ioctl
Alter the entry for HDIO_DRIVE_RESET in Documentation/ioctl/hdio.txt to
reflect a functional change in the driver. Besides, the entry has been
inaccurate before.
Elias Oltmanns [Wed, 16 Jul 2008 18:33:48 +0000 (20:33 +0200)]
IDE: Remove unused code
Remove some code which has been made obsolete and hasn't worked properly
before anyway. Part of the infrastructure may be reintroduced in a
follow up patch to implement a working command aborting facility.
Elias Oltmanns [Wed, 16 Jul 2008 18:33:48 +0000 (20:33 +0200)]
IDE: Fix HDIO_DRIVE_RESET handling
Currently, the code path executing an HDIO_DRIVE_RESET ioctl is broken
in various ways. Most importantly, it is treated as an out of band
request in an illegal way which may very likely lead to system lock ups.
Use the drive's request queue to avoid this problem (and fix a locking
issue for free along the way).
Adrian Bunk [Wed, 16 Jul 2008 18:33:47 +0000 (20:33 +0200)]
remove BLK_DEV_HD_ONLY
After commit 80aa31cb460d12c1e02327b43eceb3eebc6e7090
(ide: remove CONFIG_BLK_DEV_HD_IDE config option (take 2))
the indirection through BLK_DEV_HD_ONLY is no longer required.
ide-cd: move request prep from cdrom_start_rw_cont to rq issue path
... by factoring out the rq preparation code into a separate
function called in the request routine. As a nice side effect,
this minimizes the IRQ handler execution time.
There should be no functionality change resulting from this patch.
[bart: s/HWGROUP()/drive->hwif->hwgroup/ and remove extra newline]
ide-cd: move request prep from cdrom_start_seek_continuation to rq issue path
... by factoring out the rq preparation code into a separate
function called in the request routine. As a nice side effect,
this minimizes the IRQ handler execution time.
There should be no functionality change resulting from this patch.
[bart: s/HWGROUP()/drive->hwif->hwgroup/ and remove extra newlines]
ide: print message on error in ide_find_port_slot()
* Add DRV_NAME define to ide-h8300.c.
* Fix ide-h8300.c, swarm.c and sgiioc4.c to set .name field in
struct ide_port_info to DRV_NAME, then convert these host drivers
to use ide_find_port_slot() instead of ide_find_port().
* Move ecard_set_drvdata() from icside_probe() to icside_register_v{5,6}(),
then use state->ioc_base instead of hwif->hwif_data in icside_maskproc()
and icside_dma_test_irq().
While at it:
* Add sel field to struct icside_state, then use state->{sel,ioc_base}
instead of ->{select,config}_data in icside_dma_setup().
There should be no functional changes caused by this patch.
projects / linux.git / log