IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Prevent platform devices from being created for ACPI containers
if CONFIG_ACPI_CONTAINER is unset by compiling out the container
scan handler's callbacks only in that case and still compiling
its device ID list in and registering the scan handler in either
case.
This change is based on a prototype from Zhang Rui.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently, some scan handlers can be compiled out entirely, which
leaves the device objects they normally attach to without a scan
handler. This isn't a problem as long as we don't have any default
enumeration mechanism that applies to all devices without a scan
handler. However, if such a default enumeration is added, it still
should not be applied to devices that are normally attached to by
scan handlers, because that may result in creating "physical" device
objects of a wrong type for them.
Since we are going to create platform device objects for all ACPI
device objects with pnp.type.platform_id set by default, clear
pnp.type.platform_id where there is a matching scan handler without
an .attach() callback and otherwise simply treat that scan handler
as though the .attach() callback was present but always returned 0.
This will allow us to compile out scan handler callbacks and leave
the device ID lists used by them so as to prevent creating platform
device objects for the matching ACPI devices.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Only certain types of ACPI device objects can be enumerated as
platform devices, so in order to distinguish them from the others
introduce a new ACPI device PNP type flag, platform_id, and set it
for devices with a valid _HID to start with.
This change is based on a Zhang Rui's prototype.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The "serial" PNP driver supports some "unknown" PNP modems
(PNPCXXX/PNPDXXX) by matching magic strings in the PNP device name
or the PNP device card name.
ACPI enumerated PNP devices neither are PNP cards, nor have those
magic strings in device names, so this mechamism never actually works
for ACPI enumerated PNPCXXX/PNPDXXX devices.
Consequently, it is safe to remove those two IDs from the PNP ACPI scan
handler's device ID list.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The PNP ACPI scan handler device ID list includes all the IDs from
all of the struct pnp_device_id instances in the tree, but some of
them do not follow the ACPI PNP ID rule (3 letters + 4 hex digits).
For those IDs, the coressponding devices will never be enumerated
via ACPI, so it is safe to remove them from the PNP ACPI ID list.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
ACPI can be used to enumerate PNP devices, but the code does not
handle this in the right way currently. Namely, if an ACPI device
object
1. Has a _CRS method,
2. Has an identification of
"three capital characters followed by four hex digits",
3. Is not in the excluded IDs list,
it will be enumerated to PNP bus (that is, a PNP device object will
be create for it). This means that, actually, the PNP bus type is
used as the default bus type for enumerating _HID devices in ACPI.
However, more and more _HID devices need to be enumerated to the
platform bus instead (that is, platform device objects need to be
created for them). As a result, the device ID list in acpi_platform.c
is used to enforce creating platform device objects rather than PNP
device objects for matching devices. That list has been continuously
growing recently, unfortunately, and it is pretty much guaranteed to
grow even more in the future.
To address that problem it is better to enumerate _HID devices
as platform devices by default. To this end, change the way of
enumerating PNP devices by adding a PNP ACPI scan handler that
will use a device ID list to create PNP devices for the ACPI
device objects whose device IDs are present in that list.
The initial device ID list in the PNP ACPI scan handler contains
all of the pnp_device_id strings from all the existing PNP drivers,
so this change should be transparent to the PNP core and all of the
PNP drivers. Still, in the future it should be possible to reduce
its size by converting PNP drivers that need not be PNP for any
technical reasons into platform drivers.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Introduce a .match() callback for ACPI scan handlers to allow them to
use more elaborate matching algorithms if necessary. That is needed
for the upcoming PNP scan handler in particular.
This change is based on a Zhang Rui's prototype.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
ACPI Battery device receives notifications from firmware frequently,
and most of these notifications are some general events, like battery
remaining capacity change, etc, which should not wake the system up
if the system is in suspend/hibernate state.
This causes a problem that the system wakes up from suspend to freeze
shortly, because there is an ACPI battery notification every 10 seconds.
Fix the problem in this patch by registering ACPI battery device'
own wakeup source, and waking up the system only when the battery remaining
capacity is critical low, or lower than the alarm capacity set via _BTP.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=76221
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI battery device receives notifications when
1. the remaining battery capacity becomes critical low
2. the trip point set by the _BTP (Design capacity of Warning by default)
is reached or crossed.
So it is able to support POWER_SUPPLY_PROP_CAPACITY_LEVEL to report
POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL,
POWER_SUPPLY_CAPACITY_LEVEL_LOW,
POWER_SUPPLY_CAPACITY_LEVEL_NORMAL,
POWER_SUPPLY_CAPACITY_LEVEL_FULL,
capacity levels to power supply core and user space.
Introduce support for POWER_SUPPLY_PROP_CAPACITY_LEVEL in this patch.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA doesn't include protections around address space checking, Linux
build tests always complain increased sparse warnings around ACPICA
internal acpi_os_map/unmap_memory() invocations. This patch tries to fix
this issue permanently.
There are 2 choices left for us to solve this issue:
1. Add __iomem address space awareness into ACPICA.
2. Remove sparse checker of __iomem from ACPICA source code.
This patch chooses solution 2, because:
1. Most of the acpi_os_map/unmap_memory() invocations are used for ACPICA.
table mappings, which in fact are not IO addresses.
2. The only IO addresses usage is for "system memory space" mapping code in:
drivers/acpi/acpica/exregion.c
drivers/acpi/acpica/evrgnini.c
drivers/acpi/acpica/exregion.c
The mapped address is accessed in the handler of "system memory space"
- acpi_ex_system_memory_space_handler(). This function in fact can be
changed to invoke acpi_os_read/write_memory() so that __iomem can
always be type-casted in the OSL layer.
According to the above investigation, we drew the following conclusion:
It is not a good idea to introduce __iomem address space awareness into
ACPICA mostly in order to protect non-IO addresses.
We can simply remove __iomem for acpi_os_map/unmap_memory() to remove
__iomem checker for ACPICA code. Then we need to enforce external usages
to invoke other APIs that are aware of __iomem address space.
The external usages are:
drivers/acpi/apei/einj.c
drivers/acpi/acpi_extlog.c
drivers/char/tpm/tpm_acpi.c
drivers/acpi/nvs.c
This patch thus performs cleanups in this way:
1. Add acpi_os_map/unmap_iomem() to be invoked by non-ACPICA code.
2. Remove __iomem from acpi_os_map/unmap_memory().
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
To be future-proof and for better readability the time comparisons are
modified to use time_before() instead of plain, error-prone math.
Signed-off-by: Manuel Schölling <manuel.schoelling@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Like all of the other *30 ThinkPad models, the W530 has a broken acpi-video
backlight control. Note in order for this to actually fix things on the
ThinkPad W530 the commit titled:
"nouveau: Don't check acpi_video_backlight_support() before registering backlight"
is also needed.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1093171
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When video.use_native_backlight=1 and non intel gfx are in use, the raw
backlight device of the gfx driver will show up after acpi-video has done its
acpi_video_verify_backlight_support() check.
This causes video.use_native_backlight=1 to not have the desired result.
This patch fixes this by adding a backlight notifier and when a raw
backlight is registered or unregistered re-doing the
acpi_video_verify_backlight_support() check.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use acpi_bus_attach_private_data() to attach private data
instead of acpi_attach_data().
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is already acpi_bus_get_private_data() to get ACPI handle data
which is associated with acpi_bus_private_data_handler(). This patch
is to add acpi_bus_attach_private_data() to make a pair and facilitate
to attach and get data to/from ACPI handle.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 1a699476e258 ("ACPI / hotplug / PCI: Hotplug notifications
from acpi_bus_notify()") added debug messages for a few common
events. These debug messages are unconditionally enabled if
CONFIG_DYNAMIC_DEBUG is defined, contrary to the documented
meaning, making the ACPI system spew lots of unwanted noise on
any kernel with dynamic debugging.
The bug was introduced by commit fbfddae69657 ("ACPI: Add
acpi_handle_<level>() interfaces"), which added the
CONFIG_DYNAMIC_DEBUG dependency without respecting its meaning.
Fix by adding real support for dynamic_debug.
Fixes: fbfddae69657 ("ACPI: Add acpi_handle_<level>() interfaces")
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When the thermal module is to be removed, we should destroy the wq
acpi_thermal_pm_queue after the ACPI driver's remove callback is
executed as we will need to flush the workqueue there, or a NULL pointer
access will be hit.
Reported-and-tested-by: Kui Zhang <kuizhang@gmail.com>
References: http://www.spinics.net/lists/kernel/msg1747251.html
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This creates fractional divider type clock for the ones that
have it. It is needed by the UART driver as the clock rate must
accommodate to the requested baud rate.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
A power domain where we save the context of the additional
LPSS registers. We need to do this or all LPSS devices are
left in reset state when resuming from D3 on some Baytrails.
The devices with the fractional clock divider also have
zeros for N and M values after resuming unless they are
reset.
Li Aubrey found the root cause for the issue. The idea of
using power domain for LPSS came from Mika Westerberg.
Reported-by: Jin Yao <yao.jin@linux.intel.com>
Suggested-by: Li Aubrey <aubrey.li@linux.intel.com>
Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
[rjw: Added the .complete() callback to the PM domain, fixed build
warning on 32-bit.]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
To seed up suspend and resume of devices included into Intel SoCs
handled by the ACPI LPSS driver during system suspend, make
acpi_lpss_create_device() call device_enable_async_suspend() for
every device created by it.
This requires acpi_create_platform_device() to be modified to return
a pointer to struct platform_device instead of an int. As a result,
acpi_create_platform_device() cannot be pointed to by the .attach
pointer in platform_handler directly any more, so a simple wrapper
around it is necessary for this purpose. That, in turn, allows the
second unused argument of acpi_create_platform_device() to be
dropped, which is an improvement.
Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Now that the x86 dynamic IRQ allocation problem has been resolved with
commmit 62a08ae2a576 (genirq: x86: Ensure that dynamic irq allocation does
not conflict), we can add back Baytrail-T ACPI ID to the pinctrl driver.
This makes the driver to work on Asus T100 where it is needed for several
things like ACPI GPIO events and SD card detection.
References: https://bugzilla.kernel.org/show_bug.cgi?id=68291
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jin Yao <yao.jin@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add an acpi_video_unregister_backlight function, which only unregisters
the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
driver need this as they don't want the acpi_video# backlight device, but do
need the acpi-video driver for hotkey handling.
Chances are that this new acpi_video_unregister_backlight() is actually
what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor
drivers which want to disable the acpi_video# backlight device, make 2 calls:
acpi_video_dmi_promote_vendor();
acpi_video_unregister();
The intention here is to make things independent of when acpi_video_register()
gets called. As acpi_video_register() will get called on acpi-video load time
on non intel gfx machines, while it gets called on i915 load time on intel
gfx machines.
This leads to the following 2 interesting scenarios:
a) intel gfx:
1) acpi-video module gets loaded (as it is a dependency of acpi_vendor
and i915)
2) acpi-video does NOT call acpi_video_register()
3) acpi_vendor loads (lets assume it loads before i915), calls
acpi_video_dmi_promote_vendor(); which sets
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
4) calls acpi_video_unregister -> not registered, nop
5) i915 loads, calls acpi_video_register
6) acpi_video_register registers the acpi_notifier for the hotkeys,
does NOT register a backlight device because of
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
b) non intel gfx
1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
2) acpi-video calls acpi_video_register()
3) acpi_video_register registers the acpi_notifier for the hotkeys,
and a backlight device
4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier
for the hotkeys AND the backlight device
So here we have possibly the same acpi_vendor module, making the same calls,
but with different results, in one cases acpi-video does handle hotkeys,
in the other it does not.
Note that the a) scenario turns into b) if we assume the i915 module loads
before the vendor_acpi module, so we also have different behavior depending
on module loading order!
So as said I believe that quite a few existing acpi_vendor modules really
always want the behavior of a), hence this patch adds a new
acpi_video_unregister_backlight() which gives the behavior of a) independent
of module loading order.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
No reason for excluding the remaining ones.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
[rjw: Rebased and exported the new acpi_subsys_complete() too.]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Rework the ACPI PM domain's PM callbacks to avoid resuming devices
during system suspend (in order to modify their wakeup settings etc.)
if that isn't necessary.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch fixes the following issue:
If DSDT is customized, no local DSDT copy is needed.
References: https://bugzilla.kernel.org/show_bug.cgi?id=69711
Signed-off-by: Enrico Etxe Arte <goitizena.generoa@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 2.6.35+ <stable@vger.kernel.org> # 2.6.35+
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Seems it helps some users, but causes issues for other users:
https://bugzilla.redhat.com/show_bug.cgi?id=1089545
So lets drop it for now until we've figured out a better fix.
Fixes: 43d949024425 (ACPI / video: Add use_native_backlight quirks for more systems)
References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
During CPU online/offline testing on a large system, one of the
processors got stuck after the message "bad: scheduling from the
idle thread!". The problem is that acpi_cpu_soft_notify() calls
acpi_bus_get_device() for all action types. CPU_STARTING and
CPU_DYING do not allow the notify handlers to sleep. However,
acpi_bus_get_device() can sleep in acpi_ut_acquire_mutex().
Change acpi_cpu_soft_notify() to return immediately for CPU_STARTING
and CPU_DYING as they have no action in this handler.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Most time of battery resume callback is spent on executing AML code
_BTP, _BIF and _BIF to get battery info, status and set alarm. These
AML methods may access EC operation regions several times and consumes
time.
These operations are not necessary during devices resume and can run
during POST_SUSPEND/HIBERNATION event when all processes are thawed.
This also can avoid removing and adding battery sysfs nodes every system
resume even if the battery unit is not actually changed. The original code
updates sysfs nodes without check and this seems not reasonable.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
These IDs are used on Baytrail boards such as Lenovo Miix 2
and Asus Transformer Book T100TA. On lenovo Miix 2 8",
BCM4752 is called LNV4752. All the rest of the IDs are for
Broadcom BCM43241 module with the ID referring to different
revision number.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In acpi_processor_get_info(), ACPI processor info is initialized including
ID, namely CPU index. Currently, on a UP system running an SMP kerenl with
no LAPIC in the MADT, cpu0_initialized is checked to decide whether or not
the CPU has been initialized.
However, this check may not be sufficient for kdump kernels. Most of time
only 1 CPU is supported because of known problems in kdump kernels. So say
the multiple CPUs are present in the boot kernel and a crash happens on
one specific CPU, say CPU2. Then it jumps into the kdump kernel with
"nr_cpus=1" in the command line. In this situation, the kdump kernel
will reuse the ACPI resources from the crashed kernel directly. That
means all LAPIC instances are enabled in the MADT while only one CPU is
in use. In the kdump kernel, x86_cpu_to_apicid contains the correct APIC
ID and it's related to the CPU ID. If cpu0_initialized is checked only, 0
will be used as the CPU index instead of that APIC ID, which is not
correct.
In addition to checking cpu0_initialized, check acpi_lapic. If acpi_lapic
is 0, then no LAPIC is available from the MADT and the system should be
treated as a UP one without a LAPIC (that is, assign 0 to the CPU index).
Otherwise, use the original (valid) CPU index.
Signed-off-by: Baoquan He <bhe@redhat.com>
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If we're not going to be registering any backlight devices then
acpi_video_resume is always nop, so don't register it in that case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The "freeze" sleep state suffers from the same issue that was
addressed by commit ad07277e82de (ACPI / PM: Hold acpi_scan_lock over
system PM transitions) for ACPI sleep states, that is, things break
if ->remove() is called for devices whose system resume callbacks
haven't been executed yet.
It also can be addressed in the same way, by holding the ACPI scan
lock over the "freeze" sleep state and PM transitions to and from
that state, but ->begin() and ->end() platform operations for the
"freeze" sleep state are needed for this purpose.
This change has been tested on Acer Aspire S5 with Thunderbolt.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* acpi-video:
ACPI / video: correct DMI tag for Dell Inspiron 7520
ACPI / video: Add use_native_backlight quirks for more systems
* acpi-blacklist:
ACPI / blacklist: Add dmi_enable_osi_linux quirk for Asus EEE PC 1015PX
ACPI: blacklist win8 OSI for Dell Inspiron 7737
* acpi-ac:
ACPI: Revert "ACPI / AC: convert ACPI ac driver to platform bus"
* acpi-proc:
ACPI / proc: Do not say when /proc interfaces will be deleted in Kconfig
ACPI: Revert "ACPI / Battery: Remove battery's proc directory"
ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c"
* acpica:
ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses.
ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table().
* acpi-tpm:
ACPI / TPM: Fix resume regression on Chromebooks
* acpi-processor:
ACPI / processor: do not mark present at boot but not onlined CPU as onlined
We need to find a smarter way to switch to 64-bit FADT addresses according
to the bug report. This patch reverts Linux to the original behavior.
Fixes: 0249ed2444d6 (ACPICA: Add option to favor 32-bit FADT addresses.)
References: https://bugzilla.kernel.org/show_bug.cgi?id=74021
Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The DMI tag used to identify Dell Inspiron 7520 should be product name
instead of product version.
Fixes: 0e9f81d3b7cd (ACPI / video: Add systems that should favour native backlight interface)
Reported-and-tested-by: Téo Mazars <teomazars@gmail.com>
References: https://bugzilla.redhat.com/show_bug.cgi?id=909552
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Do not tell people in the Kconfig help when exactly we are going to
remove the deprecated ACPI interfaces in /proc, because, honestly,
we don't know. We will remove them when they are not used any more.
In particular, do not tell them that the interfaces will be removed
in a kernel release that already happened long ago.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Export the acpi_target_system_state() function to modules so that
modular drivers can use it to check what the target ACPI sleep state
of the system is (that is needed for i915 mostly at this point).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi_processor_add() assumes that present at boot CPUs
are always onlined, it is not so if a CPU failed to become
onlined. As result acpi_processor_add() will mark such CPU
device as onlined in sysfs and following attempts to
online/offline it using /sys/device/system/cpu/cpuX/online
attribute will fail.
Do not poke into device internals in acpi_processor_add()
and touch "struct device { .offline }" attribute, since
for CPUs onlined at boot it's set by:
topology_init() -> arch_register_cpu() -> register_cpu()
before ACPI device tree is parsed, and for hotplugged
CPUs it's set when userspace onlines CPU via sysfs.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Revert commit cc8ef5270734 (ACPI / AC: convert ACPI ac driver to
platform bus) that is reported to break thermal management on
MacBook Air 2013 with ArchLinux.
Fixes: cc8ef5270734 (ACPI / AC: convert ACPI ac driver to platform bus)
References: https://bugzilla.kernel.org/show_bug.cgi?id=71711
Cc: Zhang Rui <rui.zhang@intel.com>
Reported-and-tested-by: Manuel Krause <manuelkrause@netscape.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Without this this EEE PC exports a non working WMI interface, with this it
exports a working "good old" eeepc_laptop interface, fixing brightness control
not working as well as rfkill being stuck in a permanent wireless blocked
state.
This is not an ideal way to fix this, but various attempts to fix this
otherwise have failed, see:
References: https://bugzilla.redhat.com/show_bug.cgi?id=1067181
Reported-and-tested-by: lou.cardone@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
With win8 capabiltiy, the machine will boot itself immediately after
shutdown command has executed.
Work around this issue by disabling win8 capcability. This workaround
also makes wireless hotkey work.
Signed-off-by: Edward Lin <yidi.lin@canonical.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi-video is unique in that it not only generates brightness up/down
keypresses, but also (sometimes) actively changes the brightness itself.
This presents an inconsistent kernel interface to userspace, basically there
are 2 different scenarios, depending on the laptop model:
1) On some laptops a brightness up/down keypress means: show a brightness osd
with the current brightness, iow it is a brightness has changed notification.
2) Where as on (a lot of) other laptops it means a brightness up/down key was
pressed, deal with it.
Most of the desktop environments interpret any press as in scenario 2, and
change the brightness up / down as a response to the key events, causing it
to be changed twice, once by acpi-video and once by the DE.
With the new default for video.use_native_backlight we will be moving even
more laptops over to behaving as in scenario 2. Making the remaining laptops
even more of a weird exception. Also note that it is hard to detect scenario
1 properly in userspace, and AFAIK none of the DE-s deals with it.
Therefor this commit changes the default of brightness_switch_enabled to 0
making its behavior consistent with all the other backlight drivers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
