This patch reworks laptop model detection.
This addresses the Samsung P30 issue, where the INIT method would return no
object, but the implicit return in the AML interpreter would confuse the
driver. It also accounts for a newer batch of Asus models whose INIT
returns ACPI_TYPE_BUFFER instead of STRING.
The handling is now much leaner, if we get a buffer or a string, we check
against known values, in every other case we use a different path
(currently DSDT signatures). The bulk of this patch is separating the
string matching from asus_hotk_get_info() into a separate function.
This patch properly fixes http://bugme.osdl.org/show_bug.cgi?id=5067 and
http://bugme.osdl.org/show_bug.cgi?id=5092 and makes the driver fully
functional again with acpi=strict on all machines.
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds support for Asus L5D and thus fixes
http://bugme.osdl.org/show_bug.cgi?id=4695
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch creates a new file named "bluetooth" under /proc/acpi/asus/.
This file controls both the internal Bluetooth adapter's presence on the
USB bus and the associated LED.
echo 1 > /proc/acpi/asus/bluetooth to enable, 0 to disable.
Additionally, the patch add support for Asus W5A, the first model that uses
this feature.
Patch originally by Fernando A. P. Gomes.
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds support for Asus A4G.
Originally by Giuseppe Rota.
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds handling for front LED displays found on W1N and the like.
Additionally, W1N is given its own model_data instance.
Patch originally by Éric Burghard.
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch updates the version string, copyright notices and does
whitespace cleanup (it looks weird, blame Lindent).
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
- Use it instead of acpi_bus_get_device() in acpi_video_bus_notify()
and use the one from struct acpi_video_device in
acpi_video_device_notify().
Signed-off-by: Patrick Mochel <mochel@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
- Use it instead of acpi_bus_get_device() where we can..
Signed-off-by: Patrick Mochel <mochel@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
- Use it instead of acpi_bus_get_device() where we can..
Signed-off-by: Patrick Mochel <mochel@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
While trying to look for superfluous I/O accesses that can be optimized
away, I stumbled upon this ACPI sleep I/O access and couldn't figure out
why the hell this dummy op was necessary.
After more than one hour of internet research, I had collected a sufficient
number of documents (among those very old kernel versions) that finally
told me what this dummy read was about: STPCLK# doesn't get asserted in time
on (some) chipsets, which is why we need to have a dummy I/O read to delay
further instruction processing until the CPU is fully stopped.
Signed-off-by: Andreas Mohr <andi@lisas.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Only if bus master activity is going on at the present, we should avoid
entering C3-type sleep, as it might be a faulty transition. As long as the
bm_activity bitmask was based on the number of calls to the ACPI idle
function, looking at previous moments made sense. Now, with it being based on
what happened this jiffy, looking at this jiffy should be sufficient.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
