kernel/drivers/acpi, branch linux-3.13.y

ACPI / button: Add ACPI Button event via netlink routine

2014-04-22T23:49:20Z

commit 0bf6368ee8f25826d0645c0f7a4f17c8845356a4 upstream. Commit 1696d9d (ACPI: Remove the old /proc/acpi/event interface) removed ACPI Button event which originally was sent to userspace via /proc/acpi/event. This caused ACPI shutdown regression on gentoo in VirtualBox. Now ACPI events are sent to userspace via netlink, so add ACPI Button event back via netlink routine. References: https://bugzilla.kernel.org/show_bug.cgi?id=71721 Reported-and-tested-by: Richard Musil Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / sleep: Add extra checks for HW Reduced ACPI mode sleep states

2014-03-24T04:44:12Z

commit a4e90bed511220ff601d064c9e5d583e91308f65 upstream. If the HW Reduced ACPI mode bit is set in the FADT, ACPICA uses the optional sleep control and sleep status registers for making the system enter sleep states (including S5), so it is not possible to use system sleep states or power it off using ACPI if the HW Reduced ACPI mode bit is set and those registers are not available. For this reason, add a new function, acpi_sleep_state_supported(), checking if the HW Reduced ACPI mode bit is set and whether or not system sleep states are usable in that case in addition to checking the return value of acpi_get_sleep_type_data() and make the ACPI sleep setup routines use that function to check the availability of system sleep states. Among other things, this prevents the kernel from attempting to use ACPI for powering off HW Reduced ACPI systems without the sleep control and sleep status registers, because ACPI power off doesn't have a chance to work on them. That allows alternative power off mechanisms that may actually work to be used on those systems. The affected machines include Dell Venue 8 Pro, Asus T100TA, Haswell Desktop SDP and Ivy Bridge EP Demo depot. References: https://bugzilla.kernel.org/show_bug.cgi?id=70931 Reported-by: Adam Williamson Tested-by: Aubrey Li Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / EC: Clear stale EC events on Samsung systems

2014-03-24T04:44:09Z

commit ad332c8a45330d170bb38b95209de449b31cd1b4 upstream. A number of Samsung notebooks (530Uxx/535Uxx/540Uxx/550Pxx/900Xxx/etc) continue to log events during sleep (lid open/close, AC plug/unplug, battery level change), which accumulate in the EC until a buffer fills. After the buffer is full (tests suggest it holds 8 events), GPEs stop being triggered for new events. This state persists on wake or even on power cycle, and prevents new events from being registered until the EC is manually polled. This is the root cause of a number of bugs, including AC not being detected properly, lid close not triggering suspend, and low ambient light not triggering the keyboard backlight. The bug also seemed to be responsible for performance issues on at least one user's machine. Juan Manuel Cabo found the cause of bug and the workaround of polling the EC manually on wake. The loop which clears the stale events is based on an earlier patch by Lan Tianyu (see referenced attachment). This patch: - Adds a function acpi_ec_clear() which polls the EC for stale _Q events at most ACPI_EC_CLEAR_MAX (currently 100) times. A warning is logged if this limit is reached. - Adds a flag EC_FLAGS_CLEAR_ON_RESUME which is set to 1 if the DMI system vendor is Samsung. This check could be replaced by several more specific DMI vendor/product pairs, but it's likely that the bug affects more Samsung products than just the five series mentioned above. Further, it should not be harmful to run acpi_ec_clear() on systems without the bug; it will return immediately after finding no data waiting. - Runs acpi_ec_clear() on initialisation (boot), from acpi_ec_add() - Runs acpi_ec_clear() on wake, from acpi_ec_unblock_transactions() References: https://bugzilla.kernel.org/show_bug.cgi?id=44161 References: https://bugzilla.kernel.org/show_bug.cgi?id=45461 References: https://bugzilla.kernel.org/show_bug.cgi?id=57271 References: https://bugzilla.kernel.org/attachment.cgi?id=126801 Suggested-by: Juan Manuel Cabo Signed-off-by: Kieran Clancy Reviewed-by: Lan Tianyu Reviewed-by: Dennis Jansen Tested-by: Kieran Clancy Tested-by: Juan Manuel Cabo Tested-by: Dennis Jansen Tested-by: Maurizio D'Addona Tested-by: San Zamoyski Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / resources: ignore invalid ACPI device resources

2014-03-24T04:44:09Z

commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream. ACPI table may export resource entry with 0 length. But the current code interprets this kind of resource in a wrong way. It will create a resource structure with res->end = acpi_resource->start + acpi_resource->len - 1; This patch fixes a problem on my machine that a platform device fails to be created because one of its ACPI IO resource entry (start = 0, end = 0, length = 0) is translated into a generic resource with start = 0, end = 0xffffffff. Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / processor: Rework processor throttling with work_on_cpu()

2014-03-07T06:06:23Z

commit f3ca4164529b875374c410193bbbac0ee960895f upstream. acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make sure that the (struct acpi_processor)->acpi_processor_set_throttling() callback will run on the right CPU. However, the function may be called from a worker thread already bound to a different CPU in which case that won't work. Make acpi_processor_set_throttling() use work_on_cpu() as appropriate instead of abusing set_cpus_allowed_ptr(). Reported-and-tested-by: Jiri Olsa Signed-off-by: Lan Tianyu [rjw: Changelog] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / video: Filter the _BCL table for duplicate brightness values

2014-03-07T06:06:23Z

commit bd8ba20597f0cfef3ef65c3fd2aa92ab23d4c8e1 upstream. Some devices have duplicate entries in there brightness levels table, ie on my Dell Latitude E6430 the table looks like this: [ 3.686060] acpi backlight index 0, val 80 [ 3.686095] acpi backlight index 1, val 50 [ 3.686122] acpi backlight index 2, val 5 [ 3.686147] acpi backlight index 3, val 5 [ 3.686172] acpi backlight index 4, val 5 [ 3.686197] acpi backlight index 5, val 5 [ 3.686223] acpi backlight index 6, val 5 [ 3.686248] acpi backlight index 7, val 5 [ 3.686273] acpi backlight index 8, val 6 [ 3.686332] acpi backlight index 9, val 7 [ 3.686356] acpi backlight index 10, val 8 [ 3.686380] acpi backlight index 11, val 9 etc. Notice that brightness values 0-5 are all mapped to 5. This means that if userspace writes any value between 0 and 5 to the brightness sysfs attribute and then reads it, it will always return 0, which is somewhat unexpected. This is a problem for ie gnome-settings-daemon, which uses read-modify-write logic when the users presses the brightness up or down keys. This is done this way to take brightness changes from other sources into account. On this specific laptop what happens once the brightness has been set to 0, is that gsd reads 0, adds 5, writes 5, and on the next brightness up key press again reads 0, so things get stuck at the lowest brightness setting. Filtering out the duplicate table entries, makes any write to brightness read back as the written value as one would expect, fixing this. Signed-off-by: Hans de Goede Reviewed-by: Aaron Lu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / PCI: Fix memory leak in acpi_pci_irq_enable()

2014-03-07T06:06:23Z

commit b685f3b1744061aa9ad822548ba9c674de5be7c6 upstream. acpi_pci_link_allocate_irq() can return negative gsi even if entry != NULL. For that case we have a memory leak, so free entry before returning from acpi_pci_irq_enable() for gsi < 0. Signed-off-by: Tomasz Nowicki [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API

2014-02-13T21:55:31Z

commit 49a12877d2777cadcb838981c3c4f5a424aef310 upstream. There is currently no facility in ACPI to express the hookup of voltage regulators, the expectation is that the regulators that exist in the system will be handled transparently by firmware if they need software control at all. This means that if for some reason the regulator API is enabled on such a system it should assume that any supplies that devices need are provided by the system at all relevant times without any software intervention. Tell the regulator core to make this assumption by calling regulator_has_full_constraints(). Do this as soon as we know we are using ACPI so that the information is available to the regulator core as early as possible. This will cause the regulator core to pretend that there is an always on regulator supplying any supply that is requested but that has not otherwise been mapped which is the behaviour expected on a system with ACPI. Should the ability to specify regulators be added in future revisions of ACPI then once we have support for ACPI mappings in the kernel the same assumptions will apply. It is also likely that systems will default to a mode of operation which does not require any interpretation of these mappings in order to be compatible with existing operating system releases so it should remain safe to make these assumptions even if the mappings exist but are not supported by the kernel. Signed-off-by: Mark Brown Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

Revert "ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs"

2014-01-18T13:04:58Z

This reverts commit f6308b36c411 (ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs), because it causes the Alan Cox' ASUS T100TA to "crash and burn" during boot if the Baytrail pinctrl driver is compiled in. Fixes: f6308b36c411 (ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs) Reported-by: One Thousand Gnomes Requested-by: Linus Walleij Signed-off-by: Rafael J. Wysocki

Merge branches 'acpi-battery' and 'pm-cpufreq'

2014-01-06T21:49:08Z

* acpi-battery: ACPI / Battery: Add a _BIX quirk for NEC LZ750/LS * pm-cpufreq: intel_pstate: Add X86_FEATURE_APERFMPERF to cpu match parameters.