linux-stable.git/drivers/acpi, branch v3.18.10

ACPI / LPSS: provide con_id for the clkdev

2015-03-24T01:02:51+00:00

commit fcf0789a96777d79d20290e08bf43943a5619387 upstream.

Commit 7d78cbefaa (serial: 8250_dw: add ability to handle
the peripheral clock) introduces handling for a second clk
to 8250_dw.c which is the driver also for LPSS UART. The
second clk forces us to provide identifier (con_id) for the
clkdev we create.

This fixes an issue where 8250_dw.c is getting the same
handler for both clocks.

Fixes: 7d78cbefaa (serial: 8250_dw: add ability to handle the peripheral clock)
Signed-off-by: Heikki Krogerus 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / video: Load the module even if ACPI is disabled

2015-03-24T01:02:51+00:00

commit 6e17cb12881ba8d5e456b89f072dc6b70048af36 upstream.

i915.ko depends upon the acpi/video.ko module and so refuses to load if
ACPI is disabled at runtime if for example the BIOS is broken beyond
repair. acpi/video provides an optional service for i915.ko and so we
should just allow the modules to load, but do no nothing in order to let
the machines boot correctly.

Reported-by: Bill Augur 
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Acked-by: Aaron Lu 
[ rjw: Fixed up the new comment in acpi_video_init() ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / LPSS: Deassert resets for SPI host controllers on Braswell

2015-03-06T22:52:49+00:00

commit 3095794ae972bc6fc76af6cb3b864d6686b96094 upstream.

On some Braswell systems BIOS leaves resets for SPI host controllers
active. This prevents the SPI driver from transferring messages on wire.

Fix this in similar way that we do for I2C already by deasserting resets
for the SPI host controllers.

Reported-by: Yang A Fang 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / LPSS: Always disable I2C host controllers

2015-03-06T22:52:49+00:00

commit 3293c7b8ec213a640f5ea2e5efeaa2b7559b1e19 upstream.

On Baytrail and Braswell the BIOS might leave the I2C host controllers
enabled, probably because it uses them for its own purposes. This is fine
in normal cases because the I2C driver will disable the hardware when it
is probed anyway.

However, in case of suspend to disk it is different story. If the driver
happens to be compiled as a module the boot kernel never loads the driver
thus leaving host controllers enabled upon loading the hibernation image.

The I2C host controller interrupt mask register has default value of 0x8ff,
in other words it has most of the interrupts unmasked. When combined with
the fact that the host controller is enabled, the driver immediately starts
getting interrupts even before its resume hook is called (once IO-APIC is
resumed). Since the driver is not prepared for this it will crash the
kernel due to NULL pointer derefence because dev->msgs is NULL.

Unfortunately we were not able to get full backtrace to from the console
which could be reproduced here.

In order to fix this even when the driver is compiled as module, we disable
the I2C host controllers in byt_i2c_setup() before devices are created.

Reported-by: Yu Chen 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / PM: Do not disable wakeup GPEs that have not been enabled

2015-01-30T01:40:46+00:00

commit 175f8e2650f7ca6b33d338be3ccc1c00e89594ea upstream.

In some cases acpi_device_wakeup() may be called to ensure wakeup
power to be off for a given device even though that device's wakeup
GPE has not been enabled so far.  It calls acpi_disable_gpe() on a
GPE that's not enabled and this causes ACPICA to return the AE_LIMIT
status code from that call which then is reported as an error by the
ACPICA's debug facilities (if enabled).  This may lead to a fair
amount of confusion, so introduce a new ACPI device wakeup flag
to store the wakeup GPE status and avoid disabling wakeup GPEs
that have not been enabled.

Reported-and-tested-by: Venkat Raghavulu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / PM: Fix PM initialization for devices that are not present

2015-01-16T14:59:55+00:00

commit 1b1f3e1699a9886f1070f94171097ab4ccdbfc95 upstream.

If an ACPI device object whose _STA returns 0 (not present and not
functional) has _PR0 or _PS0, its power_manageable flag will be set
and acpi_bus_init_power() will return 0 for it.  Consequently, if
such a device object is passed to the ACPI device PM functions, they
will attempt to carry out the requested operation on the device,
although they should not do that for devices that are not present.

To fix that problem make acpi_bus_init_power() return an error code
for devices that are not present which will cause power_manageable to
be cleared for them as appropriate in acpi_bus_get_power_flags().
However, the lists of power resources should not be freed for the
device in that case, so modify acpi_bus_get_power_flags() to keep
those lists even if acpi_bus_init_power() returns an error.
Accordingly, when deciding whether or not the lists of power
resources need to be freed, acpi_free_power_resources_lists()
should check the power.flags.power_resources flag instead of
flags.power_manageable, so make that change too.

Furthermore, if acpi_bus_attach() sees that flags.initialized is
unset for the given device, it should reset the power management
settings of the device and re-initialize them from scratch instead
of relying on the previous settings (the device may have appeared
after being not present previously, for example), so make it use
the 'valid' flag of the D0 power state as the initial value of
flags.power_manageable for it and call acpi_bus_init_power() to
discover its current power state.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

ACPI / video: Add some Samsung models to disable_native_backlight list

2015-01-16T14:59:55+00:00

commit 7d0b93499f4879ddbc75d594f4ea216ba964f78e upstream.

Several Samsung laptop models (SAMSUNG 870Z5E/880Z5E/680Z5E and
SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V) do not have a working
native backlight control interface so restore their acpi_videoX
interface.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84221
Link: https://bugzilla.kernel.org/show_bug.cgi?id=84651
For SAMSUNG 870Z5E/880Z5E/680Z5E:
Reported-and-tested-by: Brent Saner 
Reported-by: Vitaliy Filippov 
Reported-by: Laszlo KREKACS 
For SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V:
Reported-by: Vladimir Perepechin 
Signed-off-by: Aaron Lu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / video: update the skip case for acpi_video_device_in_dod()

2015-01-16T14:59:53+00:00

commit b4df463678fb9c6dae9548dbb7545993779fd416 upstream.

If the firmware has declared more than 8 video output devices, and the
one that control the internal panel's backlight is listed after the
first 8 output devices, the _DOD will not include it due to the current
i915 operation region implementation. As a result, we will not create a
backlight device for it while we should. Solve this problem by special
case the firmware that has 8+ output devices in that if we see such a
firmware, we do not test if the device is in _DOD list. The creation of
the backlight device will also enable the firmware to emit events on
backlight hotkey press when the acpi_osi= cmdline option is specified on
those affected ASUS laptops.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=70241
Reported-and-tested-by: Oleksij Rempel 
Reported-and-tested-by: Dmitry Tunin 
Reported-and-tested-by: Jimbo 
Signed-off-by: Aaron Lu 
Acked-by: Jani Nikula 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / video: update condition to check if device is in _DOD list

2014-12-01T01:09:18+00:00

Commit 0b8db271f159 ("ACPI / video: check _DOD list when creating
backlight devices") checks if the video device is in the bind devices
list to decide if we should create backlight device for it, that causes
problem for one Dell Latitude E6410, where none of the video output
devices are properly bound due to the way how we did the comparing
between its _ADR and the _DOD's values. Solve this problem by comparing
the lower 12 bits of both the device's _ADR and the _DOD's values instead
of relying on bind result.

Fixes: 0b8db271f159 ("ACPI / video: check _DOD list when creating backlight devices")
Reported-and-tested-by: Brian Norris 
Signed-off-by: Aaron Lu 
Signed-off-by: Rafael J. Wysocki

ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up

2014-11-20T00:24:16+00:00

As reported by Dmitry, on some Chromebooks there are devices with
corresponding ACPI objects and with unusual system wakeup
configuration.  Namely, they technically are wakeup-capable, but the
wakeup is handled via a platform-specific out-of-band mechanism and
the ACPI PM layer has no information on the wakeup capability.  As
a result, device_may_wakeup(dev) called from acpi_dev_suspend_late()
returns 'true' for those devices, but the wakeup.flags.valid flag is
unset for the corresponding ACPI device objects, so acpi_device_wakeup()
reproducibly fails for them causing acpi_dev_suspend_late() to return
an error code.  The entire system suspend is then aborted and the
machines in question cannot suspend at all.

Address the problem by ignoring the device_may_wakeup(dev) return
value in acpi_dev_suspend_late() if the ACPI companion of the device
being handled has wakeup.flags.valid unset (in which case it is clear
that the wakeup is supposed to be handled by other means).

This fixes a regression introduced by commit a76e9bd89ae7 (i2c:
attach/detach I2C client device to the ACPI power domain) as the
affected systems could suspend and resume successfully before that
commit.

Fixes: a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power domain)
Reported-by: Dmitry Torokhov 
Reviewed-by: Dmitry Torokhov 
Cc: 3.13+  # 3.13+
Signed-off-by: Rafael J. Wysocki