1
0
Fork 0
alistair23-linux/drivers/platform/x86/asus-wmi.c

2701 lines
66 KiB
C
Raw Permalink Normal View History

// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Asus PC WMI hotkey driver
*
* Copyright(C) 2010 Intel Corporation.
* Copyright(C) 2010-2011 Corentin Chary <corentin.chary@gmail.com>
*
* Portions based on wistron_btns.c:
* Copyright (C) 2005 Miloslav Trmac <mitr@volny.cz>
* Copyright (C) 2005 Bernhard Rosenkraenzer <bero@arklinux.org>
* Copyright (C) 2005 Dmitry Torokhov <dtor@mail.ru>
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <linux/slab.h>
#include <linux/input.h>
#include <linux/input/sparse-keymap.h>
#include <linux/fb.h>
#include <linux/backlight.h>
#include <linux/leds.h>
#include <linux/rfkill.h>
#include <linux/pci.h>
#include <linux/pci_hotplug.h>
#include <linux/power_supply.h>
#include <linux/hwmon.h>
#include <linux/hwmon-sysfs.h>
#include <linux/debugfs.h>
#include <linux/seq_file.h>
#include <linux/platform_data/x86/asus-wmi.h>
#include <linux/platform_device.h>
#include <linux/thermal.h>
ACPI: Clean up inclusions of ACPI header files Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-02 17:49:16 -07:00
#include <linux/acpi.h>
#include <linux/dmi.h>
#include <acpi/battery.h>
#include <acpi/video.h>
#include "asus-wmi.h"
MODULE_AUTHOR("Corentin Chary <corentin.chary@gmail.com>, "
"Yong Wang <yong.y.wang@intel.com>");
MODULE_DESCRIPTION("Asus Generic WMI Driver");
MODULE_LICENSE("GPL");
#define to_asus_wmi_driver(pdrv) \
(container_of((pdrv), struct asus_wmi_driver, platform_driver))
#define ASUS_WMI_MGMT_GUID "97845ED0-4E6D-11DE-8A39-0800200C9A66"
#define NOTIFY_BRNUP_MIN 0x11
#define NOTIFY_BRNUP_MAX 0x1f
#define NOTIFY_BRNDOWN_MIN 0x20
#define NOTIFY_BRNDOWN_MAX 0x2e
#define NOTIFY_FNLOCK_TOGGLE 0x4e
#define NOTIFY_KBD_BRTUP 0xc4
#define NOTIFY_KBD_BRTDWN 0xc5
#define NOTIFY_KBD_BRTTOGGLE 0xc7
#define NOTIFY_KBD_FBM 0x99
#define ASUS_WMI_FNLOCK_BIOS_DISABLED BIT(0)
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
#define ASUS_FAN_DESC "cpu_fan"
#define ASUS_FAN_MFUN 0x13
#define ASUS_FAN_SFUN_READ 0x06
#define ASUS_FAN_SFUN_WRITE 0x07
/* Based on standard hwmon pwmX_enable values */
#define ASUS_FAN_CTRL_FULLSPEED 0
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
#define ASUS_FAN_CTRL_MANUAL 1
#define ASUS_FAN_CTRL_AUTO 2
#define ASUS_FAN_BOOST_MODE_NORMAL 0
#define ASUS_FAN_BOOST_MODE_OVERBOOST 1
#define ASUS_FAN_BOOST_MODE_OVERBOOST_MASK 0x01
#define ASUS_FAN_BOOST_MODE_SILENT 2
#define ASUS_FAN_BOOST_MODE_SILENT_MASK 0x02
#define ASUS_FAN_BOOST_MODES_MASK 0x03
platform/x86: asus-wmi: Set specified XUSB2PR value for X550LB The bluetooth adapter Atheros AR3012 can't be enumerated and make the bluetooth function broken. T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3362 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb The error is: usb 2-6: device not accepting address 7, error -62 usb usb2-port6: unable to enumerate USB device It is caused by adapter's connected port is mapped to xHC controller, but the xHCI is not supported by the usb device. The output of 'sudo lspci -nnxxx -s 00:14.0': 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) 00: 86 80 31 9c 06 04 90 02 04 30 03 0c 00 00 00 00 10: 04 00 a0 f7 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 1f 20 30: 00 00 00 00 70 00 00 00 00 00 00 00 0b 01 00 00 40: fd 01 36 80 89 c6 0f 80 00 00 00 00 00 00 00 00 50: 5f 2e ce 0f 00 00 00 00 00 00 00 00 00 00 00 00 60: 30 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 01 80 c2 c1 08 00 00 00 00 00 00 00 00 00 00 00 80: 05 00 87 00 0c a0 e0 fe 00 00 00 00 a1 41 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 0f 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 03 c0 30 00 00 00 00 00 03 0c 00 00 00 00 00 00 d0: f9 01 00 00 f9 01 00 00 0f 00 00 00 0f 00 00 00 e0: 00 08 00 00 00 00 00 00 00 00 00 00 d8 d8 00 00 f0: 00 00 00 00 00 00 00 00 b1 0f 04 08 00 00 00 00 By referencing Intel Platform Controller Hub(PCH) datasheet, the xHC USB 2.0 Port Routing(XUSB2PR) at offset 0xD0-0xD3h decides the setting of mapping the port to EHCI controller or xHC controller. And the port mapped to xHC will enable xHCI during bus resume. The setting of disabling bluetooth adapter's connected port is 0x000001D9. The value can be obtained by few times 1 bit flip operation. The suited configuration should have the 'lsusb -t' result with bluetooth using ehci: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 6: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 6: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M Signed-off-by: Kai-Chuan Hsieh <kai.chiuan@gmail.com> Acked-by: Corentin Chary <corentin.chary@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> [andy: resolve merge conflict in asus-wmi.h] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-09-01 09:55:55 -06:00
#define USB_INTEL_XUSB2PR 0xD0
#define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI 0x9c31
#define ASUS_ACPI_UID_ASUSWMI "ASUSWMI"
platform/x86: asus-wmi: Support WMI event queue Event codes are expected to be retrieved from a queue on at least some models. Specifically, very likely the ACPI WMI devices with _UID ATK are queued whereas those with ASUSWMI are not [1]. The WMI event codes are pushed into a circular buffer queue. After the INIT method is called, ACPI code is allowed to push events into this buffer. The INIT method cannot be reverted. If the module is unloaded and an event (such as hotkey press) gets emitted before inserting it back the events get processed delayed by one or if the queue overflows, additionally delayed by about 3 seconds. It might be considered a minor issue and no normal user would likely observe this (there is little reason unloading the driver), but it does significantly frustrate a developer who is unlucky enough to encounter this. Therefore, the fallback to unqueued behavior occurs whenever something unexpected happens. The fix flushes the old key codes out of the queue on load. After receiving event the queue is read until either ..FFFF or 1 is encountered. Also as noted in [1] it is checked whether notify code is equal to 0xFF before enabling queue processing in WMI notify handler. DSDT examples: FX505GM Device (ATKD) { .. Name (ATKQ, Package (0x10) { 0xFFFFFFFF, .. } Method (IANQ, 1, Serialized) { If ((AQNO >= 0x10)) { Local0 = 0x64 While ((Local0 && (AQNO >= 0x10))) { Local0-- Sleep (0x0A) } ... .. AQTI++ AQTI &= 0x0F ATKQ [AQTI] = Arg0 ... } Method (GANQ, 0, Serialized) { .. If (AQNO) { ... Local0 = DerefOf (ATKQ [AQHI]) AQHI++ AQHI &= 0x0F Return (Local0) } Return (One) } This code is almost identical to K54C, which does return Ones on empty queue. K54C: Method (GANQ, 0, Serialized) { If (AQNO) { ... Return (Local0) } Return (Ones) } [1] Link: https://lkml.org/lkml/2019/4/12/104 Signed-off-by: Yurii Pavlovskyi <yurii.pavlovskyi@gmail.com> Suggested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-05-14 13:02:09 -06:00
#define ASUS_ACPI_UID_ATK "ATK"
#define WMI_EVENT_QUEUE_SIZE 0x10
#define WMI_EVENT_QUEUE_END 0x1
#define WMI_EVENT_MASK 0xFFFF
/* The WMI hotkey event value is always the same. */
#define WMI_EVENT_VALUE_ATK 0xFF
#define WMI_EVENT_MASK 0xFFFF
static const char * const ashs_ids[] = { "ATK4001", "ATK4002", NULL };
platform/x86: asus-wmi: Fix NULL pointer dereference Do not perform the rfkill cleanup routine when (asus->driver->wlan_ctrl_by_user && ashs_present()) is true, since nothing is registered with the rfkill subsystem in that case. Doing so leads to the following kernel NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 PGD 1a3aa8067 PUD 1a3b3d067 PMD 0 Oops: 0002 [#1] PREEMPT SMP Modules linked in: bnep ccm binfmt_misc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core hid_a4tech videodev x86_pkg_temp_thermal intel_powerclamp coretemp ath3k btusb btrtl btintel bluetooth kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic irqbypass crc32c_intel arc4 i915 snd_hda_intel snd_hda_codec ath9k ath9k_common ath9k_hw ath i2c_algo_bit snd_hwdep mac80211 ghash_clmulni_intel snd_hda_core snd_pcm snd_timer cfg80211 ehci_pci xhci_pci drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_hcd ehci_hcd asus_nb_wmi(-) asus_wmi sparse_keymap r8169 rfkill mxm_wmi serio_raw snd mii mei_me lpc_ich i2c_i801 video soundcore mei i2c_smbus wmi i2c_core mfd_core CPU: 3 PID: 3275 Comm: modprobe Not tainted 4.9.34-gentoo #34 Hardware name: ASUSTeK COMPUTER INC. K56CM/K56CM, BIOS K56CM.206 08/21/2012 task: ffff8801a639ba00 task.stack: ffffc900014cc000 RIP: 0010:[<ffffffff816c7348>] [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 RSP: 0018:ffffc900014cfce0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8801a54315b0 RCX: 00000000c0000100 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8801a54315b4 RBP: ffffc900014cfd30 R08: 0000000000000000 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801a54315b4 R13: ffff8801a639ba00 R14: 00000000ffffffff R15: ffff8801a54315b8 FS: 00007faa254fb700(0000) GS:ffff8801aef80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001a3b1b000 CR4: 00000000001406e0 Stack: ffff8801a54315b8 0000000000000000 ffffffff814733ae ffffc900014cfd28 ffffffff8146a28c ffff8801a54315b0 0000000000000000 ffff8801a54315b0 ffff8801a66f3820 0000000000000000 ffffc900014cfd48 ffffffff816c73e7 Call Trace: [<ffffffff814733ae>] ? acpi_ut_release_mutex+0x5d/0x61 [<ffffffff8146a28c>] ? acpi_ns_get_node+0x49/0x52 [<ffffffff816c73e7>] mutex_lock+0x17/0x30 [<ffffffffa00a3bb4>] asus_rfkill_hotplug+0x24/0x1a0 [asus_wmi] [<ffffffffa00a4421>] asus_wmi_rfkill_exit+0x61/0x150 [asus_wmi] [<ffffffffa00a49f1>] asus_wmi_remove+0x61/0xb0 [asus_wmi] [<ffffffff814a5128>] platform_drv_remove+0x28/0x40 [<ffffffff814a2901>] __device_release_driver+0xa1/0x160 [<ffffffff814a29e3>] device_release_driver+0x23/0x30 [<ffffffff814a1ffd>] bus_remove_device+0xfd/0x170 [<ffffffff8149e5a9>] device_del+0x139/0x270 [<ffffffff814a5028>] platform_device_del+0x28/0x90 [<ffffffff814a50a2>] platform_device_unregister+0x12/0x30 [<ffffffffa00a4209>] asus_wmi_unregister_driver+0x19/0x30 [asus_wmi] [<ffffffffa00da0ea>] asus_nb_wmi_exit+0x10/0xf26 [asus_nb_wmi] [<ffffffff8110c692>] SyS_delete_module+0x192/0x270 [<ffffffff810022b2>] ? exit_to_usermode_loop+0x92/0xa0 [<ffffffff816ca560>] entry_SYSCALL_64_fastpath+0x13/0x94 Code: e8 5e 30 00 00 8b 03 83 f8 01 0f 84 93 00 00 00 48 8b 43 10 4c 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> 89 20 4c 89 6c 24 10 eb 1d 4c 89 e7 49 c7 45 08 02 00 00 00 RIP [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 RSP <ffffc900014cfce0> CR2: 0000000000000000 ---[ end trace 8d484233fa7cb512 ]--- note: modprobe[3275] exited with preempt_count 2 https://bugzilla.kernel.org/show_bug.cgi?id=196467 Reported-by: red.f0xyz@gmail.com Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2018-05-22 15:30:15 -06:00
static bool ashs_present(void)
{
int i = 0;
while (ashs_ids[i]) {
if (acpi_dev_found(ashs_ids[i++]))
return true;
}
return false;
}
struct bios_args {
u32 arg0;
u32 arg1;
u32 arg2; /* At least TUF Gaming series uses 3 dword input buffer. */
2020-05-22 01:44:24 -06:00
u32 arg4;
u32 arg5;
} __packed;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
/*
* Struct that's used for all methods called via AGFN. Naming is
* identically to the AML code.
*/
struct agfn_args {
u16 mfun; /* probably "Multi-function" to be called */
u16 sfun; /* probably "Sub-function" to be called */
u16 len; /* size of the hole struct, including subfunction fields */
u8 stas; /* not used by now */
u8 err; /* zero on success */
} __packed;
/* struct used for calling fan read and write methods */
struct agfn_fan_args {
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
struct agfn_args agfn; /* common fields */
u8 fan; /* fan number: 0: set auto mode 1: 1st fan */
u32 speed; /* read: RPM/100 - write: 0-255 */
} __packed;
/*
* <platform>/ - debugfs root directory
* dev_id - current dev_id
* ctrl_param - current ctrl_param
* method_id - current method_id
* devs - call DEVS(dev_id, ctrl_param) and print result
* dsts - call DSTS(dev_id) and print result
* call - call method_id(dev_id, ctrl_param) and print result
*/
struct asus_wmi_debug {
struct dentry *root;
u32 method_id;
u32 dev_id;
u32 ctrl_param;
};
struct asus_rfkill {
struct asus_wmi *asus;
struct rfkill *rfkill;
u32 dev_id;
};
enum fan_type {
FAN_TYPE_NONE = 0,
FAN_TYPE_AGFN, /* deprecated on newer platforms */
FAN_TYPE_SPEC83, /* starting in Spec 8.3, use CPU_FAN_CTRL */
};
struct asus_wmi {
int dsts_id;
int spec;
int sfun;
platform/x86: asus-wmi: Support WMI event queue Event codes are expected to be retrieved from a queue on at least some models. Specifically, very likely the ACPI WMI devices with _UID ATK are queued whereas those with ASUSWMI are not [1]. The WMI event codes are pushed into a circular buffer queue. After the INIT method is called, ACPI code is allowed to push events into this buffer. The INIT method cannot be reverted. If the module is unloaded and an event (such as hotkey press) gets emitted before inserting it back the events get processed delayed by one or if the queue overflows, additionally delayed by about 3 seconds. It might be considered a minor issue and no normal user would likely observe this (there is little reason unloading the driver), but it does significantly frustrate a developer who is unlucky enough to encounter this. Therefore, the fallback to unqueued behavior occurs whenever something unexpected happens. The fix flushes the old key codes out of the queue on load. After receiving event the queue is read until either ..FFFF or 1 is encountered. Also as noted in [1] it is checked whether notify code is equal to 0xFF before enabling queue processing in WMI notify handler. DSDT examples: FX505GM Device (ATKD) { .. Name (ATKQ, Package (0x10) { 0xFFFFFFFF, .. } Method (IANQ, 1, Serialized) { If ((AQNO >= 0x10)) { Local0 = 0x64 While ((Local0 && (AQNO >= 0x10))) { Local0-- Sleep (0x0A) } ... .. AQTI++ AQTI &= 0x0F ATKQ [AQTI] = Arg0 ... } Method (GANQ, 0, Serialized) { .. If (AQNO) { ... Local0 = DerefOf (ATKQ [AQHI]) AQHI++ AQHI &= 0x0F Return (Local0) } Return (One) } This code is almost identical to K54C, which does return Ones on empty queue. K54C: Method (GANQ, 0, Serialized) { If (AQNO) { ... Return (Local0) } Return (Ones) } [1] Link: https://lkml.org/lkml/2019/4/12/104 Signed-off-by: Yurii Pavlovskyi <yurii.pavlovskyi@gmail.com> Suggested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-05-14 13:02:09 -06:00
bool wmi_event_queue;
struct input_dev *inputdev;
struct backlight_device *backlight_device;
struct platform_device *platform_device;
struct led_classdev wlan_led;
int wlan_led_wk;
struct led_classdev tpd_led;
int tpd_led_wk;
struct led_classdev kbd_led;
int kbd_led_wk;
struct led_classdev lightbar_led;
int lightbar_led_wk;
struct workqueue_struct *led_workqueue;
struct work_struct tpd_led_work;
struct work_struct wlan_led_work;
struct work_struct lightbar_led_work;
struct asus_rfkill wlan;
struct asus_rfkill bluetooth;
struct asus_rfkill wimax;
struct asus_rfkill wwan3g;
struct asus_rfkill gps;
struct asus_rfkill uwb;
enum fan_type fan_type;
int fan_pwm_mode;
int agfn_pwm;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
bool fan_boost_mode_available;
u8 fan_boost_mode_mask;
u8 fan_boost_mode;
// The RSOC controls the maximum charging percentage.
bool battery_rsoc_available;
PCI: hotplug: Embed hotplug_slot When the PCI hotplug core and its first user, cpqphp, were introduced in February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot struct for its internal use plus a hotplug_slot struct to be registered with the hotplug core and linked the two with pointers: https://git.kernel.org/tglx/history/c/a8a2069f432c Nowadays, the predominant pattern in the tree is to embed ("subclass") such structures in one another and cast to the containing struct with container_of(). But it wasn't until July 2002 that container_of() was introduced with historic commit ec4f214232cf: https://git.kernel.org/tglx/history/c/ec4f214232cf pnv_php, introduced in 2016, did the right thing and embedded struct hotplug_slot in its internal struct pnv_php_slot, but all other drivers cargo-culted cpqphp's design and linked separate structs with pointers. Embedding structs is preferrable to linking them with pointers because it requires fewer allocations, thereby reducing overhead and simplifying error paths. Casting an embedded struct to the containing struct becomes a cheap subtraction rather than a dereference. And having fewer pointers reduces the risk of them pointing nowhere either accidentally or due to an attack. Convert all drivers to embed struct hotplug_slot in their internal slot struct. The "private" pointer in struct hotplug_slot thereby becomes unused, so drop it. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Sebastian Ott <sebott@linux.ibm.com> # drivers/pci/hotplug/s390* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
2018-09-08 01:59:01 -06:00
struct hotplug_slot hotplug_slot;
struct mutex hotplug_lock;
struct mutex wmi_lock;
struct workqueue_struct *hotplug_workqueue;
struct work_struct hotplug_work;
bool fnlock_locked;
struct asus_wmi_debug debug;
struct asus_wmi_driver *driver;
};
/* Input **********************************************************************/
static int asus_wmi_input_init(struct asus_wmi *asus)
{
int err;
asus->inputdev = input_allocate_device();
if (!asus->inputdev)
return -ENOMEM;
asus->inputdev->name = asus->driver->input_name;
asus->inputdev->phys = asus->driver->input_phys;
asus->inputdev->id.bustype = BUS_HOST;
asus->inputdev->dev.parent = &asus->platform_device->dev;
set_bit(EV_REP, asus->inputdev->evbit);
err = sparse_keymap_setup(asus->inputdev, asus->driver->keymap, NULL);
if (err)
goto err_free_dev;
err = input_register_device(asus->inputdev);
if (err)
goto err_free_dev;
return 0;
err_free_dev:
input_free_device(asus->inputdev);
return err;
}
static void asus_wmi_input_exit(struct asus_wmi *asus)
{
if (asus->inputdev)
input_unregister_device(asus->inputdev);
asus->inputdev = NULL;
}
/* WMI ************************************************************************/
static int asus_wmi_evaluate_method3(u32 method_id,
u32 arg0, u32 arg1, u32 arg2, u32 *retval)
{
struct bios_args args = {
.arg0 = arg0,
.arg1 = arg1,
.arg2 = arg2,
};
struct acpi_buffer input = { (acpi_size) sizeof(args), &args };
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
acpi_status status;
union acpi_object *obj;
u32 tmp = 0;
status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID, 0, method_id,
&input, &output);
if (ACPI_FAILURE(status))
return -EIO;
obj = (union acpi_object *)output.pointer;
if (obj && obj->type == ACPI_TYPE_INTEGER)
tmp = (u32) obj->integer.value;
if (retval)
*retval = tmp;
kfree(obj);
if (tmp == ASUS_WMI_UNSUPPORTED_METHOD)
return -ENODEV;
return 0;
}
int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1, u32 *retval)
{
return asus_wmi_evaluate_method3(method_id, arg0, arg1, 0, retval);
}
EXPORT_SYMBOL_GPL(asus_wmi_evaluate_method);
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
static int asus_wmi_evaluate_method_agfn(const struct acpi_buffer args)
{
struct acpi_buffer input;
u64 phys_addr;
u32 retval;
u32 status = -1;
/*
* Copy to dma capable address otherwise memory corruption occurs as
* bios has to be able to access it.
*/
input.pointer = kmemdup(args.pointer, args.length, GFP_DMA | GFP_KERNEL);
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
input.length = args.length;
if (!input.pointer)
return -ENOMEM;
phys_addr = virt_to_phys(input.pointer);
status = asus_wmi_evaluate_method(ASUS_WMI_METHODID_AGFN,
phys_addr, 0, &retval);
if (!status)
memcpy(args.pointer, input.pointer, args.length);
kfree(input.pointer);
if (status)
return -ENXIO;
return retval;
}
static int asus_wmi_get_devstate(struct asus_wmi *asus, u32 dev_id, u32 *retval)
{
return asus_wmi_evaluate_method(asus->dsts_id, dev_id, 0, retval);
}
static int asus_wmi_set_devstate(u32 dev_id, u32 ctrl_param,
u32 *retval)
{
return asus_wmi_evaluate_method(ASUS_WMI_METHODID_DEVS, dev_id,
ctrl_param, retval);
}
/* Helper for special devices with magic return codes */
static int asus_wmi_get_devstate_bits(struct asus_wmi *asus,
u32 dev_id, u32 mask)
{
u32 retval = 0;
int err;
err = asus_wmi_get_devstate(asus, dev_id, &retval);
if (err < 0)
return err;
if (!(retval & ASUS_WMI_DSTS_PRESENCE_BIT))
return -ENODEV;
if (mask == ASUS_WMI_DSTS_STATUS_BIT) {
if (retval & ASUS_WMI_DSTS_UNKNOWN_BIT)
return -ENODEV;
}
return retval & mask;
}
static int asus_wmi_get_devstate_simple(struct asus_wmi *asus, u32 dev_id)
{
return asus_wmi_get_devstate_bits(asus, dev_id,
ASUS_WMI_DSTS_STATUS_BIT);
}
static bool asus_wmi_dev_is_present(struct asus_wmi *asus, u32 dev_id)
{
u32 retval;
int status = asus_wmi_get_devstate(asus, dev_id, &retval);
return status == 0 && (retval & ASUS_WMI_DSTS_PRESENCE_BIT);
}
/* Battery ********************************************************************/
/* The battery maximum charging percentage */
static int charge_end_threshold;
static ssize_t charge_control_end_threshold_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
int value, ret, rv;
ret = kstrtouint(buf, 10, &value);
if (ret)
return ret;
if (value < 0 || value > 100)
return -EINVAL;
ret = asus_wmi_set_devstate(ASUS_WMI_DEVID_RSOC, value, &rv);
if (ret)
return ret;
if (rv != 1)
return -EIO;
/* There isn't any method in the DSDT to read the threshold, so we
* save the threshold.
*/
charge_end_threshold = value;
return count;
}
static ssize_t charge_control_end_threshold_show(struct device *device,
struct device_attribute *attr,
char *buf)
{
return sprintf(buf, "%d\n", charge_end_threshold);
}
static DEVICE_ATTR_RW(charge_control_end_threshold);
static int asus_wmi_battery_add(struct power_supply *battery)
{
/* The WMI method does not provide a way to specific a battery, so we
* just assume it is the first battery.
* Note: On some newer ASUS laptops (Zenbook UM431DA), the primary/first
* battery is named BATT.
*/
if (strcmp(battery->desc->name, "BAT0") != 0 &&
strcmp(battery->desc->name, "BAT1") != 0 &&
strcmp(battery->desc->name, "BATT") != 0)
return -ENODEV;
if (device_create_file(&battery->dev,
&dev_attr_charge_control_end_threshold))
return -ENODEV;
/* The charge threshold is only reset when the system is power cycled,
* and we can't get the current threshold so let set it to 100% when
* a battery is added.
*/
asus_wmi_set_devstate(ASUS_WMI_DEVID_RSOC, 100, NULL);
charge_end_threshold = 100;
return 0;
}
static int asus_wmi_battery_remove(struct power_supply *battery)
{
device_remove_file(&battery->dev,
&dev_attr_charge_control_end_threshold);
return 0;
}
static struct acpi_battery_hook battery_hook = {
.add_battery = asus_wmi_battery_add,
.remove_battery = asus_wmi_battery_remove,
.name = "ASUS Battery Extension",
};
static void asus_wmi_battery_init(struct asus_wmi *asus)
{
asus->battery_rsoc_available = false;
if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_RSOC)) {
asus->battery_rsoc_available = true;
battery_hook_register(&battery_hook);
}
}
static void asus_wmi_battery_exit(struct asus_wmi *asus)
{
if (asus->battery_rsoc_available)
battery_hook_unregister(&battery_hook);
}
/* LEDs ***********************************************************************/
/*
* These functions actually update the LED's, and are called from a
* workqueue. By doing this as separate work rather than when the LED
* subsystem asks, we avoid messing with the Asus ACPI stuff during a
* potentially bad time, such as a timer interrupt.
*/
static void tpd_led_update(struct work_struct *work)
{
int ctrl_param;
struct asus_wmi *asus;
asus = container_of(work, struct asus_wmi, tpd_led_work);
ctrl_param = asus->tpd_led_wk;
asus_wmi_set_devstate(ASUS_WMI_DEVID_TOUCHPAD_LED, ctrl_param, NULL);
}
static void tpd_led_set(struct led_classdev *led_cdev,
enum led_brightness value)
{
struct asus_wmi *asus;
asus = container_of(led_cdev, struct asus_wmi, tpd_led);
asus->tpd_led_wk = !!value;
queue_work(asus->led_workqueue, &asus->tpd_led_work);
}
static int read_tpd_led_state(struct asus_wmi *asus)
{
return asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_TOUCHPAD_LED);
}
static enum led_brightness tpd_led_get(struct led_classdev *led_cdev)
{
struct asus_wmi *asus;
asus = container_of(led_cdev, struct asus_wmi, tpd_led);
return read_tpd_led_state(asus);
}
static void kbd_led_update(struct asus_wmi *asus)
{
int ctrl_param = 0;
ctrl_param = 0x80 | (asus->kbd_led_wk & 0x7F);
asus_wmi_set_devstate(ASUS_WMI_DEVID_KBD_BACKLIGHT, ctrl_param, NULL);
}
static int kbd_led_read(struct asus_wmi *asus, int *level, int *env)
{
int retval;
/*
* bits 0-2: level
* bit 7: light on/off
* bit 8-10: environment (0: dark, 1: normal, 2: light)
* bit 17: status unknown
*/
retval = asus_wmi_get_devstate_bits(asus, ASUS_WMI_DEVID_KBD_BACKLIGHT,
0xFFFF);
/* Unknown status is considered as off */
if (retval == 0x8000)
retval = 0;
if (retval < 0)
return retval;
if (level)
*level = retval & 0x7F;
if (env)
*env = (retval >> 8) & 0x7F;
return 0;
}
static void do_kbd_led_set(struct led_classdev *led_cdev, int value)
{
struct asus_wmi *asus;
int max_level;
asus = container_of(led_cdev, struct asus_wmi, kbd_led);
max_level = asus->kbd_led.max_brightness;
asus->kbd_led_wk = clamp_val(value, 0, max_level);
kbd_led_update(asus);
}
static void kbd_led_set(struct led_classdev *led_cdev,
enum led_brightness value)
{
/* Prevent disabling keyboard backlight on module unregister */
if (led_cdev->flags & LED_UNREGISTERING)
return;
do_kbd_led_set(led_cdev, value);
}
static void kbd_led_set_by_kbd(struct asus_wmi *asus, enum led_brightness value)
{
struct led_classdev *led_cdev = &asus->kbd_led;
do_kbd_led_set(led_cdev, value);
led_classdev_notify_brightness_hw_changed(led_cdev, asus->kbd_led_wk);
}
static enum led_brightness kbd_led_get(struct led_classdev *led_cdev)
{
struct asus_wmi *asus;
int retval, value;
asus = container_of(led_cdev, struct asus_wmi, kbd_led);
retval = kbd_led_read(asus, &value, NULL);
if (retval < 0)
return retval;
return value;
}
static int wlan_led_unknown_state(struct asus_wmi *asus)
{
u32 result;
asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_WIRELESS_LED, &result);
return result & ASUS_WMI_DSTS_UNKNOWN_BIT;
}
static void wlan_led_update(struct work_struct *work)
{
int ctrl_param;
struct asus_wmi *asus;
asus = container_of(work, struct asus_wmi, wlan_led_work);
ctrl_param = asus->wlan_led_wk;
asus_wmi_set_devstate(ASUS_WMI_DEVID_WIRELESS_LED, ctrl_param, NULL);
}
static void wlan_led_set(struct led_classdev *led_cdev,
enum led_brightness value)
{
struct asus_wmi *asus;
asus = container_of(led_cdev, struct asus_wmi, wlan_led);
asus->wlan_led_wk = !!value;
queue_work(asus->led_workqueue, &asus->wlan_led_work);
}
static enum led_brightness wlan_led_get(struct led_classdev *led_cdev)
{
struct asus_wmi *asus;
u32 result;
asus = container_of(led_cdev, struct asus_wmi, wlan_led);
asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_WIRELESS_LED, &result);
return result & ASUS_WMI_DSTS_BRIGHTNESS_MASK;
}
static void lightbar_led_update(struct work_struct *work)
{
struct asus_wmi *asus;
int ctrl_param;
asus = container_of(work, struct asus_wmi, lightbar_led_work);
ctrl_param = asus->lightbar_led_wk;
asus_wmi_set_devstate(ASUS_WMI_DEVID_LIGHTBAR, ctrl_param, NULL);
}
static void lightbar_led_set(struct led_classdev *led_cdev,
enum led_brightness value)
{
struct asus_wmi *asus;
asus = container_of(led_cdev, struct asus_wmi, lightbar_led);
asus->lightbar_led_wk = !!value;
queue_work(asus->led_workqueue, &asus->lightbar_led_work);
}
static enum led_brightness lightbar_led_get(struct led_classdev *led_cdev)
{
struct asus_wmi *asus;
u32 result;
asus = container_of(led_cdev, struct asus_wmi, lightbar_led);
asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_LIGHTBAR, &result);
return result & ASUS_WMI_DSTS_LIGHTBAR_MASK;
}
static void asus_wmi_led_exit(struct asus_wmi *asus)
{
if (!IS_ERR_OR_NULL(asus->kbd_led.dev))
led_classdev_unregister(&asus->kbd_led);
if (!IS_ERR_OR_NULL(asus->tpd_led.dev))
led_classdev_unregister(&asus->tpd_led);
if (!IS_ERR_OR_NULL(asus->wlan_led.dev))
led_classdev_unregister(&asus->wlan_led);
if (!IS_ERR_OR_NULL(asus->lightbar_led.dev))
led_classdev_unregister(&asus->lightbar_led);
if (asus->led_workqueue)
destroy_workqueue(asus->led_workqueue);
}
static int asus_wmi_led_init(struct asus_wmi *asus)
{
int rv = 0, led_val;
asus->led_workqueue = create_singlethread_workqueue("led_workqueue");
if (!asus->led_workqueue)
return -ENOMEM;
if (read_tpd_led_state(asus) >= 0) {
INIT_WORK(&asus->tpd_led_work, tpd_led_update);
asus->tpd_led.name = "asus::touchpad";
asus->tpd_led.brightness_set = tpd_led_set;
asus->tpd_led.brightness_get = tpd_led_get;
asus->tpd_led.max_brightness = 1;
rv = led_classdev_register(&asus->platform_device->dev,
&asus->tpd_led);
if (rv)
goto error;
}
if (!kbd_led_read(asus, &led_val, NULL)) {
asus->kbd_led_wk = led_val;
asus->kbd_led.name = "asus::kbd_backlight";
asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
asus->kbd_led.brightness_set = kbd_led_set;
asus->kbd_led.brightness_get = kbd_led_get;
asus->kbd_led.max_brightness = 3;
rv = led_classdev_register(&asus->platform_device->dev,
&asus->kbd_led);
if (rv)
goto error;
}
if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_WIRELESS_LED)
&& (asus->driver->quirks->wapf > 0)) {
INIT_WORK(&asus->wlan_led_work, wlan_led_update);
asus->wlan_led.name = "asus::wlan";
asus->wlan_led.brightness_set = wlan_led_set;
if (!wlan_led_unknown_state(asus))
asus->wlan_led.brightness_get = wlan_led_get;
asus->wlan_led.flags = LED_CORE_SUSPENDRESUME;
asus->wlan_led.max_brightness = 1;
asus->wlan_led.default_trigger = "asus-wlan";
rv = led_classdev_register(&asus->platform_device->dev,
&asus->wlan_led);
if (rv)
goto error;
}
if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_LIGHTBAR)) {
INIT_WORK(&asus->lightbar_led_work, lightbar_led_update);
asus->lightbar_led.name = "asus::lightbar";
asus->lightbar_led.brightness_set = lightbar_led_set;
asus->lightbar_led.brightness_get = lightbar_led_get;
asus->lightbar_led.max_brightness = 1;
rv = led_classdev_register(&asus->platform_device->dev,
&asus->lightbar_led);
}
error:
if (rv)
asus_wmi_led_exit(asus);
return rv;
}
/* RF *************************************************************************/
/*
* PCI hotplug (for wlan rfkill)
*/
static bool asus_wlan_rfkill_blocked(struct asus_wmi *asus)
{
int result = asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_WLAN);
if (result < 0)
return false;
return !result;
}
static void asus_rfkill_hotplug(struct asus_wmi *asus)
{
struct pci_dev *dev;
struct pci_bus *bus;
bool blocked;
bool absent;
u32 l;
mutex_lock(&asus->wmi_lock);
blocked = asus_wlan_rfkill_blocked(asus);
mutex_unlock(&asus->wmi_lock);
mutex_lock(&asus->hotplug_lock);
pci_lock_rescan_remove();
if (asus->wlan.rfkill)
rfkill_set_sw_state(asus->wlan.rfkill, blocked);
PCI: hotplug: Embed hotplug_slot When the PCI hotplug core and its first user, cpqphp, were introduced in February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot struct for its internal use plus a hotplug_slot struct to be registered with the hotplug core and linked the two with pointers: https://git.kernel.org/tglx/history/c/a8a2069f432c Nowadays, the predominant pattern in the tree is to embed ("subclass") such structures in one another and cast to the containing struct with container_of(). But it wasn't until July 2002 that container_of() was introduced with historic commit ec4f214232cf: https://git.kernel.org/tglx/history/c/ec4f214232cf pnv_php, introduced in 2016, did the right thing and embedded struct hotplug_slot in its internal struct pnv_php_slot, but all other drivers cargo-culted cpqphp's design and linked separate structs with pointers. Embedding structs is preferrable to linking them with pointers because it requires fewer allocations, thereby reducing overhead and simplifying error paths. Casting an embedded struct to the containing struct becomes a cheap subtraction rather than a dereference. And having fewer pointers reduces the risk of them pointing nowhere either accidentally or due to an attack. Convert all drivers to embed struct hotplug_slot in their internal slot struct. The "private" pointer in struct hotplug_slot thereby becomes unused, so drop it. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Sebastian Ott <sebott@linux.ibm.com> # drivers/pci/hotplug/s390* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
2018-09-08 01:59:01 -06:00
if (asus->hotplug_slot.ops) {
bus = pci_find_bus(0, 1);
if (!bus) {
pr_warn("Unable to find PCI bus 1?\n");
goto out_unlock;
}
if (pci_bus_read_config_dword(bus, 0, PCI_VENDOR_ID, &l)) {
pr_err("Unable to read PCI config space?\n");
goto out_unlock;
}
absent = (l == 0xffffffff);
if (blocked != absent) {
pr_warn("BIOS says wireless lan is %s, "
"but the pci device is %s\n",
blocked ? "blocked" : "unblocked",
absent ? "absent" : "present");
pr_warn("skipped wireless hotplug as probably "
"inappropriate for this model\n");
goto out_unlock;
}
if (!blocked) {
dev = pci_get_slot(bus, 0);
if (dev) {
/* Device already present */
pci_dev_put(dev);
goto out_unlock;
}
dev = pci_scan_single_device(bus, 0);
if (dev) {
pci_bus_assign_resources(bus);
pci_bus_add_device(dev);
}
} else {
dev = pci_get_slot(bus, 0);
if (dev) {
pci_stop_and_remove_bus_device(dev);
pci_dev_put(dev);
}
}
}
out_unlock:
pci_unlock_rescan_remove();
mutex_unlock(&asus->hotplug_lock);
}
static void asus_rfkill_notify(acpi_handle handle, u32 event, void *data)
{
struct asus_wmi *asus = data;
if (event != ACPI_NOTIFY_BUS_CHECK)
return;
/*
* We can't call directly asus_rfkill_hotplug because most
* of the time WMBC is still being executed and not reetrant.
* There is currently no way to tell ACPICA that we want this
* method to be serialized, we schedule a asus_rfkill_hotplug
* call later, in a safer context.
*/
queue_work(asus->hotplug_workqueue, &asus->hotplug_work);
}
static int asus_register_rfkill_notifier(struct asus_wmi *asus, char *node)
{
acpi_status status;
acpi_handle handle;
status = acpi_get_handle(NULL, node, &handle);
if (ACPI_FAILURE(status))
return -ENODEV;
status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
asus_rfkill_notify, asus);
if (ACPI_FAILURE(status))
pr_warn("Failed to register notify on %s\n", node);
return 0;
}
static void asus_unregister_rfkill_notifier(struct asus_wmi *asus, char *node)
{
acpi_status status = AE_OK;
acpi_handle handle;
status = acpi_get_handle(NULL, node, &handle);
if (ACPI_FAILURE(status))
return;
status = acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
asus_rfkill_notify);
if (ACPI_FAILURE(status))
pr_err("Error removing rfkill notify handler %s\n", node);
}
static int asus_get_adapter_status(struct hotplug_slot *hotplug_slot,
u8 *value)
{
PCI: hotplug: Embed hotplug_slot When the PCI hotplug core and its first user, cpqphp, were introduced in February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot struct for its internal use plus a hotplug_slot struct to be registered with the hotplug core and linked the two with pointers: https://git.kernel.org/tglx/history/c/a8a2069f432c Nowadays, the predominant pattern in the tree is to embed ("subclass") such structures in one another and cast to the containing struct with container_of(). But it wasn't until July 2002 that container_of() was introduced with historic commit ec4f214232cf: https://git.kernel.org/tglx/history/c/ec4f214232cf pnv_php, introduced in 2016, did the right thing and embedded struct hotplug_slot in its internal struct pnv_php_slot, but all other drivers cargo-culted cpqphp's design and linked separate structs with pointers. Embedding structs is preferrable to linking them with pointers because it requires fewer allocations, thereby reducing overhead and simplifying error paths. Casting an embedded struct to the containing struct becomes a cheap subtraction rather than a dereference. And having fewer pointers reduces the risk of them pointing nowhere either accidentally or due to an attack. Convert all drivers to embed struct hotplug_slot in their internal slot struct. The "private" pointer in struct hotplug_slot thereby becomes unused, so drop it. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Sebastian Ott <sebott@linux.ibm.com> # drivers/pci/hotplug/s390* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
2018-09-08 01:59:01 -06:00
struct asus_wmi *asus = container_of(hotplug_slot,
struct asus_wmi, hotplug_slot);
int result = asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_WLAN);
if (result < 0)
return result;
*value = !!result;
return 0;
}
static const struct hotplug_slot_ops asus_hotplug_slot_ops = {
.get_adapter_status = asus_get_adapter_status,
.get_power_status = asus_get_adapter_status,
};
static void asus_hotplug_work(struct work_struct *work)
{
struct asus_wmi *asus;
asus = container_of(work, struct asus_wmi, hotplug_work);
asus_rfkill_hotplug(asus);
}
static int asus_setup_pci_hotplug(struct asus_wmi *asus)
{
int ret = -ENOMEM;
struct pci_bus *bus = pci_find_bus(0, 1);
if (!bus) {
pr_err("Unable to find wifi PCI bus\n");
return -ENODEV;
}
asus->hotplug_workqueue =
create_singlethread_workqueue("hotplug_workqueue");
if (!asus->hotplug_workqueue)
goto error_workqueue;
INIT_WORK(&asus->hotplug_work, asus_hotplug_work);
PCI: hotplug: Embed hotplug_slot When the PCI hotplug core and its first user, cpqphp, were introduced in February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot struct for its internal use plus a hotplug_slot struct to be registered with the hotplug core and linked the two with pointers: https://git.kernel.org/tglx/history/c/a8a2069f432c Nowadays, the predominant pattern in the tree is to embed ("subclass") such structures in one another and cast to the containing struct with container_of(). But it wasn't until July 2002 that container_of() was introduced with historic commit ec4f214232cf: https://git.kernel.org/tglx/history/c/ec4f214232cf pnv_php, introduced in 2016, did the right thing and embedded struct hotplug_slot in its internal struct pnv_php_slot, but all other drivers cargo-culted cpqphp's design and linked separate structs with pointers. Embedding structs is preferrable to linking them with pointers because it requires fewer allocations, thereby reducing overhead and simplifying error paths. Casting an embedded struct to the containing struct becomes a cheap subtraction rather than a dereference. And having fewer pointers reduces the risk of them pointing nowhere either accidentally or due to an attack. Convert all drivers to embed struct hotplug_slot in their internal slot struct. The "private" pointer in struct hotplug_slot thereby becomes unused, so drop it. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Sebastian Ott <sebott@linux.ibm.com> # drivers/pci/hotplug/s390* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
2018-09-08 01:59:01 -06:00
asus->hotplug_slot.ops = &asus_hotplug_slot_ops;
PCI: hotplug: Embed hotplug_slot When the PCI hotplug core and its first user, cpqphp, were introduced in February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot struct for its internal use plus a hotplug_slot struct to be registered with the hotplug core and linked the two with pointers: https://git.kernel.org/tglx/history/c/a8a2069f432c Nowadays, the predominant pattern in the tree is to embed ("subclass") such structures in one another and cast to the containing struct with container_of(). But it wasn't until July 2002 that container_of() was introduced with historic commit ec4f214232cf: https://git.kernel.org/tglx/history/c/ec4f214232cf pnv_php, introduced in 2016, did the right thing and embedded struct hotplug_slot in its internal struct pnv_php_slot, but all other drivers cargo-culted cpqphp's design and linked separate structs with pointers. Embedding structs is preferrable to linking them with pointers because it requires fewer allocations, thereby reducing overhead and simplifying error paths. Casting an embedded struct to the containing struct becomes a cheap subtraction rather than a dereference. And having fewer pointers reduces the risk of them pointing nowhere either accidentally or due to an attack. Convert all drivers to embed struct hotplug_slot in their internal slot struct. The "private" pointer in struct hotplug_slot thereby becomes unused, so drop it. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Sebastian Ott <sebott@linux.ibm.com> # drivers/pci/hotplug/s390* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
2018-09-08 01:59:01 -06:00
ret = pci_hp_register(&asus->hotplug_slot, bus, 0, "asus-wifi");
if (ret) {
pr_err("Unable to register hotplug slot - %d\n", ret);
goto error_register;
}
return 0;
error_register:
PCI: hotplug: Embed hotplug_slot When the PCI hotplug core and its first user, cpqphp, were introduced in February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot struct for its internal use plus a hotplug_slot struct to be registered with the hotplug core and linked the two with pointers: https://git.kernel.org/tglx/history/c/a8a2069f432c Nowadays, the predominant pattern in the tree is to embed ("subclass") such structures in one another and cast to the containing struct with container_of(). But it wasn't until July 2002 that container_of() was introduced with historic commit ec4f214232cf: https://git.kernel.org/tglx/history/c/ec4f214232cf pnv_php, introduced in 2016, did the right thing and embedded struct hotplug_slot in its internal struct pnv_php_slot, but all other drivers cargo-culted cpqphp's design and linked separate structs with pointers. Embedding structs is preferrable to linking them with pointers because it requires fewer allocations, thereby reducing overhead and simplifying error paths. Casting an embedded struct to the containing struct becomes a cheap subtraction rather than a dereference. And having fewer pointers reduces the risk of them pointing nowhere either accidentally or due to an attack. Convert all drivers to embed struct hotplug_slot in their internal slot struct. The "private" pointer in struct hotplug_slot thereby becomes unused, so drop it. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Sebastian Ott <sebott@linux.ibm.com> # drivers/pci/hotplug/s390* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
2018-09-08 01:59:01 -06:00
asus->hotplug_slot.ops = NULL;
destroy_workqueue(asus->hotplug_workqueue);
error_workqueue:
return ret;
}
/*
* Rfkill devices
*/
static int asus_rfkill_set(void *data, bool blocked)
{
struct asus_rfkill *priv = data;
u32 ctrl_param = !blocked;
asus-wmi: record wlan status while controlled by userapp If the user bit is set, that mean BIOS can't set and record the wlan status, it will report the value read from id ASUS_WMI_DEVID_WLAN_LED (0x00010012) while we query the wlan status by id ASUS_WMI_DEVID_WLAN (0x00010011) through WMI. So, we have to record wlan status in id ASUS_WMI_DEVID_WLAN_LED (0x00010012) while setting the wlan status through WMI. This is also the behavior that windows app will do. Quote from ASUS application engineer === When you call WMIMethod(DSTS, 0x00010011) to get WLAN status, it may return (1) 0x00050001 (On) (2) 0x00050000 (Off) (3) 0x00030001 (On) (4) 0x00030000 (Off) (5) 0x00000002 (Unknown) (1), (2) means that the model has hardware GPIO for WLAN, you can call WMIMethod(DEVS, 0x00010011, 1 or 0) to turn WLAN on/off. (3), (4) means that the model doesn’t have hardware GPIO, you need to use API or driver library to turn WLAN on/off, and call WMIMethod(DEVS, 0x00010012, 1 or 0) to set WLAN LED status. After you set WLAN LED status, you can see the WLAN status is changed with WMIMethod(DSTS, 0x00010011). Because the status is recorded lastly (ex: Windows), you can use it for synchronization. (5) means that the model doesn’t have WLAN device. WLAN is the ONLY special case with upper rule. For other device, like Bluetooth, you just need use WMIMethod(DSTS, 0x00010013) to get, and WMIMethod(DEVS, 0x00010013, 1 or 0) to set. === Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-26 03:13:31 -06:00
u32 dev_id = priv->dev_id;
asus-wmi: record wlan status while controlled by userapp If the user bit is set, that mean BIOS can't set and record the wlan status, it will report the value read from id ASUS_WMI_DEVID_WLAN_LED (0x00010012) while we query the wlan status by id ASUS_WMI_DEVID_WLAN (0x00010011) through WMI. So, we have to record wlan status in id ASUS_WMI_DEVID_WLAN_LED (0x00010012) while setting the wlan status through WMI. This is also the behavior that windows app will do. Quote from ASUS application engineer === When you call WMIMethod(DSTS, 0x00010011) to get WLAN status, it may return (1) 0x00050001 (On) (2) 0x00050000 (Off) (3) 0x00030001 (On) (4) 0x00030000 (Off) (5) 0x00000002 (Unknown) (1), (2) means that the model has hardware GPIO for WLAN, you can call WMIMethod(DEVS, 0x00010011, 1 or 0) to turn WLAN on/off. (3), (4) means that the model doesn’t have hardware GPIO, you need to use API or driver library to turn WLAN on/off, and call WMIMethod(DEVS, 0x00010012, 1 or 0) to set WLAN LED status. After you set WLAN LED status, you can see the WLAN status is changed with WMIMethod(DSTS, 0x00010011). Because the status is recorded lastly (ex: Windows), you can use it for synchronization. (5) means that the model doesn’t have WLAN device. WLAN is the ONLY special case with upper rule. For other device, like Bluetooth, you just need use WMIMethod(DSTS, 0x00010013) to get, and WMIMethod(DEVS, 0x00010013, 1 or 0) to set. === Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-26 03:13:31 -06:00
/*
* If the user bit is set, BIOS can't set and record the wlan status,
* it will report the value read from id ASUS_WMI_DEVID_WLAN_LED
* while we query the wlan status through WMI(ASUS_WMI_DEVID_WLAN).
* So, we have to record wlan status in id ASUS_WMI_DEVID_WLAN_LED
* while setting the wlan status through WMI.
* This is also the behavior that windows app will do.
*/
if ((dev_id == ASUS_WMI_DEVID_WLAN) &&
priv->asus->driver->wlan_ctrl_by_user)
dev_id = ASUS_WMI_DEVID_WLAN_LED;
return asus_wmi_set_devstate(dev_id, ctrl_param, NULL);
}
static void asus_rfkill_query(struct rfkill *rfkill, void *data)
{
struct asus_rfkill *priv = data;
int result;
result = asus_wmi_get_devstate_simple(priv->asus, priv->dev_id);
if (result < 0)
return;
rfkill_set_sw_state(priv->rfkill, !result);
}
static int asus_rfkill_wlan_set(void *data, bool blocked)
{
struct asus_rfkill *priv = data;
struct asus_wmi *asus = priv->asus;
int ret;
/*
* This handler is enabled only if hotplug is enabled.
* In this case, the asus_wmi_set_devstate() will
* trigger a wmi notification and we need to wait
* this call to finish before being able to call
* any wmi method
*/
mutex_lock(&asus->wmi_lock);
ret = asus_rfkill_set(data, blocked);
mutex_unlock(&asus->wmi_lock);
return ret;
}
static const struct rfkill_ops asus_rfkill_wlan_ops = {
.set_block = asus_rfkill_wlan_set,
.query = asus_rfkill_query,
};
static const struct rfkill_ops asus_rfkill_ops = {
.set_block = asus_rfkill_set,
.query = asus_rfkill_query,
};
static int asus_new_rfkill(struct asus_wmi *asus,
struct asus_rfkill *arfkill,
const char *name, enum rfkill_type type, int dev_id)
{
int result = asus_wmi_get_devstate_simple(asus, dev_id);
struct rfkill **rfkill = &arfkill->rfkill;
if (result < 0)
return result;
arfkill->dev_id = dev_id;
arfkill->asus = asus;
if (dev_id == ASUS_WMI_DEVID_WLAN &&
asus->driver->quirks->hotplug_wireless)
*rfkill = rfkill_alloc(name, &asus->platform_device->dev, type,
&asus_rfkill_wlan_ops, arfkill);
else
*rfkill = rfkill_alloc(name, &asus->platform_device->dev, type,
&asus_rfkill_ops, arfkill);
if (!*rfkill)
return -EINVAL;
if ((dev_id == ASUS_WMI_DEVID_WLAN) &&
(asus->driver->quirks->wapf > 0))
rfkill_set_led_trigger_name(*rfkill, "asus-wlan");
rfkill_init_sw_state(*rfkill, !result);
result = rfkill_register(*rfkill);
if (result) {
rfkill_destroy(*rfkill);
*rfkill = NULL;
return result;
}
return 0;
}
static void asus_wmi_rfkill_exit(struct asus_wmi *asus)
{
platform/x86: asus-wmi: Fix NULL pointer dereference Do not perform the rfkill cleanup routine when (asus->driver->wlan_ctrl_by_user && ashs_present()) is true, since nothing is registered with the rfkill subsystem in that case. Doing so leads to the following kernel NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 PGD 1a3aa8067 PUD 1a3b3d067 PMD 0 Oops: 0002 [#1] PREEMPT SMP Modules linked in: bnep ccm binfmt_misc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core hid_a4tech videodev x86_pkg_temp_thermal intel_powerclamp coretemp ath3k btusb btrtl btintel bluetooth kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic irqbypass crc32c_intel arc4 i915 snd_hda_intel snd_hda_codec ath9k ath9k_common ath9k_hw ath i2c_algo_bit snd_hwdep mac80211 ghash_clmulni_intel snd_hda_core snd_pcm snd_timer cfg80211 ehci_pci xhci_pci drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_hcd ehci_hcd asus_nb_wmi(-) asus_wmi sparse_keymap r8169 rfkill mxm_wmi serio_raw snd mii mei_me lpc_ich i2c_i801 video soundcore mei i2c_smbus wmi i2c_core mfd_core CPU: 3 PID: 3275 Comm: modprobe Not tainted 4.9.34-gentoo #34 Hardware name: ASUSTeK COMPUTER INC. K56CM/K56CM, BIOS K56CM.206 08/21/2012 task: ffff8801a639ba00 task.stack: ffffc900014cc000 RIP: 0010:[<ffffffff816c7348>] [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 RSP: 0018:ffffc900014cfce0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8801a54315b0 RCX: 00000000c0000100 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8801a54315b4 RBP: ffffc900014cfd30 R08: 0000000000000000 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801a54315b4 R13: ffff8801a639ba00 R14: 00000000ffffffff R15: ffff8801a54315b8 FS: 00007faa254fb700(0000) GS:ffff8801aef80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001a3b1b000 CR4: 00000000001406e0 Stack: ffff8801a54315b8 0000000000000000 ffffffff814733ae ffffc900014cfd28 ffffffff8146a28c ffff8801a54315b0 0000000000000000 ffff8801a54315b0 ffff8801a66f3820 0000000000000000 ffffc900014cfd48 ffffffff816c73e7 Call Trace: [<ffffffff814733ae>] ? acpi_ut_release_mutex+0x5d/0x61 [<ffffffff8146a28c>] ? acpi_ns_get_node+0x49/0x52 [<ffffffff816c73e7>] mutex_lock+0x17/0x30 [<ffffffffa00a3bb4>] asus_rfkill_hotplug+0x24/0x1a0 [asus_wmi] [<ffffffffa00a4421>] asus_wmi_rfkill_exit+0x61/0x150 [asus_wmi] [<ffffffffa00a49f1>] asus_wmi_remove+0x61/0xb0 [asus_wmi] [<ffffffff814a5128>] platform_drv_remove+0x28/0x40 [<ffffffff814a2901>] __device_release_driver+0xa1/0x160 [<ffffffff814a29e3>] device_release_driver+0x23/0x30 [<ffffffff814a1ffd>] bus_remove_device+0xfd/0x170 [<ffffffff8149e5a9>] device_del+0x139/0x270 [<ffffffff814a5028>] platform_device_del+0x28/0x90 [<ffffffff814a50a2>] platform_device_unregister+0x12/0x30 [<ffffffffa00a4209>] asus_wmi_unregister_driver+0x19/0x30 [asus_wmi] [<ffffffffa00da0ea>] asus_nb_wmi_exit+0x10/0xf26 [asus_nb_wmi] [<ffffffff8110c692>] SyS_delete_module+0x192/0x270 [<ffffffff810022b2>] ? exit_to_usermode_loop+0x92/0xa0 [<ffffffff816ca560>] entry_SYSCALL_64_fastpath+0x13/0x94 Code: e8 5e 30 00 00 8b 03 83 f8 01 0f 84 93 00 00 00 48 8b 43 10 4c 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> 89 20 4c 89 6c 24 10 eb 1d 4c 89 e7 49 c7 45 08 02 00 00 00 RIP [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 RSP <ffffc900014cfce0> CR2: 0000000000000000 ---[ end trace 8d484233fa7cb512 ]--- note: modprobe[3275] exited with preempt_count 2 https://bugzilla.kernel.org/show_bug.cgi?id=196467 Reported-by: red.f0xyz@gmail.com Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2018-05-22 15:30:15 -06:00
if (asus->driver->wlan_ctrl_by_user && ashs_present())
return;
asus_unregister_rfkill_notifier(asus, "\\_SB.PCI0.P0P5");
asus_unregister_rfkill_notifier(asus, "\\_SB.PCI0.P0P6");
asus_unregister_rfkill_notifier(asus, "\\_SB.PCI0.P0P7");
if (asus->wlan.rfkill) {
rfkill_unregister(asus->wlan.rfkill);
rfkill_destroy(asus->wlan.rfkill);
asus->wlan.rfkill = NULL;
}
/*
* Refresh pci hotplug in case the rfkill state was changed after
* asus_unregister_rfkill_notifier()
*/
asus_rfkill_hotplug(asus);
PCI: hotplug: Embed hotplug_slot When the PCI hotplug core and its first user, cpqphp, were introduced in February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot struct for its internal use plus a hotplug_slot struct to be registered with the hotplug core and linked the two with pointers: https://git.kernel.org/tglx/history/c/a8a2069f432c Nowadays, the predominant pattern in the tree is to embed ("subclass") such structures in one another and cast to the containing struct with container_of(). But it wasn't until July 2002 that container_of() was introduced with historic commit ec4f214232cf: https://git.kernel.org/tglx/history/c/ec4f214232cf pnv_php, introduced in 2016, did the right thing and embedded struct hotplug_slot in its internal struct pnv_php_slot, but all other drivers cargo-culted cpqphp's design and linked separate structs with pointers. Embedding structs is preferrable to linking them with pointers because it requires fewer allocations, thereby reducing overhead and simplifying error paths. Casting an embedded struct to the containing struct becomes a cheap subtraction rather than a dereference. And having fewer pointers reduces the risk of them pointing nowhere either accidentally or due to an attack. Convert all drivers to embed struct hotplug_slot in their internal slot struct. The "private" pointer in struct hotplug_slot thereby becomes unused, so drop it. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Sebastian Ott <sebott@linux.ibm.com> # drivers/pci/hotplug/s390* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
2018-09-08 01:59:01 -06:00
if (asus->hotplug_slot.ops)
pci_hp_deregister(&asus->hotplug_slot);
if (asus->hotplug_workqueue)
destroy_workqueue(asus->hotplug_workqueue);
if (asus->bluetooth.rfkill) {
rfkill_unregister(asus->bluetooth.rfkill);
rfkill_destroy(asus->bluetooth.rfkill);
asus->bluetooth.rfkill = NULL;
}
if (asus->wimax.rfkill) {
rfkill_unregister(asus->wimax.rfkill);
rfkill_destroy(asus->wimax.rfkill);
asus->wimax.rfkill = NULL;
}
if (asus->wwan3g.rfkill) {
rfkill_unregister(asus->wwan3g.rfkill);
rfkill_destroy(asus->wwan3g.rfkill);
asus->wwan3g.rfkill = NULL;
}
if (asus->gps.rfkill) {
rfkill_unregister(asus->gps.rfkill);
rfkill_destroy(asus->gps.rfkill);
asus->gps.rfkill = NULL;
}
if (asus->uwb.rfkill) {
rfkill_unregister(asus->uwb.rfkill);
rfkill_destroy(asus->uwb.rfkill);
asus->uwb.rfkill = NULL;
}
}
static int asus_wmi_rfkill_init(struct asus_wmi *asus)
{
int result = 0;
mutex_init(&asus->hotplug_lock);
mutex_init(&asus->wmi_lock);
result = asus_new_rfkill(asus, &asus->wlan, "asus-wlan",
RFKILL_TYPE_WLAN, ASUS_WMI_DEVID_WLAN);
if (result && result != -ENODEV)
goto exit;
result = asus_new_rfkill(asus, &asus->bluetooth,
"asus-bluetooth", RFKILL_TYPE_BLUETOOTH,
ASUS_WMI_DEVID_BLUETOOTH);
if (result && result != -ENODEV)
goto exit;
result = asus_new_rfkill(asus, &asus->wimax, "asus-wimax",
RFKILL_TYPE_WIMAX, ASUS_WMI_DEVID_WIMAX);
if (result && result != -ENODEV)
goto exit;
result = asus_new_rfkill(asus, &asus->wwan3g, "asus-wwan3g",
RFKILL_TYPE_WWAN, ASUS_WMI_DEVID_WWAN3G);
if (result && result != -ENODEV)
goto exit;
result = asus_new_rfkill(asus, &asus->gps, "asus-gps",
RFKILL_TYPE_GPS, ASUS_WMI_DEVID_GPS);
if (result && result != -ENODEV)
goto exit;
result = asus_new_rfkill(asus, &asus->uwb, "asus-uwb",
RFKILL_TYPE_UWB, ASUS_WMI_DEVID_UWB);
if (result && result != -ENODEV)
goto exit;
if (!asus->driver->quirks->hotplug_wireless)
goto exit;
result = asus_setup_pci_hotplug(asus);
/*
* If we get -EBUSY then something else is handling the PCI hotplug -
* don't fail in this case
*/
if (result == -EBUSY)
result = 0;
asus_register_rfkill_notifier(asus, "\\_SB.PCI0.P0P5");
asus_register_rfkill_notifier(asus, "\\_SB.PCI0.P0P6");
asus_register_rfkill_notifier(asus, "\\_SB.PCI0.P0P7");
/*
* Refresh pci hotplug in case the rfkill state was changed during
* setup.
*/
asus_rfkill_hotplug(asus);
exit:
if (result && result != -ENODEV)
asus_wmi_rfkill_exit(asus);
if (result == -ENODEV)
result = 0;
return result;
}
/* Quirks *********************************************************************/
platform/x86: asus-wmi: Set specified XUSB2PR value for X550LB The bluetooth adapter Atheros AR3012 can't be enumerated and make the bluetooth function broken. T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3362 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb The error is: usb 2-6: device not accepting address 7, error -62 usb usb2-port6: unable to enumerate USB device It is caused by adapter's connected port is mapped to xHC controller, but the xHCI is not supported by the usb device. The output of 'sudo lspci -nnxxx -s 00:14.0': 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) 00: 86 80 31 9c 06 04 90 02 04 30 03 0c 00 00 00 00 10: 04 00 a0 f7 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 1f 20 30: 00 00 00 00 70 00 00 00 00 00 00 00 0b 01 00 00 40: fd 01 36 80 89 c6 0f 80 00 00 00 00 00 00 00 00 50: 5f 2e ce 0f 00 00 00 00 00 00 00 00 00 00 00 00 60: 30 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 01 80 c2 c1 08 00 00 00 00 00 00 00 00 00 00 00 80: 05 00 87 00 0c a0 e0 fe 00 00 00 00 a1 41 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 0f 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 03 c0 30 00 00 00 00 00 03 0c 00 00 00 00 00 00 d0: f9 01 00 00 f9 01 00 00 0f 00 00 00 0f 00 00 00 e0: 00 08 00 00 00 00 00 00 00 00 00 00 d8 d8 00 00 f0: 00 00 00 00 00 00 00 00 b1 0f 04 08 00 00 00 00 By referencing Intel Platform Controller Hub(PCH) datasheet, the xHC USB 2.0 Port Routing(XUSB2PR) at offset 0xD0-0xD3h decides the setting of mapping the port to EHCI controller or xHC controller. And the port mapped to xHC will enable xHCI during bus resume. The setting of disabling bluetooth adapter's connected port is 0x000001D9. The value can be obtained by few times 1 bit flip operation. The suited configuration should have the 'lsusb -t' result with bluetooth using ehci: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 6: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 6: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M Signed-off-by: Kai-Chuan Hsieh <kai.chiuan@gmail.com> Acked-by: Corentin Chary <corentin.chary@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> [andy: resolve merge conflict in asus-wmi.h] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-09-01 09:55:55 -06:00
static void asus_wmi_set_xusb2pr(struct asus_wmi *asus)
{
struct pci_dev *xhci_pdev;
u32 orig_ports_available;
u32 ports_available = asus->driver->quirks->xusb2pr;
xhci_pdev = pci_get_device(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI,
NULL);
if (!xhci_pdev)
return;
pci_read_config_dword(xhci_pdev, USB_INTEL_XUSB2PR,
&orig_ports_available);
pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR,
cpu_to_le32(ports_available));
pr_info("set USB_INTEL_XUSB2PR old: 0x%04x, new: 0x%04x\n",
orig_ports_available, ports_available);
}
/*
* Some devices dont support or have borcken get_als method
* but still support set method.
*/
static void asus_wmi_set_als(void)
{
asus_wmi_set_devstate(ASUS_WMI_DEVID_ALS_ENABLE, 1, NULL);
}
/* Hwmon device ***************************************************************/
static int asus_agfn_fan_speed_read(struct asus_wmi *asus, int fan,
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
int *speed)
{
struct agfn_fan_args args = {
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
.agfn.len = sizeof(args),
.agfn.mfun = ASUS_FAN_MFUN,
.agfn.sfun = ASUS_FAN_SFUN_READ,
.fan = fan,
.speed = 0,
};
struct acpi_buffer input = { (acpi_size) sizeof(args), &args };
int status;
if (fan != 1)
return -EINVAL;
status = asus_wmi_evaluate_method_agfn(input);
if (status || args.agfn.err)
return -ENXIO;
if (speed)
*speed = args.speed;
return 0;
}
static int asus_agfn_fan_speed_write(struct asus_wmi *asus, int fan,
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
int *speed)
{
struct agfn_fan_args args = {
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
.agfn.len = sizeof(args),
.agfn.mfun = ASUS_FAN_MFUN,
.agfn.sfun = ASUS_FAN_SFUN_WRITE,
.fan = fan,
.speed = speed ? *speed : 0,
};
struct acpi_buffer input = { (acpi_size) sizeof(args), &args };
int status;
/* 1: for setting 1st fan's speed 0: setting auto mode */
if (fan != 1 && fan != 0)
return -EINVAL;
status = asus_wmi_evaluate_method_agfn(input);
if (status || args.agfn.err)
return -ENXIO;
if (speed && fan == 1)
asus->agfn_pwm = *speed;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
return 0;
}
/*
* Check if we can read the speed of one fan. If true we assume we can also
* control it.
*/
static bool asus_wmi_has_agfn_fan(struct asus_wmi *asus)
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
{
int status;
int speed;
u32 value;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
status = asus_agfn_fan_speed_read(asus, 1, &speed);
if (status != 0)
return false;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
status = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_FAN_CTRL, &value);
if (status != 0)
return false;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
/*
* We need to find a better way, probably using sfun,
* bits or spec ...
* Currently we disable it if:
* - ASUS_WMI_UNSUPPORTED_METHOD is returned
* - reverved bits are non-zero
* - sfun and presence bit are not set
*/
return !(value == ASUS_WMI_UNSUPPORTED_METHOD || value & 0xFFF80000
|| (!asus->sfun && !(value & ASUS_WMI_DSTS_PRESENCE_BIT)));
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
}
static int asus_fan_set_auto(struct asus_wmi *asus)
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
{
int status;
u32 retval;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
switch (asus->fan_type) {
case FAN_TYPE_SPEC83:
status = asus_wmi_set_devstate(ASUS_WMI_DEVID_CPU_FAN_CTRL,
0, &retval);
if (status)
return status;
if (retval != 1)
return -EIO;
break;
case FAN_TYPE_AGFN:
status = asus_agfn_fan_speed_write(asus, 0, NULL);
if (status)
return -ENXIO;
break;
default:
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
return -ENXIO;
}
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
return 0;
}
static ssize_t pwm1_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
struct asus_wmi *asus = dev_get_drvdata(dev);
int err;
int value;
/* If we already set a value then just return it */
if (asus->agfn_pwm >= 0)
return sprintf(buf, "%d\n", asus->agfn_pwm);
/*
* If we haven't set already set a value through the AGFN interface,
* we read a current value through the (now-deprecated) FAN_CTRL device.
*/
err = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_FAN_CTRL, &value);
if (err < 0)
return err;
value &= 0xFF;
if (value == 1) /* Low Speed */
value = 85;
else if (value == 2)
value = 170;
else if (value == 3)
value = 255;
else if (value) {
pr_err("Unknown fan speed %#x\n", value);
value = -1;
}
return sprintf(buf, "%d\n", value);
}
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
static ssize_t pwm1_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count) {
struct asus_wmi *asus = dev_get_drvdata(dev);
int value;
int state;
int ret;
ret = kstrtouint(buf, 10, &value);
if (ret)
return ret;
value = clamp(value, 0, 255);
state = asus_agfn_fan_speed_write(asus, 1, &value);
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
if (state)
pr_warn("Setting fan speed failed: %d\n", state);
else
asus->fan_pwm_mode = ASUS_FAN_CTRL_MANUAL;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
return count;
}
static ssize_t fan1_input_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
struct asus_wmi *asus = dev_get_drvdata(dev);
int value;
int ret;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
switch (asus->fan_type) {
case FAN_TYPE_SPEC83:
ret = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_CPU_FAN_CTRL,
&value);
if (ret < 0)
return ret;
value &= 0xffff;
break;
case FAN_TYPE_AGFN:
/* no speed readable on manual mode */
if (asus->fan_pwm_mode == ASUS_FAN_CTRL_MANUAL)
return -ENXIO;
ret = asus_agfn_fan_speed_read(asus, 1, &value);
if (ret) {
pr_warn("reading fan speed failed: %d\n", ret);
return -ENXIO;
}
break;
default:
return -ENXIO;
}
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
return sprintf(buf, "%d\n", value < 0 ? -1 : value*100);
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
}
static ssize_t pwm1_enable_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
struct asus_wmi *asus = dev_get_drvdata(dev);
/*
* Just read back the cached pwm mode.
*
* For the CPU_FAN device, the spec indicates that we should be
* able to read the device status and consult bit 19 to see if we
* are in Full On or Automatic mode. However, this does not work
* in practice on X532FL at least (the bit is always 0) and there's
* also nothing in the DSDT to indicate that this behaviour exists.
*/
return sprintf(buf, "%d\n", asus->fan_pwm_mode);
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
}
static ssize_t pwm1_enable_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
struct asus_wmi *asus = dev_get_drvdata(dev);
int status = 0;
int state;
int value;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
int ret;
u32 retval;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
ret = kstrtouint(buf, 10, &state);
if (ret)
return ret;
if (asus->fan_type == FAN_TYPE_SPEC83) {
switch (state) { /* standard documented hwmon values */
case ASUS_FAN_CTRL_FULLSPEED:
value = 1;
break;
case ASUS_FAN_CTRL_AUTO:
value = 0;
break;
default:
return -EINVAL;
}
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
ret = asus_wmi_set_devstate(ASUS_WMI_DEVID_CPU_FAN_CTRL,
value, &retval);
if (ret)
return ret;
if (retval != 1)
return -EIO;
} else if (asus->fan_type == FAN_TYPE_AGFN) {
switch (state) {
case ASUS_FAN_CTRL_MANUAL:
break;
case ASUS_FAN_CTRL_AUTO:
status = asus_fan_set_auto(asus);
if (status)
return status;
break;
default:
return -EINVAL;
}
}
asus->fan_pwm_mode = state;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
return count;
}
static ssize_t fan1_label_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
return sprintf(buf, "%s\n", ASUS_FAN_DESC);
}
static ssize_t asus_hwmon_temp1(struct device *dev,
struct device_attribute *attr,
char *buf)
{
struct asus_wmi *asus = dev_get_drvdata(dev);
u32 value;
int err;
err = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_THERMAL_CTRL, &value);
if (err < 0)
return err;
value = DECI_KELVIN_TO_CELSIUS((value & 0xFFFF)) * 1000;
return sprintf(buf, "%d\n", value);
}
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
/* Fan1 */
static DEVICE_ATTR_RW(pwm1);
static DEVICE_ATTR_RW(pwm1_enable);
static DEVICE_ATTR_RO(fan1_input);
static DEVICE_ATTR_RO(fan1_label);
/* Temperature */
static DEVICE_ATTR(temp1_input, S_IRUGO, asus_hwmon_temp1, NULL);
static struct attribute *hwmon_attributes[] = {
&dev_attr_pwm1.attr,
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
&dev_attr_pwm1_enable.attr,
&dev_attr_fan1_input.attr,
&dev_attr_fan1_label.attr,
&dev_attr_temp1_input.attr,
NULL
};
static umode_t asus_hwmon_sysfs_is_visible(struct kobject *kobj,
struct attribute *attr, int idx)
{
struct device *dev = container_of(kobj, struct device, kobj);
struct asus_wmi *asus = dev_get_drvdata(dev->parent);
u32 value = ASUS_WMI_UNSUPPORTED_METHOD;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
if (attr == &dev_attr_pwm1.attr) {
if (asus->fan_type != FAN_TYPE_AGFN)
return 0;
} else if (attr == &dev_attr_fan1_input.attr
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
|| attr == &dev_attr_fan1_label.attr
|| attr == &dev_attr_pwm1_enable.attr) {
if (asus->fan_type == FAN_TYPE_NONE)
return 0;
} else if (attr == &dev_attr_temp1_input.attr) {
int err = asus_wmi_get_devstate(asus,
ASUS_WMI_DEVID_THERMAL_CTRL,
&value);
if (err < 0)
return 0; /* can't return negative here */
/*
* If the temperature value in deci-Kelvin is near the absolute
* zero temperature, something is clearly wrong
*/
if (value == 0 || value == 1)
return 0;
}
return attr->mode;
}
static const struct attribute_group hwmon_attribute_group = {
.is_visible = asus_hwmon_sysfs_is_visible,
.attrs = hwmon_attributes
};
__ATTRIBUTE_GROUPS(hwmon_attribute);
static int asus_wmi_hwmon_init(struct asus_wmi *asus)
{
struct device *dev = &asus->platform_device->dev;
struct device *hwmon;
hwmon = devm_hwmon_device_register_with_groups(dev, "asus", asus,
hwmon_attribute_groups);
if (IS_ERR(hwmon)) {
pr_err("Could not register asus hwmon device\n");
return PTR_ERR(hwmon);
}
return 0;
}
static int asus_wmi_fan_init(struct asus_wmi *asus)
{
asus->fan_type = FAN_TYPE_NONE;
asus->agfn_pwm = -1;
if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_CPU_FAN_CTRL))
asus->fan_type = FAN_TYPE_SPEC83;
else if (asus_wmi_has_agfn_fan(asus))
asus->fan_type = FAN_TYPE_AGFN;
if (asus->fan_type == FAN_TYPE_NONE)
return -ENODEV;
asus_fan_set_auto(asus);
asus->fan_pwm_mode = ASUS_FAN_CTRL_AUTO;
return 0;
}
/* Fan mode *******************************************************************/
static int fan_boost_mode_check_present(struct asus_wmi *asus)
{
u32 result;
int err;
asus->fan_boost_mode_available = false;
err = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_FAN_BOOST_MODE,
&result);
if (err) {
if (err == -ENODEV)
return 0;
else
return err;
}
if ((result & ASUS_WMI_DSTS_PRESENCE_BIT) &&
(result & ASUS_FAN_BOOST_MODES_MASK)) {
asus->fan_boost_mode_available = true;
asus->fan_boost_mode_mask = result & ASUS_FAN_BOOST_MODES_MASK;
}
return 0;
}
static int fan_boost_mode_write(struct asus_wmi *asus)
{
int err;
u8 value;
u32 retval;
value = asus->fan_boost_mode;
pr_info("Set fan boost mode: %u\n", value);
err = asus_wmi_set_devstate(ASUS_WMI_DEVID_FAN_BOOST_MODE, value,
&retval);
if (err) {
pr_warn("Failed to set fan boost mode: %d\n", err);
return err;
}
if (retval != 1) {
pr_warn("Failed to set fan boost mode (retval): 0x%x\n",
retval);
return -EIO;
}
return 0;
}
static int fan_boost_mode_switch_next(struct asus_wmi *asus)
{
u8 mask = asus->fan_boost_mode_mask;
if (asus->fan_boost_mode == ASUS_FAN_BOOST_MODE_NORMAL) {
if (mask & ASUS_FAN_BOOST_MODE_OVERBOOST_MASK)
asus->fan_boost_mode = ASUS_FAN_BOOST_MODE_OVERBOOST;
else if (mask & ASUS_FAN_BOOST_MODE_SILENT_MASK)
asus->fan_boost_mode = ASUS_FAN_BOOST_MODE_SILENT;
} else if (asus->fan_boost_mode == ASUS_FAN_BOOST_MODE_OVERBOOST) {
if (mask & ASUS_FAN_BOOST_MODE_SILENT_MASK)
asus->fan_boost_mode = ASUS_FAN_BOOST_MODE_SILENT;
else
asus->fan_boost_mode = ASUS_FAN_BOOST_MODE_NORMAL;
} else {
asus->fan_boost_mode = ASUS_FAN_BOOST_MODE_NORMAL;
}
return fan_boost_mode_write(asus);
}
static ssize_t fan_boost_mode_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct asus_wmi *asus = dev_get_drvdata(dev);
return scnprintf(buf, PAGE_SIZE, "%d\n", asus->fan_boost_mode);
}
static ssize_t fan_boost_mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
int result;
u8 new_mode;
struct asus_wmi *asus = dev_get_drvdata(dev);
u8 mask = asus->fan_boost_mode_mask;
result = kstrtou8(buf, 10, &new_mode);
if (result < 0) {
pr_warn("Trying to store invalid value\n");
return result;
}
if (new_mode == ASUS_FAN_BOOST_MODE_OVERBOOST) {
if (!(mask & ASUS_FAN_BOOST_MODE_OVERBOOST_MASK))
return -EINVAL;
} else if (new_mode == ASUS_FAN_BOOST_MODE_SILENT) {
if (!(mask & ASUS_FAN_BOOST_MODE_SILENT_MASK))
return -EINVAL;
} else if (new_mode != ASUS_FAN_BOOST_MODE_NORMAL) {
return -EINVAL;
}
asus->fan_boost_mode = new_mode;
fan_boost_mode_write(asus);
return result;
}
// Fan boost mode: 0 - normal, 1 - overboost, 2 - silent
static DEVICE_ATTR_RW(fan_boost_mode);
/* Backlight ******************************************************************/
static int read_backlight_power(struct asus_wmi *asus)
{
int ret;
if (asus->driver->quirks->store_backlight_power)
ret = !asus->driver->panel_power;
else
ret = asus_wmi_get_devstate_simple(asus,
ASUS_WMI_DEVID_BACKLIGHT);
if (ret < 0)
return ret;
return ret ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
}
static int read_brightness_max(struct asus_wmi *asus)
{
u32 retval;
int err;
err = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_BRIGHTNESS, &retval);
if (err < 0)
return err;
retval = retval & ASUS_WMI_DSTS_MAX_BRIGTH_MASK;
retval >>= 8;
if (!retval)
return -ENODEV;
return retval;
}
static int read_brightness(struct backlight_device *bd)
{
struct asus_wmi *asus = bl_get_data(bd);
u32 retval;
int err;
err = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_BRIGHTNESS, &retval);
if (err < 0)
return err;
return retval & ASUS_WMI_DSTS_BRIGHTNESS_MASK;
}
static u32 get_scalar_command(struct backlight_device *bd)
{
struct asus_wmi *asus = bl_get_data(bd);
u32 ctrl_param = 0;
if ((asus->driver->brightness < bd->props.brightness) ||
bd->props.brightness == bd->props.max_brightness)
ctrl_param = 0x00008001;
else if ((asus->driver->brightness > bd->props.brightness) ||
bd->props.brightness == 0)
ctrl_param = 0x00008000;
asus->driver->brightness = bd->props.brightness;
return ctrl_param;
}
static int update_bl_status(struct backlight_device *bd)
{
struct asus_wmi *asus = bl_get_data(bd);
u32 ctrl_param;
int power, err = 0;
power = read_backlight_power(asus);
if (power != -ENODEV && bd->props.power != power) {
ctrl_param = !!(bd->props.power == FB_BLANK_UNBLANK);
err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT,
ctrl_param, NULL);
if (asus->driver->quirks->store_backlight_power)
asus->driver->panel_power = bd->props.power;
/* When using scalar brightness, updating the brightness
* will mess with the backlight power */
if (asus->driver->quirks->scalar_panel_brightness)
return err;
}
if (asus->driver->quirks->scalar_panel_brightness)
ctrl_param = get_scalar_command(bd);
else
ctrl_param = bd->props.brightness;
err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BRIGHTNESS,
ctrl_param, NULL);
return err;
}
static const struct backlight_ops asus_wmi_bl_ops = {
.get_brightness = read_brightness,
.update_status = update_bl_status,
};
static int asus_wmi_backlight_notify(struct asus_wmi *asus, int code)
{
struct backlight_device *bd = asus->backlight_device;
int old = bd->props.brightness;
int new = old;
if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
new = code - NOTIFY_BRNUP_MIN + 1;
else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
new = code - NOTIFY_BRNDOWN_MIN;
bd->props.brightness = new;
backlight_update_status(bd);
backlight_force_update(bd, BACKLIGHT_UPDATE_HOTKEY);
return old;
}
static int asus_wmi_backlight_init(struct asus_wmi *asus)
{
struct backlight_device *bd;
struct backlight_properties props;
int max;
int power;
max = read_brightness_max(asus);
if (max < 0)
return max;
power = read_backlight_power(asus);
if (power == -ENODEV)
power = FB_BLANK_UNBLANK;
else if (power < 0)
return power;
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = max;
bd = backlight_device_register(asus->driver->name,
&asus->platform_device->dev, asus,
&asus_wmi_bl_ops, &props);
if (IS_ERR(bd)) {
pr_err("Could not register backlight device\n");
return PTR_ERR(bd);
}
asus->backlight_device = bd;
if (asus->driver->quirks->store_backlight_power)
asus->driver->panel_power = power;
bd->props.brightness = read_brightness(bd);
bd->props.power = power;
backlight_update_status(bd);
asus->driver->brightness = bd->props.brightness;
return 0;
}
static void asus_wmi_backlight_exit(struct asus_wmi *asus)
{
backlight_device_unregister(asus->backlight_device);
asus->backlight_device = NULL;
}
static int is_display_toggle(int code)
{
/* display toggle keys */
if ((code >= 0x61 && code <= 0x67) ||
(code >= 0x8c && code <= 0x93) ||
(code >= 0xa0 && code <= 0xa7) ||
(code >= 0xd0 && code <= 0xd5))
return 1;
return 0;
}
/* Fn-lock ********************************************************************/
static bool asus_wmi_has_fnlock_key(struct asus_wmi *asus)
{
u32 result;
asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_FNLOCK, &result);
return (result & ASUS_WMI_DSTS_PRESENCE_BIT) &&
!(result & ASUS_WMI_FNLOCK_BIOS_DISABLED);
}
static void asus_wmi_fnlock_update(struct asus_wmi *asus)
{
int mode = asus->fnlock_locked;
asus_wmi_set_devstate(ASUS_WMI_DEVID_FNLOCK, mode, NULL);
}
/* WMI events *****************************************************************/
static int asus_wmi_get_event_code(u32 value)
{
struct acpi_buffer response = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
acpi_status status;
int code;
status = wmi_get_event_data(value, &response);
if (ACPI_FAILURE(status)) {
pr_warn("Failed to get WMI notify code: %s\n",
acpi_format_exception(status));
return -EIO;
}
obj = (union acpi_object *)response.pointer;
if (obj && obj->type == ACPI_TYPE_INTEGER)
code = (int)(obj->integer.value & WMI_EVENT_MASK);
else
code = -EIO;
kfree(obj);
return code;
}
static void asus_wmi_handle_event_code(int code, struct asus_wmi *asus)
{
int orig_code;
unsigned int key_value = 1;
bool autorelease = 1;
orig_code = code;
if (asus->driver->key_filter) {
asus->driver->key_filter(asus->driver, &code, &key_value,
&autorelease);
if (code == ASUS_WMI_KEY_IGNORE)
return;
}
if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
code = ASUS_WMI_BRN_UP;
else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
code = ASUS_WMI_BRN_DOWN;
if (code == ASUS_WMI_BRN_DOWN || code == ASUS_WMI_BRN_UP) {
if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
asus_wmi_backlight_notify(asus, orig_code);
return;
}
}
if (code == NOTIFY_KBD_BRTUP) {
kbd_led_set_by_kbd(asus, asus->kbd_led_wk + 1);
return;
}
if (code == NOTIFY_KBD_BRTDWN) {
kbd_led_set_by_kbd(asus, asus->kbd_led_wk - 1);
return;
}
if (code == NOTIFY_KBD_BRTTOGGLE) {
if (asus->kbd_led_wk == asus->kbd_led.max_brightness)
kbd_led_set_by_kbd(asus, 0);
else
kbd_led_set_by_kbd(asus, asus->kbd_led_wk + 1);
return;
}
if (code == NOTIFY_FNLOCK_TOGGLE) {
asus->fnlock_locked = !asus->fnlock_locked;
asus_wmi_fnlock_update(asus);
return;
}
if (asus->fan_boost_mode_available && code == NOTIFY_KBD_FBM) {
fan_boost_mode_switch_next(asus);
return;
}
if (is_display_toggle(code) && asus->driver->quirks->no_display_toggle)
return;
if (!sparse_keymap_report_event(asus->inputdev, code,
key_value, autorelease))
pr_info("Unknown key %x pressed\n", code);
}
static void asus_wmi_notify(u32 value, void *context)
{
struct asus_wmi *asus = context;
platform/x86: asus-wmi: Support WMI event queue Event codes are expected to be retrieved from a queue on at least some models. Specifically, very likely the ACPI WMI devices with _UID ATK are queued whereas those with ASUSWMI are not [1]. The WMI event codes are pushed into a circular buffer queue. After the INIT method is called, ACPI code is allowed to push events into this buffer. The INIT method cannot be reverted. If the module is unloaded and an event (such as hotkey press) gets emitted before inserting it back the events get processed delayed by one or if the queue overflows, additionally delayed by about 3 seconds. It might be considered a minor issue and no normal user would likely observe this (there is little reason unloading the driver), but it does significantly frustrate a developer who is unlucky enough to encounter this. Therefore, the fallback to unqueued behavior occurs whenever something unexpected happens. The fix flushes the old key codes out of the queue on load. After receiving event the queue is read until either ..FFFF or 1 is encountered. Also as noted in [1] it is checked whether notify code is equal to 0xFF before enabling queue processing in WMI notify handler. DSDT examples: FX505GM Device (ATKD) { .. Name (ATKQ, Package (0x10) { 0xFFFFFFFF, .. } Method (IANQ, 1, Serialized) { If ((AQNO >= 0x10)) { Local0 = 0x64 While ((Local0 && (AQNO >= 0x10))) { Local0-- Sleep (0x0A) } ... .. AQTI++ AQTI &= 0x0F ATKQ [AQTI] = Arg0 ... } Method (GANQ, 0, Serialized) { .. If (AQNO) { ... Local0 = DerefOf (ATKQ [AQHI]) AQHI++ AQHI &= 0x0F Return (Local0) } Return (One) } This code is almost identical to K54C, which does return Ones on empty queue. K54C: Method (GANQ, 0, Serialized) { If (AQNO) { ... Return (Local0) } Return (Ones) } [1] Link: https://lkml.org/lkml/2019/4/12/104 Signed-off-by: Yurii Pavlovskyi <yurii.pavlovskyi@gmail.com> Suggested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-05-14 13:02:09 -06:00
int code;
int i;
platform/x86: asus-wmi: Support WMI event queue Event codes are expected to be retrieved from a queue on at least some models. Specifically, very likely the ACPI WMI devices with _UID ATK are queued whereas those with ASUSWMI are not [1]. The WMI event codes are pushed into a circular buffer queue. After the INIT method is called, ACPI code is allowed to push events into this buffer. The INIT method cannot be reverted. If the module is unloaded and an event (such as hotkey press) gets emitted before inserting it back the events get processed delayed by one or if the queue overflows, additionally delayed by about 3 seconds. It might be considered a minor issue and no normal user would likely observe this (there is little reason unloading the driver), but it does significantly frustrate a developer who is unlucky enough to encounter this. Therefore, the fallback to unqueued behavior occurs whenever something unexpected happens. The fix flushes the old key codes out of the queue on load. After receiving event the queue is read until either ..FFFF or 1 is encountered. Also as noted in [1] it is checked whether notify code is equal to 0xFF before enabling queue processing in WMI notify handler. DSDT examples: FX505GM Device (ATKD) { .. Name (ATKQ, Package (0x10) { 0xFFFFFFFF, .. } Method (IANQ, 1, Serialized) { If ((AQNO >= 0x10)) { Local0 = 0x64 While ((Local0 && (AQNO >= 0x10))) { Local0-- Sleep (0x0A) } ... .. AQTI++ AQTI &= 0x0F ATKQ [AQTI] = Arg0 ... } Method (GANQ, 0, Serialized) { .. If (AQNO) { ... Local0 = DerefOf (ATKQ [AQHI]) AQHI++ AQHI &= 0x0F Return (Local0) } Return (One) } This code is almost identical to K54C, which does return Ones on empty queue. K54C: Method (GANQ, 0, Serialized) { If (AQNO) { ... Return (Local0) } Return (Ones) } [1] Link: https://lkml.org/lkml/2019/4/12/104 Signed-off-by: Yurii Pavlovskyi <yurii.pavlovskyi@gmail.com> Suggested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-05-14 13:02:09 -06:00
for (i = 0; i < WMI_EVENT_QUEUE_SIZE + 1; i++) {
code = asus_wmi_get_event_code(value);
if (code < 0) {
pr_warn("Failed to get notify code: %d\n", code);
return;
}
if (code == WMI_EVENT_QUEUE_END || code == WMI_EVENT_MASK)
return;
asus_wmi_handle_event_code(code, asus);
/*
* Double check that queue is present:
* ATK (with queue) uses 0xff, ASUSWMI (without) 0xd2.
*/
if (!asus->wmi_event_queue || value != WMI_EVENT_VALUE_ATK)
return;
}
platform/x86: asus-wmi: Support WMI event queue Event codes are expected to be retrieved from a queue on at least some models. Specifically, very likely the ACPI WMI devices with _UID ATK are queued whereas those with ASUSWMI are not [1]. The WMI event codes are pushed into a circular buffer queue. After the INIT method is called, ACPI code is allowed to push events into this buffer. The INIT method cannot be reverted. If the module is unloaded and an event (such as hotkey press) gets emitted before inserting it back the events get processed delayed by one or if the queue overflows, additionally delayed by about 3 seconds. It might be considered a minor issue and no normal user would likely observe this (there is little reason unloading the driver), but it does significantly frustrate a developer who is unlucky enough to encounter this. Therefore, the fallback to unqueued behavior occurs whenever something unexpected happens. The fix flushes the old key codes out of the queue on load. After receiving event the queue is read until either ..FFFF or 1 is encountered. Also as noted in [1] it is checked whether notify code is equal to 0xFF before enabling queue processing in WMI notify handler. DSDT examples: FX505GM Device (ATKD) { .. Name (ATKQ, Package (0x10) { 0xFFFFFFFF, .. } Method (IANQ, 1, Serialized) { If ((AQNO >= 0x10)) { Local0 = 0x64 While ((Local0 && (AQNO >= 0x10))) { Local0-- Sleep (0x0A) } ... .. AQTI++ AQTI &= 0x0F ATKQ [AQTI] = Arg0 ... } Method (GANQ, 0, Serialized) { .. If (AQNO) { ... Local0 = DerefOf (ATKQ [AQHI]) AQHI++ AQHI &= 0x0F Return (Local0) } Return (One) } This code is almost identical to K54C, which does return Ones on empty queue. K54C: Method (GANQ, 0, Serialized) { If (AQNO) { ... Return (Local0) } Return (Ones) } [1] Link: https://lkml.org/lkml/2019/4/12/104 Signed-off-by: Yurii Pavlovskyi <yurii.pavlovskyi@gmail.com> Suggested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-05-14 13:02:09 -06:00
pr_warn("Failed to process event queue, last code: 0x%x\n", code);
}
platform/x86: asus-wmi: Support WMI event queue Event codes are expected to be retrieved from a queue on at least some models. Specifically, very likely the ACPI WMI devices with _UID ATK are queued whereas those with ASUSWMI are not [1]. The WMI event codes are pushed into a circular buffer queue. After the INIT method is called, ACPI code is allowed to push events into this buffer. The INIT method cannot be reverted. If the module is unloaded and an event (such as hotkey press) gets emitted before inserting it back the events get processed delayed by one or if the queue overflows, additionally delayed by about 3 seconds. It might be considered a minor issue and no normal user would likely observe this (there is little reason unloading the driver), but it does significantly frustrate a developer who is unlucky enough to encounter this. Therefore, the fallback to unqueued behavior occurs whenever something unexpected happens. The fix flushes the old key codes out of the queue on load. After receiving event the queue is read until either ..FFFF or 1 is encountered. Also as noted in [1] it is checked whether notify code is equal to 0xFF before enabling queue processing in WMI notify handler. DSDT examples: FX505GM Device (ATKD) { .. Name (ATKQ, Package (0x10) { 0xFFFFFFFF, .. } Method (IANQ, 1, Serialized) { If ((AQNO >= 0x10)) { Local0 = 0x64 While ((Local0 && (AQNO >= 0x10))) { Local0-- Sleep (0x0A) } ... .. AQTI++ AQTI &= 0x0F ATKQ [AQTI] = Arg0 ... } Method (GANQ, 0, Serialized) { .. If (AQNO) { ... Local0 = DerefOf (ATKQ [AQHI]) AQHI++ AQHI &= 0x0F Return (Local0) } Return (One) } This code is almost identical to K54C, which does return Ones on empty queue. K54C: Method (GANQ, 0, Serialized) { If (AQNO) { ... Return (Local0) } Return (Ones) } [1] Link: https://lkml.org/lkml/2019/4/12/104 Signed-off-by: Yurii Pavlovskyi <yurii.pavlovskyi@gmail.com> Suggested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-05-14 13:02:09 -06:00
static int asus_wmi_notify_queue_flush(struct asus_wmi *asus)
{
int code;
int i;
for (i = 0; i < WMI_EVENT_QUEUE_SIZE + 1; i++) {
code = asus_wmi_get_event_code(WMI_EVENT_VALUE_ATK);
if (code < 0) {
pr_warn("Failed to get event during flush: %d\n", code);
return code;
}
if (code == WMI_EVENT_QUEUE_END || code == WMI_EVENT_MASK)
return 0;
}
pr_warn("Failed to flush event queue\n");
return -EIO;
}
/* Sysfs **********************************************************************/
static ssize_t store_sys_wmi(struct asus_wmi *asus, int devid,
const char *buf, size_t count)
{
u32 retval;
int err, value;
value = asus_wmi_get_devstate_simple(asus, devid);
if (value < 0)
return value;
err = kstrtoint(buf, 0, &value);
if (err)
return err;
err = asus_wmi_set_devstate(devid, value, &retval);
if (err < 0)
return err;
return count;
}
static ssize_t show_sys_wmi(struct asus_wmi *asus, int devid, char *buf)
{
int value = asus_wmi_get_devstate_simple(asus, devid);
if (value < 0)
return value;
return sprintf(buf, "%d\n", value);
}
#define ASUS_WMI_CREATE_DEVICE_ATTR(_name, _mode, _cm) \
static ssize_t show_##_name(struct device *dev, \
struct device_attribute *attr, \
char *buf) \
{ \
struct asus_wmi *asus = dev_get_drvdata(dev); \
\
return show_sys_wmi(asus, _cm, buf); \
} \
static ssize_t store_##_name(struct device *dev, \
struct device_attribute *attr, \
const char *buf, size_t count) \
{ \
struct asus_wmi *asus = dev_get_drvdata(dev); \
\
return store_sys_wmi(asus, _cm, buf, count); \
} \
static struct device_attribute dev_attr_##_name = { \
.attr = { \
.name = __stringify(_name), \
.mode = _mode }, \
.show = show_##_name, \
.store = store_##_name, \
}
ASUS_WMI_CREATE_DEVICE_ATTR(touchpad, 0644, ASUS_WMI_DEVID_TOUCHPAD);
ASUS_WMI_CREATE_DEVICE_ATTR(camera, 0644, ASUS_WMI_DEVID_CAMERA);
ASUS_WMI_CREATE_DEVICE_ATTR(cardr, 0644, ASUS_WMI_DEVID_CARDREADER);
ASUS_WMI_CREATE_DEVICE_ATTR(lid_resume, 0644, ASUS_WMI_DEVID_LID_RESUME);
ASUS_WMI_CREATE_DEVICE_ATTR(als_enable, 0644, ASUS_WMI_DEVID_ALS_ENABLE);
static ssize_t cpufv_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
int value, rv;
rv = kstrtoint(buf, 0, &value);
if (rv)
return rv;
if (value < 0 || value > 2)
return -EINVAL;
rv = asus_wmi_evaluate_method(ASUS_WMI_METHODID_CFVS, value, 0, NULL);
if (rv < 0)
return rv;
return count;
}
static DEVICE_ATTR_WO(cpufv);
static struct attribute *platform_attributes[] = {
&dev_attr_cpufv.attr,
&dev_attr_camera.attr,
&dev_attr_cardr.attr,
&dev_attr_touchpad.attr,
&dev_attr_lid_resume.attr,
&dev_attr_als_enable.attr,
&dev_attr_fan_boost_mode.attr,
NULL
};
static umode_t asus_sysfs_is_visible(struct kobject *kobj,
struct attribute *attr, int idx)
{
struct device *dev = container_of(kobj, struct device, kobj);
struct asus_wmi *asus = dev_get_drvdata(dev);
bool ok = true;
int devid = -1;
if (attr == &dev_attr_camera.attr)
devid = ASUS_WMI_DEVID_CAMERA;
else if (attr == &dev_attr_cardr.attr)
devid = ASUS_WMI_DEVID_CARDREADER;
else if (attr == &dev_attr_touchpad.attr)
devid = ASUS_WMI_DEVID_TOUCHPAD;
else if (attr == &dev_attr_lid_resume.attr)
devid = ASUS_WMI_DEVID_LID_RESUME;
else if (attr == &dev_attr_als_enable.attr)
devid = ASUS_WMI_DEVID_ALS_ENABLE;
else if (attr == &dev_attr_fan_boost_mode.attr)
ok = asus->fan_boost_mode_available;
if (devid != -1)
ok = !(asus_wmi_get_devstate_simple(asus, devid) < 0);
return ok ? attr->mode : 0;
}
static const struct attribute_group platform_attribute_group = {
.is_visible = asus_sysfs_is_visible,
.attrs = platform_attributes
};
static void asus_wmi_sysfs_exit(struct platform_device *device)
{
sysfs_remove_group(&device->dev.kobj, &platform_attribute_group);
}
static int asus_wmi_sysfs_init(struct platform_device *device)
{
return sysfs_create_group(&device->dev.kobj, &platform_attribute_group);
}
/* Platform device ************************************************************/
static int asus_wmi_platform_init(struct asus_wmi *asus)
{
struct device *dev = &asus->platform_device->dev;
char *wmi_uid;
int rv;
/* INIT enable hotkeys on some models */
if (!asus_wmi_evaluate_method(ASUS_WMI_METHODID_INIT, 0, 0, &rv))
pr_info("Initialization: %#x\n", rv);
/* We don't know yet what to do with this version... */
if (!asus_wmi_evaluate_method(ASUS_WMI_METHODID_SPEC, 0, 0x9, &rv)) {
pr_info("BIOS WMI version: %d.%d\n", rv >> 16, rv & 0xFF);
asus->spec = rv;
}
/*
* The SFUN method probably allows the original driver to get the list
* of features supported by a given model. For now, 0x0100 or 0x0800
* bit signifies that the laptop is equipped with a Wi-Fi MiniPCI card.
* The significance of others is yet to be found.
*/
if (!asus_wmi_evaluate_method(ASUS_WMI_METHODID_SFUN, 0, 0, &rv)) {
pr_info("SFUN value: %#x\n", rv);
asus->sfun = rv;
}
/*
* Eee PC and Notebooks seems to have different method_id for DSTS,
* but it may also be related to the BIOS's SPEC.
* Note, on most Eeepc, there is no way to check if a method exist
* or note, while on notebooks, they returns 0xFFFFFFFE on failure,
* but once again, SPEC may probably be used for that kind of things.
*
* Additionally at least TUF Gaming series laptops return nothing for
* unknown methods, so the detection in this way is not possible.
*
* There is strong indication that only ACPI WMI devices that have _UID
* equal to "ASUSWMI" use DCTS whereas those with "ATK" use DSTS.
*/
wmi_uid = wmi_get_acpi_device_uid(ASUS_WMI_MGMT_GUID);
if (!wmi_uid)
return -ENODEV;
if (!strcmp(wmi_uid, ASUS_ACPI_UID_ASUSWMI)) {
dev_info(dev, "Detected ASUSWMI, use DCTS\n");
asus->dsts_id = ASUS_WMI_METHODID_DCTS;
} else {
dev_info(dev, "Detected %s, not ASUSWMI, use DSTS\n", wmi_uid);
asus->dsts_id = ASUS_WMI_METHODID_DSTS;
}
platform/x86: asus-wmi: Support WMI event queue Event codes are expected to be retrieved from a queue on at least some models. Specifically, very likely the ACPI WMI devices with _UID ATK are queued whereas those with ASUSWMI are not [1]. The WMI event codes are pushed into a circular buffer queue. After the INIT method is called, ACPI code is allowed to push events into this buffer. The INIT method cannot be reverted. If the module is unloaded and an event (such as hotkey press) gets emitted before inserting it back the events get processed delayed by one or if the queue overflows, additionally delayed by about 3 seconds. It might be considered a minor issue and no normal user would likely observe this (there is little reason unloading the driver), but it does significantly frustrate a developer who is unlucky enough to encounter this. Therefore, the fallback to unqueued behavior occurs whenever something unexpected happens. The fix flushes the old key codes out of the queue on load. After receiving event the queue is read until either ..FFFF or 1 is encountered. Also as noted in [1] it is checked whether notify code is equal to 0xFF before enabling queue processing in WMI notify handler. DSDT examples: FX505GM Device (ATKD) { .. Name (ATKQ, Package (0x10) { 0xFFFFFFFF, .. } Method (IANQ, 1, Serialized) { If ((AQNO >= 0x10)) { Local0 = 0x64 While ((Local0 && (AQNO >= 0x10))) { Local0-- Sleep (0x0A) } ... .. AQTI++ AQTI &= 0x0F ATKQ [AQTI] = Arg0 ... } Method (GANQ, 0, Serialized) { .. If (AQNO) { ... Local0 = DerefOf (ATKQ [AQHI]) AQHI++ AQHI &= 0x0F Return (Local0) } Return (One) } This code is almost identical to K54C, which does return Ones on empty queue. K54C: Method (GANQ, 0, Serialized) { If (AQNO) { ... Return (Local0) } Return (Ones) } [1] Link: https://lkml.org/lkml/2019/4/12/104 Signed-off-by: Yurii Pavlovskyi <yurii.pavlovskyi@gmail.com> Suggested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-05-14 13:02:09 -06:00
/*
* Some devices can have multiple event codes stored in a queue before
* the module load if it was unloaded intermittently after calling
* the INIT method (enables event handling). The WMI notify handler is
* expected to retrieve all event codes until a retrieved code equals
* queue end marker (One or Ones). Old codes are flushed from the queue
* upon module load. Not enabling this when it should be has minimal
* visible impact so fall back if anything goes wrong.
*/
wmi_uid = wmi_get_acpi_device_uid(asus->driver->event_guid);
if (wmi_uid && !strcmp(wmi_uid, ASUS_ACPI_UID_ATK)) {
dev_info(dev, "Detected ATK, enable event queue\n");
if (!asus_wmi_notify_queue_flush(asus))
asus->wmi_event_queue = true;
}
/* CWAP allow to define the behavior of the Fn+F2 key,
* this method doesn't seems to be present on Eee PCs */
if (asus->driver->quirks->wapf >= 0)
asus_wmi_set_devstate(ASUS_WMI_DEVID_CWAP,
asus->driver->quirks->wapf, NULL);
return 0;
}
/* debugfs ********************************************************************/
struct asus_wmi_debugfs_node {
struct asus_wmi *asus;
char *name;
int (*show) (struct seq_file *m, void *data);
};
static int show_dsts(struct seq_file *m, void *data)
{
struct asus_wmi *asus = m->private;
int err;
u32 retval = -1;
err = asus_wmi_get_devstate(asus, asus->debug.dev_id, &retval);
if (err < 0)
return err;
seq_printf(m, "DSTS(%#x) = %#x\n", asus->debug.dev_id, retval);
return 0;
}
static int show_devs(struct seq_file *m, void *data)
{
struct asus_wmi *asus = m->private;
int err;
u32 retval = -1;
err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param,
&retval);
if (err < 0)
return err;
seq_printf(m, "DEVS(%#x, %#x) = %#x\n", asus->debug.dev_id,
asus->debug.ctrl_param, retval);
return 0;
}
static int show_call(struct seq_file *m, void *data)
{
struct asus_wmi *asus = m->private;
struct bios_args args = {
.arg0 = asus->debug.dev_id,
.arg1 = asus->debug.ctrl_param,
};
struct acpi_buffer input = { (acpi_size) sizeof(args), &args };
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
acpi_status status;
status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
0, asus->debug.method_id,
&input, &output);
if (ACPI_FAILURE(status))
return -EIO;
obj = (union acpi_object *)output.pointer;
if (obj && obj->type == ACPI_TYPE_INTEGER)
seq_printf(m, "%#x(%#x, %#x) = %#x\n", asus->debug.method_id,
asus->debug.dev_id, asus->debug.ctrl_param,
(u32) obj->integer.value);
else
seq_printf(m, "%#x(%#x, %#x) = t:%d\n", asus->debug.method_id,
asus->debug.dev_id, asus->debug.ctrl_param,
obj ? obj->type : -1);
kfree(obj);
return 0;
}
static struct asus_wmi_debugfs_node asus_wmi_debug_files[] = {
{NULL, "devs", show_devs},
{NULL, "dsts", show_dsts},
{NULL, "call", show_call},
};
static int asus_wmi_debugfs_open(struct inode *inode, struct file *file)
{
struct asus_wmi_debugfs_node *node = inode->i_private;
return single_open(file, node->show, node->asus);
}
static const struct file_operations asus_wmi_debugfs_io_ops = {
.owner = THIS_MODULE,
.open = asus_wmi_debugfs_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
static void asus_wmi_debugfs_exit(struct asus_wmi *asus)
{
debugfs_remove_recursive(asus->debug.root);
}
static void asus_wmi_debugfs_init(struct asus_wmi *asus)
{
int i;
asus->debug.root = debugfs_create_dir(asus->driver->name, NULL);
debugfs_create_x32("method_id", S_IRUGO | S_IWUSR, asus->debug.root,
&asus->debug.method_id);
debugfs_create_x32("dev_id", S_IRUGO | S_IWUSR, asus->debug.root,
&asus->debug.dev_id);
debugfs_create_x32("ctrl_param", S_IRUGO | S_IWUSR, asus->debug.root,
&asus->debug.ctrl_param);
for (i = 0; i < ARRAY_SIZE(asus_wmi_debug_files); i++) {
struct asus_wmi_debugfs_node *node = &asus_wmi_debug_files[i];
node->asus = asus;
debugfs_create_file(node->name, S_IFREG | S_IRUGO,
asus->debug.root, node,
&asus_wmi_debugfs_io_ops);
}
}
/* Init / exit ****************************************************************/
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
static int asus_wmi_add(struct platform_device *pdev)
{
struct platform_driver *pdrv = to_platform_driver(pdev->dev.driver);
struct asus_wmi_driver *wdrv = to_asus_wmi_driver(pdrv);
struct asus_wmi *asus;
const char *chassis_type;
acpi_status status;
int err;
asus-wmi: record wlan status while controlled by userapp If the user bit is set, that mean BIOS can't set and record the wlan status, it will report the value read from id ASUS_WMI_DEVID_WLAN_LED (0x00010012) while we query the wlan status by id ASUS_WMI_DEVID_WLAN (0x00010011) through WMI. So, we have to record wlan status in id ASUS_WMI_DEVID_WLAN_LED (0x00010012) while setting the wlan status through WMI. This is also the behavior that windows app will do. Quote from ASUS application engineer === When you call WMIMethod(DSTS, 0x00010011) to get WLAN status, it may return (1) 0x00050001 (On) (2) 0x00050000 (Off) (3) 0x00030001 (On) (4) 0x00030000 (Off) (5) 0x00000002 (Unknown) (1), (2) means that the model has hardware GPIO for WLAN, you can call WMIMethod(DEVS, 0x00010011, 1 or 0) to turn WLAN on/off. (3), (4) means that the model doesn’t have hardware GPIO, you need to use API or driver library to turn WLAN on/off, and call WMIMethod(DEVS, 0x00010012, 1 or 0) to set WLAN LED status. After you set WLAN LED status, you can see the WLAN status is changed with WMIMethod(DSTS, 0x00010011). Because the status is recorded lastly (ex: Windows), you can use it for synchronization. (5) means that the model doesn’t have WLAN device. WLAN is the ONLY special case with upper rule. For other device, like Bluetooth, you just need use WMIMethod(DSTS, 0x00010013) to get, and WMIMethod(DEVS, 0x00010013, 1 or 0) to set. === Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-26 03:13:31 -06:00
u32 result;
asus = kzalloc(sizeof(struct asus_wmi), GFP_KERNEL);
if (!asus)
return -ENOMEM;
asus->driver = wdrv;
asus->platform_device = pdev;
wdrv->platform_device = pdev;
platform_set_drvdata(asus->platform_device, asus);
if (wdrv->detect_quirks)
wdrv->detect_quirks(asus->driver);
err = asus_wmi_platform_init(asus);
if (err)
goto fail_platform;
err = fan_boost_mode_check_present(asus);
if (err)
goto fail_fan_boost_mode;
err = asus_wmi_sysfs_init(asus->platform_device);
if (err)
goto fail_sysfs;
err = asus_wmi_input_init(asus);
if (err)
goto fail_input;
asus-wmi: add fan control 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>
2015-05-13 08:24:16 -06:00
err = asus_wmi_fan_init(asus); /* probably no problems on error */
err = asus_wmi_hwmon_init(asus);
if (err)
goto fail_hwmon;
err = asus_wmi_led_init(asus);
if (err)
goto fail_leds;
asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_WLAN, &result);
if (result & (ASUS_WMI_DSTS_PRESENCE_BIT | ASUS_WMI_DSTS_USER_BIT))
asus->driver->wlan_ctrl_by_user = 1;
if (!(asus->driver->wlan_ctrl_by_user && ashs_present())) {
err = asus_wmi_rfkill_init(asus);
if (err)
goto fail_rfkill;
}
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
/* Some Asus desktop boards export an acpi-video backlight interface,
stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
if (chassis_type && !strcmp(chassis_type, "3"))
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
if (asus->driver->quirks->wmi_backlight_power)
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
if (asus->driver->quirks->wmi_backlight_native)
acpi_video_set_dmi_backlight_type(acpi_backlight_native);
platform/x86: asus-wmi: Set specified XUSB2PR value for X550LB The bluetooth adapter Atheros AR3012 can't be enumerated and make the bluetooth function broken. T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3362 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb The error is: usb 2-6: device not accepting address 7, error -62 usb usb2-port6: unable to enumerate USB device It is caused by adapter's connected port is mapped to xHC controller, but the xHCI is not supported by the usb device. The output of 'sudo lspci -nnxxx -s 00:14.0': 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) 00: 86 80 31 9c 06 04 90 02 04 30 03 0c 00 00 00 00 10: 04 00 a0 f7 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 1f 20 30: 00 00 00 00 70 00 00 00 00 00 00 00 0b 01 00 00 40: fd 01 36 80 89 c6 0f 80 00 00 00 00 00 00 00 00 50: 5f 2e ce 0f 00 00 00 00 00 00 00 00 00 00 00 00 60: 30 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 01 80 c2 c1 08 00 00 00 00 00 00 00 00 00 00 00 80: 05 00 87 00 0c a0 e0 fe 00 00 00 00 a1 41 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 0f 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 03 c0 30 00 00 00 00 00 03 0c 00 00 00 00 00 00 d0: f9 01 00 00 f9 01 00 00 0f 00 00 00 0f 00 00 00 e0: 00 08 00 00 00 00 00 00 00 00 00 00 d8 d8 00 00 f0: 00 00 00 00 00 00 00 00 b1 0f 04 08 00 00 00 00 By referencing Intel Platform Controller Hub(PCH) datasheet, the xHC USB 2.0 Port Routing(XUSB2PR) at offset 0xD0-0xD3h decides the setting of mapping the port to EHCI controller or xHC controller. And the port mapped to xHC will enable xHCI during bus resume. The setting of disabling bluetooth adapter's connected port is 0x000001D9. The value can be obtained by few times 1 bit flip operation. The suited configuration should have the 'lsusb -t' result with bluetooth using ehci: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 6: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 6: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M Signed-off-by: Kai-Chuan Hsieh <kai.chiuan@gmail.com> Acked-by: Corentin Chary <corentin.chary@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> [andy: resolve merge conflict in asus-wmi.h] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-09-01 09:55:55 -06:00
if (asus->driver->quirks->xusb2pr)
asus_wmi_set_xusb2pr(asus);
if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
err = asus_wmi_backlight_init(asus);
if (err && err != -ENODEV)
goto fail_backlight;
} else if (asus->driver->quirks->wmi_backlight_set_devstate)
platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey In the past, Asus firmwares would change the panel backlight directly through the EC when the display off hotkey (Fn+F7) was pressed, and only notify the OS of such change, with 0x33 when the LCD was ON and 0x34 when the LCD was OFF. These are currently mapped to KEY_DISPLAYTOGGLE and KEY_DISPLAY_OFF, respectively. Most recently the EC on Asus most machines lost ability to toggle the LCD backlight directly, but unless the OS informs the firmware it is going to handle the display toggle hotkey events, the firmware still tries change the brightness through the EC, to no effect. The end result is a long list (at Endless we counted 11) of Asus laptop models where the display toggle hotkey does not perform any action. Our firmware engineers contacts at Asus were surprised that there were still machines out there with the old behavior. Calling WMNB(ASUS_WMI_DEVID_BACKLIGHT==0x00050011, 2) on the _WDG device tells the firmware that it should let the OS handle the display toggle event, in which case it will simply notify the OS of a key press with 0x35, as shown by the DSDT excerpts bellow. Scope (_SB) { (...) Device (ATKD) { (...) Name (_WDG, Buffer (0x28) { /* 0000 */ 0xD0, 0x5E, 0x84, 0x97, 0x6D, 0x4E, 0xDE, 0x11, /* 0008 */ 0x8A, 0x39, 0x08, 0x00, 0x20, 0x0C, 0x9A, 0x66, /* 0010 */ 0x4E, 0x42, 0x01, 0x02, 0x35, 0xBB, 0x3C, 0x0B, /* 0018 */ 0xC2, 0xE3, 0xED, 0x45, 0x91, 0xC2, 0x4C, 0x5A, /* 0020 */ 0x6D, 0x19, 0x5D, 0x1C, 0xFF, 0x00, 0x01, 0x08 }) Method (WMNB, 3, Serialized) { CreateDWordField (Arg2, Zero, IIA0) CreateDWordField (Arg2, 0x04, IIA1) Local0 = (Arg1 & 0xFFFFFFFF) (...) If ((Local0 == 0x53564544)) { (...) If ((IIA0 == 0x00050011)) { If ((IIA1 == 0x02)) { ^^PCI0.SBRG.EC0.SPIN (0x72, One) ^^PCI0.SBRG.EC0.BLCT = One } Return (One) } } (...) } (...) } (...) } (...) Scope (_SB.PCI0.SBRG.EC0) { (...) Name (BLCT, Zero) (...) Method (_Q10, 0, NotSerialized) // _Qxx: EC Query { If ((BLCT == Zero)) { Local0 = One Local0 = RPIN (0x72) Local0 ^= One SPIN (0x72, Local0) If (ATKP) { Local0 = (0x34 - Local0) ^^^^ATKD.IANE (Local0) } } ElseIf ((BLCT == One)) { If (ATKP) { ^^^^ATKD.IANE (0x35) } } } (...) } Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2018-10-31 18:21:26 -06:00
err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL);
if (asus_wmi_has_fnlock_key(asus)) {
asus->fnlock_locked = true;
asus_wmi_fnlock_update(asus);
}
status = wmi_install_notify_handler(asus->driver->event_guid,
asus_wmi_notify, asus);
if (ACPI_FAILURE(status)) {
pr_err("Unable to register notify handler - %d\n", status);
err = -ENODEV;
goto fail_wmi_handler;
}
asus_wmi_battery_init(asus);
asus_wmi_debugfs_init(asus);
return 0;
fail_wmi_handler:
asus_wmi_backlight_exit(asus);
fail_backlight:
asus_wmi_rfkill_exit(asus);
fail_rfkill:
asus_wmi_led_exit(asus);
fail_leds:
fail_hwmon:
asus_wmi_input_exit(asus);
fail_input:
asus_wmi_sysfs_exit(asus->platform_device);
fail_sysfs:
fail_fan_boost_mode:
fail_platform:
kfree(asus);
return err;
}
static int asus_wmi_remove(struct platform_device *device)
{
struct asus_wmi *asus;
asus = platform_get_drvdata(device);
wmi_remove_notify_handler(asus->driver->event_guid);
asus_wmi_backlight_exit(asus);
asus_wmi_input_exit(asus);
asus_wmi_led_exit(asus);
asus_wmi_rfkill_exit(asus);
asus_wmi_debugfs_exit(asus);
asus_wmi_sysfs_exit(asus->platform_device);
asus_fan_set_auto(asus);
asus_wmi_battery_exit(asus);
kfree(asus);
return 0;
}
/* Platform driver - hibernate/resume callbacks *******************************/
static int asus_hotk_thaw(struct device *device)
{
struct asus_wmi *asus = dev_get_drvdata(device);
if (asus->wlan.rfkill) {
bool wlan;
/*
* Work around bios bug - acpi _PTS turns off the wireless led
* during suspend. Normally it restores it on resume, but
* we should kick it ourselves in case hibernation is aborted.
*/
wlan = asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_WLAN);
asus_wmi_set_devstate(ASUS_WMI_DEVID_WLAN, wlan, NULL);
}
return 0;
}
static int asus_hotk_resume(struct device *device)
{
struct asus_wmi *asus = dev_get_drvdata(device);
if (!IS_ERR_OR_NULL(asus->kbd_led.dev))
kbd_led_update(asus);
if (asus_wmi_has_fnlock_key(asus))
asus_wmi_fnlock_update(asus);
return 0;
}
static int asus_hotk_restore(struct device *device)
{
struct asus_wmi *asus = dev_get_drvdata(device);
int bl;
/* Refresh both wlan rfkill state and pci hotplug */
if (asus->wlan.rfkill)
asus_rfkill_hotplug(asus);
if (asus->bluetooth.rfkill) {
bl = !asus_wmi_get_devstate_simple(asus,
ASUS_WMI_DEVID_BLUETOOTH);
rfkill_set_sw_state(asus->bluetooth.rfkill, bl);
}
if (asus->wimax.rfkill) {
bl = !asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_WIMAX);
rfkill_set_sw_state(asus->wimax.rfkill, bl);
}
if (asus->wwan3g.rfkill) {
bl = !asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_WWAN3G);
rfkill_set_sw_state(asus->wwan3g.rfkill, bl);
}
if (asus->gps.rfkill) {
bl = !asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_GPS);
rfkill_set_sw_state(asus->gps.rfkill, bl);
}
if (asus->uwb.rfkill) {
bl = !asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_UWB);
rfkill_set_sw_state(asus->uwb.rfkill, bl);
}
if (!IS_ERR_OR_NULL(asus->kbd_led.dev))
kbd_led_update(asus);
if (asus_wmi_has_fnlock_key(asus))
asus_wmi_fnlock_update(asus);
return 0;
}
static const struct dev_pm_ops asus_pm_ops = {
.thaw = asus_hotk_thaw,
.restore = asus_hotk_restore,
.resume = asus_hotk_resume,
};
/* Registration ***************************************************************/
static int asus_wmi_probe(struct platform_device *pdev)
{
struct platform_driver *pdrv = to_platform_driver(pdev->dev.driver);
struct asus_wmi_driver *wdrv = to_asus_wmi_driver(pdrv);
int ret;
if (!wmi_has_guid(ASUS_WMI_MGMT_GUID)) {
pr_warn("ASUS Management GUID not found\n");
return -ENODEV;
}
if (wdrv->event_guid && !wmi_has_guid(wdrv->event_guid)) {
pr_warn("ASUS Event GUID not found\n");
return -ENODEV;
}
if (wdrv->probe) {
ret = wdrv->probe(pdev);
if (ret)
return ret;
}
return asus_wmi_add(pdev);
}
static bool used;
int __init_or_module asus_wmi_register_driver(struct asus_wmi_driver *driver)
{
struct platform_driver *platform_driver;
struct platform_device *platform_device;
if (used)
return -EBUSY;
platform_driver = &driver->platform_driver;
platform_driver->remove = asus_wmi_remove;
platform_driver->driver.owner = driver->owner;
platform_driver->driver.name = driver->name;
platform_driver->driver.pm = &asus_pm_ops;
platform_device = platform_create_bundle(platform_driver,
asus_wmi_probe,
NULL, 0, NULL, 0);
if (IS_ERR(platform_device))
return PTR_ERR(platform_device);
used = true;
return 0;
}
EXPORT_SYMBOL_GPL(asus_wmi_register_driver);
void asus_wmi_unregister_driver(struct asus_wmi_driver *driver)
{
platform_device_unregister(driver->platform_device);
platform_driver_unregister(&driver->platform_driver);
used = false;
}
EXPORT_SYMBOL_GPL(asus_wmi_unregister_driver);
static int __init asus_wmi_init(void)
{
pr_info("ASUS WMI generic driver loaded\n");
return 0;
}
static void __exit asus_wmi_exit(void)
{
pr_info("ASUS WMI generic driver unloaded\n");
}
module_init(asus_wmi_init);
module_exit(asus_wmi_exit);