Intel Sunrisepoint (Skylake PCH) has the iTCO watchdog accessible across
the SMBus, unlike previous generations of PCH/ICH where it was on the
LPC bus. Because it's on the SMBus, it doesn't make sense to pass around
a 'struct lpc_ich_info', and leaking the type of bus into the iTCO
watchdog driver is kind of backwards anyway.
This change introduces a new 'struct itco_wdt_platform_data' for use
inside the iTCO watchdog driver and by the upcoming Intel Sunrisepoint
code, which neatly avoids having to include lpc_ich headers in the i801
i2c driver.
This change is overdue because lpc_ich_info has already found its way
into other TCO watchdog users, notably the intel_pmc_ipc driver where
the watchdog actually isn't on the LPC bus as far as I can see.
A simple translation layer is provided for converting from the existing
'struct lpc_ich_info' inside the lpc_ich mfd driver.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Acked-by: Darren Hart <dvhart@linux.intel.com> [drivers/x86 refactoring]
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
A new intel_pmc_ipc driver, a symmetrical allocation and free fix in
dell-laptop, a couple minor fixes, and some updated documentation in the
dell-laptop comments.
intel_pmc_ipc:
- Add Intel Apollo Lake PMC IPC driver
tc1100-wmi:
- Delete an unnecessary check before the function call "kfree"
dell-laptop:
- Fix allocating & freeing SMI buffer page
- Show info about WiGig and UWB in debugfs
- Update information about wireless control
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVmM8aAAoJEKbMaAwKp364iUkH/jihOduWkDTzzzxRP2Dv2nEh
qyvE94Nc9A9dl87C2+II/Pi1s8h4CJOQpl70syYYPc4FdF70hpvP8TbHkgCWrY/d
F8CoS9L9keviMtGOWlbEL9hBjfSDNwTMESTrDxrwhA04TSAwjDmXhhiUOF5FjFJm
CX5+ZQ3iXEH6KsENR+Er54J9+6WKE6IuRcnnKCapnPQ8cEYeVn+WEPyzHCOy8Pg3
xzzUar3/knS2VMIb5eIVpaKFvD9P9qBsC/gQ0pk1Y+686gwQZMVURDv8lw8hfXpx
TJDOXk21P8WbSH1r+jwax5wLjLge7vJtYG2Deye6MUgvSgg+O2tSVCv9SMQR088=
=WUgr
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
Pull late x86 platform driver updates from Darren Hart:
"The following came in a bit later and I wanted them to bake in next a
few more days before submitting, thus the second pull.
A new intel_pmc_ipc driver, a symmetrical allocation and free fix in
dell-laptop, a couple minor fixes, and some updated documentation in
the dell-laptop comments.
intel_pmc_ipc:
- Add Intel Apollo Lake PMC IPC driver
tc1100-wmi:
- Delete an unnecessary check before the function call "kfree"
dell-laptop:
- Fix allocating & freeing SMI buffer page
- Show info about WiGig and UWB in debugfs
- Update information about wireless control"
* tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
intel_pmc_ipc: Add Intel Apollo Lake PMC IPC driver
tc1100-wmi: Delete an unnecessary check before the function call "kfree"
dell-laptop: Fix allocating & freeing SMI buffer page
dell-laptop: Show info about WiGig and UWB in debugfs
dell-laptop: Update information about wireless control
asus-wmi: Fan control
dell*: Add Dell airplane mode switch driver
ideapad-laptop: Platform rfkill fixes, and regression fix
pvpanic: Handle missing _STA correctly
toshiba*: Rafactor bluetooth support, haps documentation, driver cleanup
other: Use acpi_video_unregister_backlight instead of acpi_video_unregister in
serveral drivers.
Orphan msi-wmi.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVks/CAAoJEKbMaAwKp364M5kH/06QhbX8NBSrzZk96jTmiFrP
pSO1Z6Jwnm3SL/phUAaRusNVWh0ZsaezvQ6M3Lnsjeh+07qPsF+lag+nHGYXSrQJ
3LVOdqXAojnvPIPNxaTSXylypF776WqFcWwzksICaJo/RA8mE/I4S0A6PMzujivV
6aAZEApED9EFWgnBWz8yYDscTUF7Bypy5/6uNtI0CRXFwUw1C05f5LW5J/qPpIMW
lerSLJKQSpuGbK3db4TqlwJOCZXdSb3HgzLAQKvzhRCukyEdA3zL76Jj6DfVhE9d
nKybk30qYVy1smEWH/I2jMSrxcjY56pRnGhanc/U5gSo9WARGjed/XKtbkFqpSQ=
=9RCr
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v4.2-1' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
Pull x86 platform driver updates from Darren Hart:
"Fairly routine update for platform-drivers-x86.
Mostly fixes and cleanups, with a significant refactoring of toshiba*
drivers. Includes the addition of the dell-rbtn driver.
Details:
asus-wmi:
- fan control
dell*:
- add Dell airplane mode switch driver
ideapad-laptop:
- platform rfkill fixes, and regression fix
pvpanic:
- handle missing _STA correctly
toshiba*:
- rafactor bluetooth support
- haps documentation
- driver cleanup
other:
- Use acpi_video_unregister_backlight instead of
acpi_video_unregister in serveral drivers.
- Orphan msi-wmi.
* tag 'platform-drivers-x86-v4.2-1' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86: (24 commits)
MAINTAINERS: Orphan x86 driver msi-wmi
ideapad: fix software rfkill setting
dell-laptop: Use dell-rbtn instead i8042 filter when possible
dell-rbtn: Export notifier for other kernel modules
dell-rbtn: Dell Airplane Mode Switch driver
samsung-laptop: Use acpi_video_unregister_backlight instead of acpi_video_unregister
asus-wmi: Use acpi_video_unregister_backlight instead of acpi_video_unregister
apple_gmux: Use acpi_video_unregister_backlight instead of acpi_video_unregister
pvpanic: handle missing _STA correctly
ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked
asus-wmi: add fan control
Documentation/ABI: Add file describing the sysfs entries for toshiba_haps
toshiba_haps: Make use of DEVICE_ATTR_{RW, WO} macros
toshiba_haps: Replace sscanf with kstrtoint
toshiba_acpi: Bump driver version to 0.22
toshiba_acpi: Remove TOS_FAILURE check from some functions
toshiba_acpi: Comments cleanup
toshiba_acpi: Rename hci_{read, write}1 functions
toshiba_acpi: Remove no longer needed hci_{read, write}2 functions
toshiba_bluetooth: Change BT status message to debug
...
This driver provides support for PMC control on Apollo Lake platforms.
The PMC is an ARC processor which defines some IPC commands for
communication with other entities in the CPU.
Signed-off-by: qipeng.zha <qipeng.zha@intel.com>
[fengguang.wu@intel.com: Fix Sparse and Cocinelle warnings]
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Pull thermal management updates from Zhang Rui:
"Specifics:
- enhance Thermal Framework with several new capabilities:
* use power estimates
* compute weights with relative integers instead of percentages
* allow governors to have private data in thermal zones
* export thermal zone parameters through sysfs
Thanks to the ARM thermal team (Javi, Punit, KP).
- introduce a new thermal governor: power allocator. First in kernel
closed loop PI(D) controller for thermal control. Thanks to ARM
thermal team.
- enhance OF thermal to allow thermal zones to have sustainable power
HW specification. Thanks to Punit.
- introduce thermal driver for Intel Quark SoC x1000platform. Thanks
to Ong, Boon Leong.
- introduce QPNP PMIC temperature alarm driver. Thanks to Ivan T. I.
- introduce thermal driver for Hisilicon hi6220. Thanks to
kongxinwei.
- enhance Exynos thermal driver to handle Exynos5433 TMU. Thanks to
Chanwoo C.
- TI thermal driver now has a better implementation for EOCZ bit.
From Pavel M.
- add id for Skylake processors in int340x processor thermal driver.
- a couple of small fixes and cleanups."
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (36 commits)
thermal: hisilicon: add new hisilicon thermal sensor driver
dt-bindings: Document the hi6220 thermal sensor bindings
thermal: of-thermal: add support for reading coefficients property
thermal: support slope and offset coefficients
thermal: power_allocator: round the division when divvying up power
thermal: exynos: Add the support for Exynos5433 TMU
thermal: cpu_cooling: Fix power calculation when CPUs are offline
thermal: cpu_cooling: Remove cpu_dev update on policy CPU update
thermal: export thermal_zone_parameters to sysfs
thermal: cpu_cooling: Check memory allocation of power_table
ti-soc-thermal: request temperature periodically if hw can't do that itself
ti-soc-thermal: implement eocz bit to make driver useful on omap3
cleanup ti-soc-thermal
thermal: remove stale THERMAL_POWER_ACTOR select
thermal: Default OF created trip points to writable
thermal: core: Add Kconfig option to enable writable trips
thermal: x86_pkg_temp: drop const for thermal_zone_parameters
of: thermal: Introduce sustainable power for a thermal zone
thermal: add trace events to the power allocator governor
thermal: introduce the Power Allocator governor
...
This commit fix kernel crash when probing for rfkill devices in dell-laptop
driver failed. Function free_page() was incorrectly used on struct page *
instead of virtual address of SMI buffer.
This commit also simplify allocating page for SMI buffer by using
__get_free_page() function instead of sequential call of functions
alloc_page() and page_address().
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
- ACPICA update to upstream revision 20150515 including basic
support for ACPI 6 features: new ACPI tables introduced by
ACPI 6 (STAO, XENV, WPBT, NFIT, IORT), changes related to the
other tables (DTRM, FADT, LPIT, MADT), new predefined names
(_BTH, _CR3, _DSD, _LPI, _MTL, _PRR, _RDI, _RST, _TFP, _TSN),
fixes and cleanups (Bob Moore, Lv Zheng).
- ACPI device power management core code update to follow ACPI 6
which reflects the ACPI device power management implementation
in Windows (Rafael J Wysocki).
- Rework of the backlight interface selection logic to reduce the
number of kernel command line options and improve the handling
of DMI quirks that may be involved in that and to make the
code generally more straightforward (Hans de Goede).
- Fixes for the ACPI Embedded Controller (EC) driver related to
the handling of EC transactions (Lv Zheng).
- Fix for a regression related to the ACPI resources management
and resulting from a recent change of ACPI initialization code
ordering (Rafael J Wysocki).
- Fix for a system initialization regression related to ACPI
introduced during the 3.14 cycle and caused by running the
code that switches the platform over to the ACPI mode too
early in the initialization sequence (Rafael J Wysocki).
- Support for the ACPI _CCA device configuration object related
to DMA cache coherence (Suravee Suthikulpanit).
- ACPI/APEI fixes and cleanups (Jiri Kosina, Borislav Petkov).
- ACPI battery driver cleanups (Luis Henriques, Mathias Krause).
- ACPI processor driver cleanups (Hanjun Guo).
- Cleanups and documentation update related to the ACPI device
properties interface based on _DSD (Rafael J Wysocki).
- ACPI device power management fixes (Rafael J Wysocki).
- Assorted cleanups related to ACPI (Dominik Brodowski. Fabian
Frederick, Lorenzo Pieralisi, Mathias Krause, Rafael J Wysocki).
- Fix for a long-standing issue causing General Protection Faults
to be generated occasionally on return to user space after resume
from ACPI-based suspend-to-RAM on 32-bit x86 (Ingo Molnar).
- Fix to make the suspend core code return -EBUSY consistently in
all cases when system suspend is aborted due to wakeup detection
(Ruchi Kandoi).
- Support for automated device wakeup IRQ handling allowing drivers
to make their PM support more starightforward (Tony Lindgren).
- New tracepoints for suspend-to-idle tracing and rework of the
prepare/complete callbacks tracing in the PM core (Todd E Brandt,
Rafael J Wysocki).
- Wakeup sources framework enhancements (Jin Qian).
- New macro for noirq system PM callbacks (Grygorii Strashko).
- Assorted cleanups related to system suspend (Rafael J Wysocki).
- cpuidle core cleanups to make the code more efficient (Rafael J
Wysocki).
- powernv/pseries cpuidle driver update (Shilpasri G Bhat).
- cpufreq core fixes related to CPU online/offline that should
reduce the overhead of these operations quite a bit, unless the
CPU in question is physically going away (Viresh Kumar, Saravana
Kannan).
- Serialization of cpufreq governor callbacks to avoid race
conditions in some cases (Viresh Kumar).
- intel_pstate driver fixes and cleanups (Doug Smythies, Prarit
Bhargava, Joe Konno).
- cpufreq driver (arm_big_little, cpufreq-dt, qoriq) updates (Sudeep
Holla, Felipe Balbi, Tang Yuantian).
- Assorted cleanups in cpufreq drivers and core (Shailendra Verma,
Fabian Frederick, Wang Long).
- New Device Tree bindings for representing Operating Performance
Points (Viresh Kumar).
- Updates for the common clock operations support code in the PM
core (Rajendra Nayak, Geert Uytterhoeven).
- PM domains core code update (Geert Uytterhoeven).
- Intel Knights Landing support for the RAPL (Running Average Power
Limit) power capping driver (Dasaratharaman Chandramouli).
- Fixes related to the floor frequency setting on Atom SoCs in the
RAPL power capping driver (Ajay Thomas).
- Runtime PM framework documentation update (Ben Dooks).
- cpupower tool fix (Herton R Krzesinski).
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJViJdWAAoJEILEb/54YlRx/9gP/3gHoFevNRycvn0VpKqdufCI
Mxy2LBBLlfyW2uD3+NvqvA2WWSo0Cs/LgXa04eAVxPdU7k48s8w+54U23wSouzjW
gfwAmuHxzDR8v0h8X3h6BxNzmkIQHtmDcQlA/cZdHejY/UUw01yxRGNUUZDNbxlm
WXn2nmlBLmGqXTYq0fpBV+3jicUghJqHHsBCqa3VR2yQioHMJG01F4UZMqYTZunN
OIvDUghxByKz6alzdCqlLl1Y0exV6vwWUAzBsl1qHqmHu/bWFSZn3ujNNVrjqHhw
Kl7/8dC2pQkv3Zo3gEVvfQ0onotwWZxGHzPQRdvmxvRnBunQVCi/wynx90yABX/r
PPb/iBNV0mZskbF0zb0GZT3ZZWGA8Z0p3o5JQv2jV4m62qTzx8w50Y5kbn9N1WT+
5bre7AVbVAlGonWszcS9iE+6TOboRz9OD1CCwPFXHItFutlBkau+1hHfFoLM0o9n
LhpGuyszT/EUa1BHkLzuCckFqO2DpbF3N2CKmuTekw0CdgdsvRL2pRByuerk3j7R
WQhlcvBq5YH6j43AuoEZKp8r1iN8oG/iqlrMYQaYWrW9hJaoQOoU8dGJxp/e7gKN
r/qeYjETI+tIsjCbtH5WQzzxDI3gPISAYAtfqs7G34EEo+Lwp6kyRUAF4kDot2V3
ZIyuKMmTu4cdwDETr/O+
=7jTj
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI updates from Rafael Wysocki:
"The rework of backlight interface selection API from Hans de Goede
stands out from the number of commits and the number of affected
places perspective. The cpufreq core fixes from Viresh Kumar are
quite significant too as far as the number of commits goes and because
they should reduce CPU online/offline overhead quite a bit in the
majority of cases.
From the new featues point of view, the ACPICA update (to upstream
revision 20150515) adding support for new ACPI 6 material to ACPICA is
the one that matters the most as some new significant features will be
based on it going forward. Also included is an update of the ACPI
device power management core to follow ACPI 6 (which in turn reflects
the Windows' device PM implementation), a PM core extension to support
wakeup interrupts in a more generic way and support for the ACPI _CCA
device configuration object.
The rest is mostly fixes and cleanups all over and some documentation
updates, including new DT bindings for Operating Performance Points.
There is one fix for a regression introduced in the 4.1 cycle, but it
adds quite a number of lines of code, it wasn't really ready before
Thursday and you were on vacation, so I refrained from pushing it on
the last minute for 4.1.
Specifics:
- ACPICA update to upstream revision 20150515 including basic support
for ACPI 6 features: new ACPI tables introduced by ACPI 6 (STAO,
XENV, WPBT, NFIT, IORT), changes related to the other tables (DTRM,
FADT, LPIT, MADT), new predefined names (_BTH, _CR3, _DSD, _LPI,
_MTL, _PRR, _RDI, _RST, _TFP, _TSN), fixes and cleanups (Bob Moore,
Lv Zheng).
- ACPI device power management core code update to follow ACPI 6
which reflects the ACPI device power management implementation in
Windows (Rafael J Wysocki).
- rework of the backlight interface selection logic to reduce the
number of kernel command line options and improve the handling of
DMI quirks that may be involved in that and to make the code
generally more straightforward (Hans de Goede).
- fixes for the ACPI Embedded Controller (EC) driver related to the
handling of EC transactions (Lv Zheng).
- fix for a regression related to the ACPI resources management and
resulting from a recent change of ACPI initialization code ordering
(Rafael J Wysocki).
- fix for a system initialization regression related to ACPI
introduced during the 3.14 cycle and caused by running the code
that switches the platform over to the ACPI mode too early in the
initialization sequence (Rafael J Wysocki).
- support for the ACPI _CCA device configuration object related to
DMA cache coherence (Suravee Suthikulpanit).
- ACPI/APEI fixes and cleanups (Jiri Kosina, Borislav Petkov).
- ACPI battery driver cleanups (Luis Henriques, Mathias Krause).
- ACPI processor driver cleanups (Hanjun Guo).
- cleanups and documentation update related to the ACPI device
properties interface based on _DSD (Rafael J Wysocki).
- ACPI device power management fixes (Rafael J Wysocki).
- assorted cleanups related to ACPI (Dominik Brodowski, Fabian
Frederick, Lorenzo Pieralisi, Mathias Krause, Rafael J Wysocki).
- fix for a long-standing issue causing General Protection Faults to
be generated occasionally on return to user space after resume from
ACPI-based suspend-to-RAM on 32-bit x86 (Ingo Molnar).
- fix to make the suspend core code return -EBUSY consistently in all
cases when system suspend is aborted due to wakeup detection (Ruchi
Kandoi).
- support for automated device wakeup IRQ handling allowing drivers
to make their PM support more starightforward (Tony Lindgren).
- new tracepoints for suspend-to-idle tracing and rework of the
prepare/complete callbacks tracing in the PM core (Todd E Brandt,
Rafael J Wysocki).
- wakeup sources framework enhancements (Jin Qian).
- new macro for noirq system PM callbacks (Grygorii Strashko).
- assorted cleanups related to system suspend (Rafael J Wysocki).
- cpuidle core cleanups to make the code more efficient (Rafael J
Wysocki).
- powernv/pseries cpuidle driver update (Shilpasri G Bhat).
- cpufreq core fixes related to CPU online/offline that should reduce
the overhead of these operations quite a bit, unless the CPU in
question is physically going away (Viresh Kumar, Saravana Kannan).
- serialization of cpufreq governor callbacks to avoid race
conditions in some cases (Viresh Kumar).
- intel_pstate driver fixes and cleanups (Doug Smythies, Prarit
Bhargava, Joe Konno).
- cpufreq driver (arm_big_little, cpufreq-dt, qoriq) updates (Sudeep
Holla, Felipe Balbi, Tang Yuantian).
- assorted cleanups in cpufreq drivers and core (Shailendra Verma,
Fabian Frederick, Wang Long).
- new Device Tree bindings for representing Operating Performance
Points (Viresh Kumar).
- updates for the common clock operations support code in the PM core
(Rajendra Nayak, Geert Uytterhoeven).
- PM domains core code update (Geert Uytterhoeven).
- Intel Knights Landing support for the RAPL (Running Average Power
Limit) power capping driver (Dasaratharaman Chandramouli).
- fixes related to the floor frequency setting on Atom SoCs in the
RAPL power capping driver (Ajay Thomas).
- runtime PM framework documentation update (Ben Dooks).
- cpupower tool fix (Herton R Krzesinski)"
* tag 'pm+acpi-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (194 commits)
cpuidle: powernv/pseries: Auto-promotion of snooze to deeper idle state
x86: Load __USER_DS into DS/ES after resume
PM / OPP: Add binding for 'opp-suspend'
PM / OPP: Allow multiple OPP tables to be passed via DT
PM / OPP: Add new bindings to address shortcomings of existing bindings
ACPI: Constify ACPI device IDs in documentation
ACPI / enumeration: Document the rules regarding the PRP0001 device ID
ACPI / video: Make acpi_video_unregister_backlight() private
acpi-video-detect: Remove old API
toshiba-acpi: Port to new backlight interface selection API
thinkpad-acpi: Port to new backlight interface selection API
sony-laptop: Port to new backlight interface selection API
samsung-laptop: Port to new backlight interface selection API
msi-wmi: Port to new backlight interface selection API
msi-laptop: Port to new backlight interface selection API
intel-oaktrail: Port to new backlight interface selection API
ideapad-laptop: Port to new backlight interface selection API
fujitsu-laptop: Port to new backlight interface selection API
eeepc-laptop: Port to new backlight interface selection API
dell-wmi: Port to new backlight interface selection API
...
This commit show additional information about rfkill state in debugfs based
on newly released documentation by Dell.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Make sure that all existing SMBIOS calls for wireless control are properly
documented. This commit also add new documentation released by Dell.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Azael Avalos <coproscefalo@gmail.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple "ls /sys/class/backlight" suffices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mattia Dongili <malattia@linux.it>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple "ls /sys/class/backlight" suffices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple "ls /sys/class/backlight" suffices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple "ls /sys/class/backlight" suffices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jonathan Woithe <jwoithe@just42.net>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple "ls /sys/class/backlight" suffices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple "ls /sys/class/backlight" suffices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple "ls /sys/class/backlight" suffices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple "ls /sys/class/backlight" suffices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This is a preparation patch for the backlight interface selection logic
cleanup, there are 2 reasons to not always build the video_detect code
into the kernel:
1) In order for the video_detect.c to also deal with / select native
backlight interfaces on win8 systems, instead of doing this in video.c
where it does not belong, video_detect.c needs to call into the backlight
class code. Which cannot be done if it is builtin and the blacklight class
is not.
2) Currently all the platform/x86 drivers which have quirks to prefer
the vendor driver over acpi-video call acpi_video_unregister_backlight()
to remove the acpi-video backlight interface, this logic really belongs
in video_detect.c, which will cause video_detect.c to depend on symbols of
video.c and video.c already depends on video_detect.c symbols, so they
really need to be a single module.
Note that this commits make 2 changes so as to maintain 100% kernel
commandline compatibility:
1) The __setup call for the acpi_backlight= handling is moved to
acpi/util.c as __setup may only be used by code which is alwasy builtin
2) video.c is renamed to acpi_video.c so that it can be combined with
video_detect.c into video.ko
This commit also makes changes to drivers/platform/x86/Kconfig to ensure
that drivers which use acpi_video_backlight_support() from video_detect.c,
will not be built-in when acpi_video is not built in. This also changes
some "select" uses to "depends on" to avoid dependency loops.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi_video_dmi_demote_vendor() is going away as part of the cleanup of
the code for determinging which backlight class driver(s) to register.
The call to acpi_video_dmi_demote_vendor() was meant to undo the call to
acpi_video_dmi_promote_vendor() when the gmux device is removed, this is
questionable though since the promote call sets a flag, not a counter, so
the demote call may undo a promoto done elsewhere. Moreover in practice
this is a nop since the gmux device is never removed, and the flag is only
checked when acpi/video.ko gets loaded, so even if the user manually
removes apple-gmux the demote call is still a nop as video.ko will already
have loaded by this time.
Also note that none of the other users of acpi_video_dmi_promote_vendor()
use acpi_video_dmi_demote_vendor().
If we ever encounter a system with a gmux where the acpi-video interface
should be used, then the proper fix would be to dmi-blacklist the gmux
driver on that system.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.
The unregistering of the acpi video bus event listener usually is
undesirable, which by itself is a good reason to switch to
acpi_video_unregister_backlight().
Another problem with using acpi_video_unregister() rather then using
acpi_video_unregister_backlight() is that on systems with an intel video
opregion (most systems) and a broken_acpi_video quirk, whether or not
the acpi video bus event listener actually gets unregistered depends on
module load ordering:
Scenario a:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) intel.ko gets loaded, calls acpi_video_register() which registers both
the listener and the acpi backlight interface
3) samsung-laptop.ko gets loaded, calls acpi_video_unregister() causing
both the listener and the acpi backlight interface to unregister
Scenario b:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) samsung-laptop.ko gets loaded, calls acpi_video_dmi_promote_vendor(),
calls acpi_video_unregister(), which is a nop since acpi_video_register
has not yet been called
2) intel.ko gets loaded, calls acpi_video_register() which registers
the listener, but does not register the acpi backlight interface due to
the call to the preciding call to acpi_video_dmi_promote_vendor()
*) acpi/video.ko always loads first as both other modules depend on it.
So we end up with or without an acpi video bus event listener depending
on module load ordering, not good.
Switching to using acpi_video_unregister_backlight() means that independ
of ordering we will always have an acpi video bus event listener fixing
this.
Note that this commit means that systems without an intel video opregion,
and systems which were hitting scenario a wrt module load ordering, are
now getting an acpi video bus event listener while before they were not!
On some systems this may cause the brightness hotkeys to start generating
keypresses while before they were not (good), while on other systems this
may cause the brightness hotkeys to generate multiple keypress events for
a single press (not so good). Since on most systems the acpi video bus is
the canonical source for brightness events I believe that the latter case
will needs to be handled on a case by case basis by filtering out the
duplicate keypresses at the other source for them.
Cc: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.
The unregistering of the acpi video bus event listener usually is
undesirable, which by itself is a good reason to switch to
acpi_video_unregister_backlight().
Another problem with using acpi_video_unregister() rather then using
acpi_video_unregister_backlight() is that on systems with an intel video
opregion (most systems) and a wmi_backlight_power quirk, whether or not
the acpi video bus event listener actually gets unregistered depends on
module load ordering:
Scenario a:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) intel.ko gets loaded, calls acpi_video_register() which registers both
the listener and the acpi backlight interface
3) asus-wmi.ko gets loaded, calls acpi_video_unregister() causing both
the listener and the acpi backlight interface to unregister
Scenario b:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) asus-wmi.ko gets loaded, calls acpi_video_dmi_promote_vendor(),
calls acpi_video_unregister(), which is a nop since acpi_video_register
has not yet been called
2) intel.ko gets loaded, calls acpi_video_register() which registers
the listener, but does not register the acpi backlight interface due to
the call to the preciding call to acpi_video_dmi_promote_vendor()
*) acpi/video.ko always loads first as both other modules depend on it.
So we end up with or without an acpi video bus event listener depending
on module load ordering, not good.
Switching to using acpi_video_unregister_backlight() means that independ
of ordering we will always have an acpi video bus event listener fixing
this.
Note that this commit means that systems without an intel video opregion,
and systems which were hitting scenario a wrt module load ordering, are
now getting an acpi video bus event listener while before they were not!
On some systems this may cause the brightness hotkeys to start generating
keypresses while before they were not (good), while on other systems this
may cause the brightness hotkeys to generate multiple keypress events for
a single press (not so good). Since on most systems the acpi video bus is
the canonical source for brightness events I believe that the latter case
will needs to be handled on a case by case basis by filtering out the
duplicate keypresses at the other source for them.
Cc: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.
The unregistering of the acpi video bus event listener usually is
undesirable, which by itself is a good reason to switch to
acpi_video_unregister_backlight().
Another problem with using acpi_video_unregister() rather then using
acpi_video_unregister_backlight() is that on systems with an intel video
opregion (most systems) whether or not the acpi video bus event listener
actually gets unregistered depends on module load ordering:
Scenario a:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) intel.ko gets loaded, calls acpi_video_register() which registers both
the listener and the acpi backlight interface
3) apple-gmux.ko gets loaded, calls acpi_video_unregister() causing both
the listener and the acpi backlight interface to unregister
Scenario b:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) apple-gmux.ko gets loaded, calls acpi_video_dmi_promote_vendor(),
calls acpi_video_unregister(), which is a nop since acpi_video_register
has not yet been called
2) intel.ko gets loaded, calls acpi_video_register() which registers
the listener, but does not register the acpi backlight interface due to
the call to the preciding call to acpi_video_dmi_promote_vendor()
*) acpi/video.ko always loads first as both other modules depend on it.
So we end up with or without an acpi video bus event listener depending
on module load ordering, not good.
Switching to using acpi_video_unregister_backlight() means that independ
of ordering we will always have an acpi video bus event listener fixing
this.
Note that this commit means that systems without an intel video opregion,
and systems which were hitting scenario a wrt module load ordering, are
now getting an acpi video bus event listener while before they were not!
On some systems this may cause the brightness hotkeys to start generating
keypresses while before they were not (good), while on other systems this
may cause the brightness hotkeys to generate multiple keypress events for
a single press (not so good). Since on most systems the acpi video bus is
the canonical source for brightness events I believe that the latter case
will needs to be handled on a case by case basis by filtering out the
duplicate keypresses at the other source for them.
Cc: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This fixes a several year old regression that I found while trying
to get the Yoga 3 11 to work. The ideapad_rfk_set function is meant
to send a command to the embedded controller through ACPI, but
as of c1f73658ed, it sends the index of the rfkill device instead
of the command, and ignores the opcode field.
This changes it back to the original behavior, which indeed
flips the rfkill state as seen in the debugfs interface.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: c1f73658ed ("ideapad: pass ideapad_priv as argument (part 2)")
Cc: stable@vger.kernel.org # v2.6.38+
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Until now module dell-laptop registered rfkill device which used i8042
filter function for receiving HW switch rfkill events (handling special
keycode).
But for some dell laptops there is native ACPI driver dell-rbtn which can
receive rfkill events (without i8042 hooks).
So this patch will combine best from both sides. It will use native ACPI
driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
enabling or disabling radio devices. If ACPI driver or device will not be
available fallback to i8042 filter function will be used.
Patch also changes module_init() to late_initcall() to ensure that init
function will be called after initializing dell-rbtn.c driver.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
This patch exports notifier functions so other modules can receive HW
switch events. By default when some module register notifier, dell-rbtn
driver automatically remove rfkill interfaces from system (it is expected
that other module will use events for other rfkill interface). This
behaviour can be changed with new module parameter "auto_remove_rfkill".
This patch is designed for dell-laptop module for receiving those events.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
[dvhart@linux.intel.com: Cleanup MODULE_PARM_DESC formatting and grammar]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
This is an ACPI driver for Dell laptops which receive HW slider radio
switch or hotkey toggle wifi button events. It exports rfkill device
dell-rbtn (which provide correct hard rfkill state) or hotkey input device.
Alex Hung is author of original hotkey input device code.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Cc: Alex Hung <alex.hung@canonical.com>
[fengguang.wu@intel.com: rbtn_ops can be static]
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
[dvhart@linux.intel.com: Correct multi-line comment formatting]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.
The unregistering of the acpi video bus event listener usually is
undesirable, which by itself is a good reason to switch to
acpi_video_unregister_backlight().
Another problem with using acpi_video_unregister() rather then using
acpi_video_unregister_backlight() is that on systems with an intel video
opregion (most systems) and a broken_acpi_video quirk, whether or not
the acpi video bus event listener actually gets unregistered depends on
module load ordering:
Scenario a:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) intel.ko gets loaded, calls acpi_video_register() which registers both
the listener and the acpi backlight interface
3) samsung-laptop.ko gets loaded, calls acpi_video_unregister() causing
both the listener and the acpi backlight interface to unregister
Scenario b:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) samsung-laptop.ko gets loaded, calls acpi_video_dmi_promote_vendor(),
calls acpi_video_unregister(), which is a nop since acpi_video_register
has not yet been called
2) intel.ko gets loaded, calls acpi_video_register() which registers
the listener, but does not register the acpi backlight interface due to
the call to the preciding call to acpi_video_dmi_promote_vendor()
*) acpi/video.ko always loads first as both other modules depend on it.
So we end up with or without an acpi video bus event listener depending
on module load ordering, not good.
Switching to using acpi_video_unregister_backlight() means that independ
of ordering we will always have an acpi video bus event listener fixing
this.
Note that this commit means that systems without an intel video opregion,
and systems which were hitting scenario a wrt module load ordering, are
now getting an acpi video bus event listener while before they were not!
On some systems this may cause the brightness hotkeys to start generating
keypresses while before they were not (good), while on other systems this
may cause the brightness hotkeys to generate multiple keypress events for
a single press (not so good). Since on most systems the acpi video bus is
the canonical source for brightness events I believe that the latter case
will needs to be handled on a case by case basis by filtering out the
duplicate keypresses at the other source for them.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Corentin Chary <corentin.chary@gmail.com)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.
The unregistering of the acpi video bus event listener usually is
undesirable, which by itself is a good reason to switch to
acpi_video_unregister_backlight().
Another problem with using acpi_video_unregister() rather then using
acpi_video_unregister_backlight() is that on systems with an intel video
opregion (most systems) and a wmi_backlight_power quirk, whether or not
the acpi video bus event listener actually gets unregistered depends on
module load ordering:
Scenario a:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) intel.ko gets loaded, calls acpi_video_register() which registers both
the listener and the acpi backlight interface
3) asus-wmi.ko gets loaded, calls acpi_video_unregister() causing both
the listener and the acpi backlight interface to unregister
Scenario b:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) asus-wmi.ko gets loaded, calls acpi_video_dmi_promote_vendor(),
calls acpi_video_unregister(), which is a nop since acpi_video_register
has not yet been called
2) intel.ko gets loaded, calls acpi_video_register() which registers
the listener, but does not register the acpi backlight interface due to
the call to the preciding call to acpi_video_dmi_promote_vendor()
*) acpi/video.ko always loads first as both other modules depend on it.
So we end up with or without an acpi video bus event listener depending
on module load ordering, not good.
Switching to using acpi_video_unregister_backlight() means that independ
of ordering we will always have an acpi video bus event listener fixing
this.
Note that this commit means that systems without an intel video opregion,
and systems which were hitting scenario a wrt module load ordering, are
now getting an acpi video bus event listener while before they were not!
On some systems this may cause the brightness hotkeys to start generating
keypresses while before they were not (good), while on other systems this
may cause the brightness hotkeys to generate multiple keypress events for
a single press (not so good). Since on most systems the acpi video bus is
the canonical source for brightness events I believe that the latter case
will needs to be handled on a case by case basis by filtering out the
duplicate keypresses at the other source for them.
Cc: acpi4asus-user@lists.sourceforge.net
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Corentin Chary <corentin.chary@gmail.com)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.
The unregistering of the acpi video bus event listener usually is
undesirable, which by itself is a good reason to switch to
acpi_video_unregister_backlight().
Another problem with using acpi_video_unregister() rather then using
acpi_video_unregister_backlight() is that on systems with an intel video
opregion (most systems) whether or not the acpi video bus event listener
actually gets unregistered depends on module load ordering:
Scenario a:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) intel.ko gets loaded, calls acpi_video_register() which registers both
the listener and the acpi backlight interface
3) apple-gmux.ko gets loaded, calls acpi_video_unregister() causing both
the listener and the acpi backlight interface to unregister
Scenario b:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
is an intel opregion.
2) apple-gmux.ko gets loaded, calls acpi_video_dmi_promote_vendor(),
calls acpi_video_unregister(), which is a nop since acpi_video_register
has not yet been called
2) intel.ko gets loaded, calls acpi_video_register() which registers
the listener, but does not register the acpi backlight interface due to
the call to the preciding call to acpi_video_dmi_promote_vendor()
*) acpi/video.ko always loads first as both other modules depend on it.
So we end up with or without an acpi video bus event listener depending
on module load ordering, not good.
Switching to using acpi_video_unregister_backlight() means that independ
of ordering we will always have an acpi video bus event listener fixing
this.
Note that this commit means that systems without an intel video opregion,
and systems which were hitting scenario a wrt module load ordering, are
now getting an acpi video bus event listener while before they were not!
On some systems this may cause the brightness hotkeys to start generating
keypresses while before they were not (good), while on other systems this
may cause the brightness hotkeys to generate multiple keypress events for
a single press (not so good). Since on most systems the acpi video bus is
the canonical source for brightness events I believe that the latter case
will needs to be handled on a case by case basis by filtering out the
duplicate keypresses at the other source for them.
Cc: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
pvpanic was not properly detected when _STA was missing.
ACPI 6.0 April 2015, 6.3.7 _STA (Status)
If a device object (including the processor object) does not have an
_STA object, then OSPM assumes that all of the above bits are set
(i.e., the device is present, enabled, shown in the UI, and
functioning).
Not adhering to the specification made pvpanic dormant under QEMU 2.3.
The original patch used acpi_bus_get_status_handle, which was not
being exported, so module build blew up; switch to acpi_bus_get_status
and use the status it populates.
Populated status is a bitfield so we can make the code self-documenting.
We do not check 'present' because 'enabled' has to be false in that case
by specification. Older QEMUs set 0xff to status and newer ones do 0xb.
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
[dvhart@linux.intel.com: Merge acpi_bug_get_status fix to avoid bisect breakage]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Lenovo G30-50 does not have a hardware wireless switch and wireless
is always blocked.
BugLink: https://bugs.launchpad.net/bugs/1397021
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Philippe Coval <philippe.coval@open.eurogiciel.org>
[dvhart@linux.intel.com: Reordered dmi id per Phillippe's later version]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
The conversion to DEVICE_ATTR_* macros failed to fixup a few cases where
the old attribute names didn't match the show/store function names.
Instead of renaming the functions, the attributes were renamed. This
caused an unintentional API change. The hwmon required 'name' attribute
were among the renamed attribute, causing libsensors to fail to detect
the hwmon device at all.
Fix by using the DEVICE_ATTR macro for these attributes, allowing the
show/store functions to keep their system specific prefixes.
Fixes: b4dd04ac6e ("thinkpad_acpi: use DEVICE_ATTR_* macros")
Cc: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
This patch is partially based on Felipe Contrera's earlier patch, that
was discussed here: https://lkml.org/lkml/2013/10/8/800
Some problems of that patch are solved, now:
1) The main obstacle for the earlier patch seemed to be the use of
virt_to_phys, which is accepted, now
2) random memory corruption occurred on my notebook, thus DMA-able memory
is allocated now, which solves this problem
3) hwmon interface is used instead of the thermal interface, as a
hwmon device is already set up by this driver and seemed more
appropriate than the thermal interface
4) Calling the ACPI-functions was modularized thus it's possible to call
some multifunctions easily, now (by using
asus_wmi_evaluate_method_agfn).
Unfortunately the WMI doesn't support controlling both fans on
a dual-fan notebook because of an restriction in the acpi-method
"SFNS", that is callable through the wmi. If "SFNV" would be called
directly even dual fan configurations could be controlled, but not by using
wmi.
Speed readings only work on auto-mode, thus "-1" will be reported in
manual mode.
Additionally the speed readings are reported as hundreds of RPM thus
they are not too precise.
This patch is tested only on one notebook (N551JK) but a similar module,
that contained some code to try to control the second fan also, was
reported to work on an UX32VD, at least for the first fan.
As Felipe already mentioned the low-level functions are described here:
http://forum.notebookreview.com/threads/fan-control-on-asus-prime-ux31-ux31a-ux32a-ux32vd.705656/
Signed-off-by: Kast Bernd <kastbernd@gmx.de>
Acked-by: Corentin Chary <corentin.chary@gmail.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
This patch makes use of DEVICE_ATTR_{RW, WO} macros, simplifying
device attributes creation.
Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
This patch simply replaces the use of sscanf with kstrtoint returning
the error code in case that something went bad.
Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
This patch simply bumps the driver version to 0.22, as significant
changes were made to the driver, such as cleanups, updated events,
keymap handling, fixes and the bluetooth rfkill code removal.
Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
This patch removes the check for TOS_FAILURE whenever we are using
the tci_raw function call, as that code is only returned by the
{hci, sci}_{read, write} functions and never by the tci_raw, and
thus making that check irrelevant.
Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
