This patch cleans up the recently added backlight device support by Holger
Macht <hmacht@suse.de> to fit well with the rest of the code, using the
ibms struct as the other "subdrivers" in ibm-acpi.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch makes it possible to disable ibm-acpi non-generic bay support,
as generic bay support already works well for a number of ThinkPads.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch adds support for the ultrabay on the T60, X60 and other new
ThinkPads that have a SATA ultrabay.
I intend to keep bay and dock support in ibm-acpi working and updated until
it finally gets deprecated and removed in favour of the generic dock and
bay support. But we aren't there yet.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch implements a fan control safety watchdog, by request of the
authors of userspace fan control scripts.
When the watchdog timer expires, the equivalent action of a "fan enable"
command is executed. The watchdog timer is reset at every reception of a
fan control command that could change the state of the fan itself.
This command is meant to be used by userspace fan control daemons, to make
sure the fan is never left set to an unsafe level because of userspace
problems.
Users of the X31/X40/X41 "speed" command are on their own, the current
implementation of "speed" is just too incomplete to be used safely,
anyway. Better to never use it, and just use the "level" command instead.
The watchdog is programmed using echo "watchdog <number>" > fan, where
number is the number of seconds to wait before doing an "enable", and zero
disables the watchdog.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
A few ThinkPads fail to initialize EC register 0x2f both in the EC
firmware and ACPI DSDT. If the BIOS and the ACPI DSDT also do not
initialize it, then the initial status of that register does not
correspond to reality.
On all reported buggy machines, EC 0x2f will read 0x07 (fan level 7) upon
cold boot, when the EC is actually in mode 0x80 (auto mode). Since
returning a text string ("unknown") would break a number of userspace
programs, instead we correct the reading for the most probably correct
answer, and return it is in auto mode.
The workaround flags the status and level as unknown on module load/kernel
boot, until we are certain at least one fan control command was issued,
either by us, or by something else.
We don't work around the bug by doing a "fan enable" at module
load/startup (which would initialize the EC register) because it is not
known if these ThinkPad ACPI DSDT might have set the fan to level 7
instead of "auto" (we don't know if they can do this or not) due to a
thermal condition, and we don't want to override that, should they be
capable of it.
We should be setting the workaround flag to "status known" upon resume, as
both reports and a exaustive search on the DSDT tables at acpi.sf.net show
that the DSDTs always enable the fan on resume, thus working around the
bug. But since we don't have suspend/resume handlers in ibm-acpi yet and
the "EC register 0x2f was modified" logic is likely to catch the change
anyway, we don't.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch changes the ThinkPad Embedded Controller DMI matching
code to store the firmware version of the EC for later usage, e.g.
for quirks.
It also prints the firmware version when starting up.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch extend fan control functions, implementing enable/disable for
all write access modes, implementing level control for all level-capable
write access modes.
The patch also updates the documentation, explaining levels auto and
disengaged.
ABI changes:
1. Support level 0 as an equivalent to disable
2. Add support for level auto and level disengaged when doing
EC 0x2f fan control
3. Support enable/disable for all level-based write access modes
4. Add support for level command on FANS thinkpads, as per
thinkwiki reports
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch fix fan enable to attempt to do the right thing and not slow
down the fan if it is forced to the maximum speed. It also extends fan
enable to work on older thinkpads.
ABI changes:
1. Support enable/disable for all level-based write access modes
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch fixes fan_read to return correct values for all fan access
modes. It also implements some fan access mode status output that was
missing, and normalizes the proc fan abi to return consistent data across
all fan read/write modes.
Userspace ABI changes and extensions:
1. Return status: enable/disable for *all* modes
(this actually improves compatibility with userspace utils!)
2. Return level: auto and level: disengaged for EC 2f access mode
3. Return level: <number> for EC 0x2f access mode
4. Return level 0 as well as "disabled" in level-aware modes
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch cleans up fan_write so that it is much easier to read and
extend. It separates the proc api handling from the operations themselves.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch breaks fan_read mechanics into a generic function to get fan
status and speed, and leaves only the procfs interface code in fan_read.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch cleans up fan_read so that it is much easier to read and
extend.
The patch fixes the userspace ABI to return "status: not supported" (like
all other ibm-acpi functions) when neither fan status or fan control are
possible.
It also fixes the userspace ABI to return EIO if ACPI access to the EC
fails, instead of returning "status: unreadable" or "speed: unreadable".
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch lays some groundwork for a fan_read and fan_write cleanup in the
next patches. To do so, it provides a new fan_init initializer, and also some
constants (through enums).
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch extends ibm-acpi to support reading thermal sensors directly
through ACPI EC register access. It uses a DMI match to detect ThinkPads
with a new-style embedded controller, that are known to have forward-
compatible register maps and use 0x00 to fill in non-used registers and
export thermal sensors at EC offsets 0x78-7F and 0xC0-C7.
Direct ACPI EC register access is implemented for 8-sensor and 16-sensor
new-style ThinkPad controller firmwares as an experimental feature. The
code does some limited sanity checks on the temperatures read through EC
access, and will default to the old ACPI TMP0-7 mode if anything is amiss.
Userspace ABI is not changed for 8 sensors, but /proc/acpi/ibm/thermal is
extended for 16 sensors if the firmware supports 16 sensors.
A documentation update is also provided.
The information about the ThinkPad register map was determined by studying
ibm-acpi "ecdump" output from various ThinkPad models, submitted by
subscribers of the linux-thinkpad mailinglist. Futher information was
gathered from the DSDT tables, as they describe the EC register map in
recent ThinkPads.
DSDT source shows that TMP0-7 access and direct register access are
actually the same thing on these firmwares, but unfortunately IBM never
did update their DSDT EC register map to export TMP8-TMP15 for the second
range of sensors.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
This patch consolidades all decisions regarding the strategy to be used to
read thinkpad thermal sensors into a single enum, and refactors the
thermal sensor reading code to use a much more readable (and easier to
extend) switch() construct, in a separate function.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
ibm-acpi uses sub-device names like ibm/hotkey, which get in the way of
a sysfs conversion. Fix it to use ibm_hotkey instead. Thanks to Zhang
Rui for noticing this.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Add support for the generic backlight interface below /sys/class/backlight.
Keep the procfs brightness handling for backward compatibility.
To achive this, add two generic functions get_lcd and set_lcd
to be used both by the procfs related and the sysfs related methods.
[apw@shadowen.org: backlight users need to select BACKLIGHT_CLASS_DEVICE]
Signed-off-by: Holger Macht <hmacht@suse.de>
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Add support for the generic backlight interface below /sys/class/backlight.
Keep the procfs brightness handling for backward compatibility.
[apw@shadowen.org: backlight users need to select BACKLIGHT_CLASS_DEVICE]
Signed-off-by: Holger Macht <hmacht@suse.de>
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Add support for the generic backlight interface below /sys/class/backlight.
The patch keeps the procfs brightness handling for backward compatibility.
Add two generic functions brightness_get and brightness_set
to be used both by the procfs related and the sysfs related methods.
[apw@shadowen.org: backlight users need to select BACKLIGHT_CLASS_DEVICE]
Signed-off-by: Holger Macht <hmacht@suse.de>
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
I wrote a patch to avoid redundant memory hot-add call at boot time. This
was cause of strange fail message of memory hotplug like "ACPI: add_memory
failed". Memory is recognized by early boot code with EFI/E820.
But, if DSDT describes memory devices for them, then hot-add code is called
for already recognized memory, and it shows fail messages with -EEXIST.
So, sys admin will misunderstand this message as something wrong by it.
This patch avoids them by preventing redundant hot-add call until
completion of driver initialization.
[akpm@osdl.org: cleanups]
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I suppose this message seems quite useless except debugging. It just shows
"Hotplug Mem Device". System admin can't know anything by this message.
So, I would like to change it to KERN_DEBUG.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch breaks C-state discovery on my IBM IntelliStation Z30 because
the return value of acpi_processor_get_power_info_fadt is not assigned to
"result" in the case that acpi_processor_get_power_info_cst returns
-ENODEV. Thus, if ACPI provides C-state data via the FADT and not _CST (as
is the case on this machine), we incorrectly exit the function with -ENODEV
after reading the FADT. The attached patch sets the value of result so
that we don't exit early.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Acked-by: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Acked-by: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
drivers/acpi/processor_idle.c:1112: warning: 'smp_callback' defined but not used
Cc: Len Brown <lenb@kernel.org>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add ->resume method to the ACPI battery handler to check
if the battery state has changed during sleep.
If yes, update the ACPI internal data structures
for benefit of /proc/acpi/battery/.
Signed-off-by: Jiri Kosina <jikos@jikos.cz>
Cc: Stefan Seyfried <seife@suse.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
I could not get correct PCI Express bus number from the structure of
acpi_object_extra. I always get zero as bus number regardless of bus
location. I found that there is incorrect comparison with _HID (PNP0A08) in
acpi/events/evrgnini.c and PCI Express _BBN method always fail.
Therefore, we always get zero as PCI Express bus number.
http://bugzilla.kernel.org/show_bug.cgi?id=7145
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This reporting is useless (we errno anyway).
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
ICC complains about a "Pointless comparsion of unsigned interger with zero"
@ line 760 & 808 of asus_acpi.c
parse_arg() mentioned below returns -E but it's copied into unsigned variable...
Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix printk format warnings in drivers/acpi:
drivers/acpi/tables/tbget.c:326: warning: format '%X' expects type 'unsigned int', but argument 5 has type 'long unsigned int'
drivers/acpi/tables/tbrsdt.c:189: warning: format '%X' expects type 'unsigned int', but argument 5 has type 'long unsigned int'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
The ACPI processor init functions should be marked as __cpuinit as they use
structures marked with __cpuinitdata.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_pci_link_set() allocates both with interrupts on
and with interrupts off (resume-time), so check interrupts
and decide on GFP_ATOMIC or GFP_KERNEL at run-time.
Signed-off-by: Jiri Kosina <jikos@jikos.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
device was set to null and used before set in a debug printk
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>
On acquiring the ACPI global lock, if there were sleepers on the lock,
we used to use acpi_os_execute() to defer a thread which would signal
sleepers. Now just signal the semaphore directly.
http://bugzilla.kernel.org/show_bug.cgi?id=5534#c159
Signed-off-by: Len Brown <len.brown@intel.com>
Simplify acpi_hw_low_level_xxx() functions to inb() and outb().
Signed-off-by: Alexey Y. Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
