OpenCloudOS-Kernel/drivers/platform/x86/asus-wireless.c

204 lines
5.0 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-only
/*
* Asus Wireless Radio Control Driver
*
* Copyright (C) 2015-2016 Endless Mobile, Inc.
*/
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <linux/acpi.h>
#include <linux/input.h>
#include <linux/pci_ids.h>
#include <linux/leds.h>
platform/x86: asus-wireless: Use per-HID HSWC parameters Some Asus machines use 0x4/0x5 as their LED on/off values, while others use 0x0/0x1, as shown in the DSDT excerpts below. Luckily it seems this behavior is tied to different HIDs, after looking at 44 DSDTs from different Asus models. Another small difference is that a few of them call GWBL instead of OWGS, and SWBL instead of OWGD. That does not seem to make a difference for asus-wireless, and is additional reasoning to not try to call these methods directly. Device (ASHS) | Device (ASHS) { | { Name (_HID, "ATK4002") | Name (_HID, "ATK4001") Method (HSWC, 1, Serialized) | Method (HSWC, 1, Serialized) { | { If ((Arg0 < 0x02)) | If ((Arg0 < 0x02)) { | { OWGD (Arg0) | OWGD (Arg0) Return (One) | Return (One) } | } If ((Arg0 == 0x02)) | { | If ((Arg0 == 0x02)) Local0 = OWGS () | { If (Local0) | Return (OWGS ()) { | } Return (0x05) | } | If ((Arg0 == 0x03)) Else | { { | Return (0xFF) Return (0x04) | } } | } | If ((Arg0 == 0x80)) If ((Arg0 == 0x03)) | { { | Return (One) Return (0xFF) | } } | } If ((Arg0 == 0x04)) | Method (_STA, 0, NotSerialized) { | { OWGD (Zero) | If ((MSOS () >= OSW8)) Return (One) | { } | Return (0x0F) If ((Arg0 == 0x05)) | } { | Else OWGD (One) | { Return (One) | Return (Zero) } | } If ((Arg0 == 0x80)) | } { | } Return (One) | } | } | Method (_STA, 0, NotSerialized) | { | If ((MSOS () >= OSW8)) | { | Return (0x0F) | } | Else | { | Return (Zero) | } | } | } | Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-02-08 05:45:10 +08:00
struct hswc_params {
u8 on;
u8 off;
u8 status;
};
struct asus_wireless_data {
struct input_dev *idev;
struct acpi_device *adev;
platform/x86: asus-wireless: Use per-HID HSWC parameters Some Asus machines use 0x4/0x5 as their LED on/off values, while others use 0x0/0x1, as shown in the DSDT excerpts below. Luckily it seems this behavior is tied to different HIDs, after looking at 44 DSDTs from different Asus models. Another small difference is that a few of them call GWBL instead of OWGS, and SWBL instead of OWGD. That does not seem to make a difference for asus-wireless, and is additional reasoning to not try to call these methods directly. Device (ASHS) | Device (ASHS) { | { Name (_HID, "ATK4002") | Name (_HID, "ATK4001") Method (HSWC, 1, Serialized) | Method (HSWC, 1, Serialized) { | { If ((Arg0 < 0x02)) | If ((Arg0 < 0x02)) { | { OWGD (Arg0) | OWGD (Arg0) Return (One) | Return (One) } | } If ((Arg0 == 0x02)) | { | If ((Arg0 == 0x02)) Local0 = OWGS () | { If (Local0) | Return (OWGS ()) { | } Return (0x05) | } | If ((Arg0 == 0x03)) Else | { { | Return (0xFF) Return (0x04) | } } | } | If ((Arg0 == 0x80)) If ((Arg0 == 0x03)) | { { | Return (One) Return (0xFF) | } } | } If ((Arg0 == 0x04)) | Method (_STA, 0, NotSerialized) { | { OWGD (Zero) | If ((MSOS () >= OSW8)) Return (One) | { } | Return (0x0F) If ((Arg0 == 0x05)) | } { | Else OWGD (One) | { Return (One) | Return (Zero) } | } If ((Arg0 == 0x80)) | } { | } Return (One) | } | } | Method (_STA, 0, NotSerialized) | { | If ((MSOS () >= OSW8)) | { | Return (0x0F) | } | Else | { | Return (Zero) | } | } | } | Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-02-08 05:45:10 +08:00
const struct hswc_params *hswc_params;
struct workqueue_struct *wq;
struct work_struct led_work;
struct led_classdev led;
int led_state;
};
platform/x86: asus-wireless: Use per-HID HSWC parameters Some Asus machines use 0x4/0x5 as their LED on/off values, while others use 0x0/0x1, as shown in the DSDT excerpts below. Luckily it seems this behavior is tied to different HIDs, after looking at 44 DSDTs from different Asus models. Another small difference is that a few of them call GWBL instead of OWGS, and SWBL instead of OWGD. That does not seem to make a difference for asus-wireless, and is additional reasoning to not try to call these methods directly. Device (ASHS) | Device (ASHS) { | { Name (_HID, "ATK4002") | Name (_HID, "ATK4001") Method (HSWC, 1, Serialized) | Method (HSWC, 1, Serialized) { | { If ((Arg0 < 0x02)) | If ((Arg0 < 0x02)) { | { OWGD (Arg0) | OWGD (Arg0) Return (One) | Return (One) } | } If ((Arg0 == 0x02)) | { | If ((Arg0 == 0x02)) Local0 = OWGS () | { If (Local0) | Return (OWGS ()) { | } Return (0x05) | } | If ((Arg0 == 0x03)) Else | { { | Return (0xFF) Return (0x04) | } } | } | If ((Arg0 == 0x80)) If ((Arg0 == 0x03)) | { { | Return (One) Return (0xFF) | } } | } If ((Arg0 == 0x04)) | Method (_STA, 0, NotSerialized) { | { OWGD (Zero) | If ((MSOS () >= OSW8)) Return (One) | { } | Return (0x0F) If ((Arg0 == 0x05)) | } { | Else OWGD (One) | { Return (One) | Return (Zero) } | } If ((Arg0 == 0x80)) | } { | } Return (One) | } | } | Method (_STA, 0, NotSerialized) | { | If ((MSOS () >= OSW8)) | { | Return (0x0F) | } | Else | { | Return (Zero) | } | } | } | Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-02-08 05:45:10 +08:00
static const struct hswc_params atk4001_id_params = {
.on = 0x0,
.off = 0x1,
.status = 0x2,
};
static const struct hswc_params atk4002_id_params = {
.on = 0x5,
.off = 0x4,
.status = 0x2,
};
static const struct acpi_device_id device_ids[] = {
{"ATK4001", (kernel_ulong_t)&atk4001_id_params},
{"ATK4002", (kernel_ulong_t)&atk4002_id_params},
{"", 0},
};
MODULE_DEVICE_TABLE(acpi, device_ids);
static acpi_status asus_wireless_method(acpi_handle handle, const char *method,
int param, u64 *ret)
{
struct acpi_object_list p;
union acpi_object obj;
acpi_status s;
acpi_handle_debug(handle, "Evaluating method %s, parameter %#x\n",
method, param);
obj.type = ACPI_TYPE_INTEGER;
obj.integer.value = param;
p.count = 1;
p.pointer = &obj;
s = acpi_evaluate_integer(handle, (acpi_string) method, &p, ret);
if (ACPI_FAILURE(s))
acpi_handle_err(handle,
"Failed to eval method %s, param %#x (%d)\n",
method, param, s);
else
acpi_handle_debug(handle, "%s returned %#llx\n", method, *ret);
return s;
}
static enum led_brightness led_state_get(struct led_classdev *led)
{
struct asus_wireless_data *data;
acpi_status s;
u64 ret;
data = container_of(led, struct asus_wireless_data, led);
s = asus_wireless_method(acpi_device_handle(data->adev), "HSWC",
data->hswc_params->status, &ret);
if (ACPI_SUCCESS(s) && ret == data->hswc_params->on)
return LED_FULL;
return LED_OFF;
}
static void led_state_update(struct work_struct *work)
{
struct asus_wireless_data *data;
u64 ret;
data = container_of(work, struct asus_wireless_data, led_work);
asus_wireless_method(acpi_device_handle(data->adev), "HSWC",
data->led_state, &ret);
}
static void led_state_set(struct led_classdev *led, enum led_brightness value)
{
struct asus_wireless_data *data;
data = container_of(led, struct asus_wireless_data, led);
platform/x86: asus-wireless: Use per-HID HSWC parameters Some Asus machines use 0x4/0x5 as their LED on/off values, while others use 0x0/0x1, as shown in the DSDT excerpts below. Luckily it seems this behavior is tied to different HIDs, after looking at 44 DSDTs from different Asus models. Another small difference is that a few of them call GWBL instead of OWGS, and SWBL instead of OWGD. That does not seem to make a difference for asus-wireless, and is additional reasoning to not try to call these methods directly. Device (ASHS) | Device (ASHS) { | { Name (_HID, "ATK4002") | Name (_HID, "ATK4001") Method (HSWC, 1, Serialized) | Method (HSWC, 1, Serialized) { | { If ((Arg0 < 0x02)) | If ((Arg0 < 0x02)) { | { OWGD (Arg0) | OWGD (Arg0) Return (One) | Return (One) } | } If ((Arg0 == 0x02)) | { | If ((Arg0 == 0x02)) Local0 = OWGS () | { If (Local0) | Return (OWGS ()) { | } Return (0x05) | } | If ((Arg0 == 0x03)) Else | { { | Return (0xFF) Return (0x04) | } } | } | If ((Arg0 == 0x80)) If ((Arg0 == 0x03)) | { { | Return (One) Return (0xFF) | } } | } If ((Arg0 == 0x04)) | Method (_STA, 0, NotSerialized) { | { OWGD (Zero) | If ((MSOS () >= OSW8)) Return (One) | { } | Return (0x0F) If ((Arg0 == 0x05)) | } { | Else OWGD (One) | { Return (One) | Return (Zero) } | } If ((Arg0 == 0x80)) | } { | } Return (One) | } | } | Method (_STA, 0, NotSerialized) | { | If ((MSOS () >= OSW8)) | { | Return (0x0F) | } | Else | { | Return (Zero) | } | } | } | Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-02-08 05:45:10 +08:00
data->led_state = value == LED_OFF ? data->hswc_params->off :
data->hswc_params->on;
queue_work(data->wq, &data->led_work);
}
static void asus_wireless_notify(struct acpi_device *adev, u32 event)
{
struct asus_wireless_data *data = acpi_driver_data(adev);
dev_dbg(&adev->dev, "event=%#x\n", event);
if (event != 0x88) {
dev_notice(&adev->dev, "Unknown ASHS event: %#x\n", event);
return;
}
input_report_key(data->idev, KEY_RFKILL, 1);
input_sync(data->idev);
input_report_key(data->idev, KEY_RFKILL, 0);
input_sync(data->idev);
}
static int asus_wireless_add(struct acpi_device *adev)
{
struct asus_wireless_data *data;
platform/x86: asus-wireless: Use per-HID HSWC parameters Some Asus machines use 0x4/0x5 as their LED on/off values, while others use 0x0/0x1, as shown in the DSDT excerpts below. Luckily it seems this behavior is tied to different HIDs, after looking at 44 DSDTs from different Asus models. Another small difference is that a few of them call GWBL instead of OWGS, and SWBL instead of OWGD. That does not seem to make a difference for asus-wireless, and is additional reasoning to not try to call these methods directly. Device (ASHS) | Device (ASHS) { | { Name (_HID, "ATK4002") | Name (_HID, "ATK4001") Method (HSWC, 1, Serialized) | Method (HSWC, 1, Serialized) { | { If ((Arg0 < 0x02)) | If ((Arg0 < 0x02)) { | { OWGD (Arg0) | OWGD (Arg0) Return (One) | Return (One) } | } If ((Arg0 == 0x02)) | { | If ((Arg0 == 0x02)) Local0 = OWGS () | { If (Local0) | Return (OWGS ()) { | } Return (0x05) | } | If ((Arg0 == 0x03)) Else | { { | Return (0xFF) Return (0x04) | } } | } | If ((Arg0 == 0x80)) If ((Arg0 == 0x03)) | { { | Return (One) Return (0xFF) | } } | } If ((Arg0 == 0x04)) | Method (_STA, 0, NotSerialized) { | { OWGD (Zero) | If ((MSOS () >= OSW8)) Return (One) | { } | Return (0x0F) If ((Arg0 == 0x05)) | } { | Else OWGD (One) | { Return (One) | Return (Zero) } | } If ((Arg0 == 0x80)) | } { | } Return (One) | } | } | Method (_STA, 0, NotSerialized) | { | If ((MSOS () >= OSW8)) | { | Return (0x0F) | } | Else | { | Return (Zero) | } | } | } | Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-02-08 05:45:10 +08:00
const struct acpi_device_id *id;
int err;
data = devm_kzalloc(&adev->dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
adev->driver_data = data;
platform/x86: asus-wireless: Use per-HID HSWC parameters Some Asus machines use 0x4/0x5 as their LED on/off values, while others use 0x0/0x1, as shown in the DSDT excerpts below. Luckily it seems this behavior is tied to different HIDs, after looking at 44 DSDTs from different Asus models. Another small difference is that a few of them call GWBL instead of OWGS, and SWBL instead of OWGD. That does not seem to make a difference for asus-wireless, and is additional reasoning to not try to call these methods directly. Device (ASHS) | Device (ASHS) { | { Name (_HID, "ATK4002") | Name (_HID, "ATK4001") Method (HSWC, 1, Serialized) | Method (HSWC, 1, Serialized) { | { If ((Arg0 < 0x02)) | If ((Arg0 < 0x02)) { | { OWGD (Arg0) | OWGD (Arg0) Return (One) | Return (One) } | } If ((Arg0 == 0x02)) | { | If ((Arg0 == 0x02)) Local0 = OWGS () | { If (Local0) | Return (OWGS ()) { | } Return (0x05) | } | If ((Arg0 == 0x03)) Else | { { | Return (0xFF) Return (0x04) | } } | } | If ((Arg0 == 0x80)) If ((Arg0 == 0x03)) | { { | Return (One) Return (0xFF) | } } | } If ((Arg0 == 0x04)) | Method (_STA, 0, NotSerialized) { | { OWGD (Zero) | If ((MSOS () >= OSW8)) Return (One) | { } | Return (0x0F) If ((Arg0 == 0x05)) | } { | Else OWGD (One) | { Return (One) | Return (Zero) } | } If ((Arg0 == 0x80)) | } { | } Return (One) | } | } | Method (_STA, 0, NotSerialized) | { | If ((MSOS () >= OSW8)) | { | Return (0x0F) | } | Else | { | Return (Zero) | } | } | } | Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-02-08 05:45:10 +08:00
data->adev = adev;
data->idev = devm_input_allocate_device(&adev->dev);
if (!data->idev)
return -ENOMEM;
data->idev->name = "Asus Wireless Radio Control";
data->idev->phys = "asus-wireless/input0";
data->idev->id.bustype = BUS_HOST;
data->idev->id.vendor = PCI_VENDOR_ID_ASUSTEK;
set_bit(EV_KEY, data->idev->evbit);
set_bit(KEY_RFKILL, data->idev->keybit);
err = input_register_device(data->idev);
if (err)
return err;
platform/x86: asus-wireless: Use per-HID HSWC parameters Some Asus machines use 0x4/0x5 as their LED on/off values, while others use 0x0/0x1, as shown in the DSDT excerpts below. Luckily it seems this behavior is tied to different HIDs, after looking at 44 DSDTs from different Asus models. Another small difference is that a few of them call GWBL instead of OWGS, and SWBL instead of OWGD. That does not seem to make a difference for asus-wireless, and is additional reasoning to not try to call these methods directly. Device (ASHS) | Device (ASHS) { | { Name (_HID, "ATK4002") | Name (_HID, "ATK4001") Method (HSWC, 1, Serialized) | Method (HSWC, 1, Serialized) { | { If ((Arg0 < 0x02)) | If ((Arg0 < 0x02)) { | { OWGD (Arg0) | OWGD (Arg0) Return (One) | Return (One) } | } If ((Arg0 == 0x02)) | { | If ((Arg0 == 0x02)) Local0 = OWGS () | { If (Local0) | Return (OWGS ()) { | } Return (0x05) | } | If ((Arg0 == 0x03)) Else | { { | Return (0xFF) Return (0x04) | } } | } | If ((Arg0 == 0x80)) If ((Arg0 == 0x03)) | { { | Return (One) Return (0xFF) | } } | } If ((Arg0 == 0x04)) | Method (_STA, 0, NotSerialized) { | { OWGD (Zero) | If ((MSOS () >= OSW8)) Return (One) | { } | Return (0x0F) If ((Arg0 == 0x05)) | } { | Else OWGD (One) | { Return (One) | Return (Zero) } | } If ((Arg0 == 0x80)) | } { | } Return (One) | } | } | Method (_STA, 0, NotSerialized) | { | If ((MSOS () >= OSW8)) | { | Return (0x0F) | } | Else | { | Return (Zero) | } | } | } | Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-02-08 05:45:10 +08:00
for (id = device_ids; id->id[0]; id++) {
if (!strcmp((char *) id->id, acpi_device_hid(adev))) {
data->hswc_params =
(const struct hswc_params *)id->driver_data;
break;
}
}
if (!data->hswc_params)
return 0;
data->wq = create_singlethread_workqueue("asus_wireless_workqueue");
if (!data->wq)
return -ENOMEM;
INIT_WORK(&data->led_work, led_state_update);
data->led.name = "asus-wireless::airplane";
data->led.brightness_set = led_state_set;
data->led.brightness_get = led_state_get;
data->led.flags = LED_CORE_SUSPENDRESUME;
data->led.max_brightness = 1;
data->led.default_trigger = "rfkill-none";
err = devm_led_classdev_register(&adev->dev, &data->led);
if (err)
destroy_workqueue(data->wq);
platform/x86: asus-wireless: Use per-HID HSWC parameters Some Asus machines use 0x4/0x5 as their LED on/off values, while others use 0x0/0x1, as shown in the DSDT excerpts below. Luckily it seems this behavior is tied to different HIDs, after looking at 44 DSDTs from different Asus models. Another small difference is that a few of them call GWBL instead of OWGS, and SWBL instead of OWGD. That does not seem to make a difference for asus-wireless, and is additional reasoning to not try to call these methods directly. Device (ASHS) | Device (ASHS) { | { Name (_HID, "ATK4002") | Name (_HID, "ATK4001") Method (HSWC, 1, Serialized) | Method (HSWC, 1, Serialized) { | { If ((Arg0 < 0x02)) | If ((Arg0 < 0x02)) { | { OWGD (Arg0) | OWGD (Arg0) Return (One) | Return (One) } | } If ((Arg0 == 0x02)) | { | If ((Arg0 == 0x02)) Local0 = OWGS () | { If (Local0) | Return (OWGS ()) { | } Return (0x05) | } | If ((Arg0 == 0x03)) Else | { { | Return (0xFF) Return (0x04) | } } | } | If ((Arg0 == 0x80)) If ((Arg0 == 0x03)) | { { | Return (One) Return (0xFF) | } } | } If ((Arg0 == 0x04)) | Method (_STA, 0, NotSerialized) { | { OWGD (Zero) | If ((MSOS () >= OSW8)) Return (One) | { } | Return (0x0F) If ((Arg0 == 0x05)) | } { | Else OWGD (One) | { Return (One) | Return (Zero) } | } If ((Arg0 == 0x80)) | } { | } Return (One) | } | } | Method (_STA, 0, NotSerialized) | { | If ((MSOS () >= OSW8)) | { | Return (0x0F) | } | Else | { | Return (Zero) | } | } | } | Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-02-08 05:45:10 +08:00
return err;
}
static int asus_wireless_remove(struct acpi_device *adev)
{
struct asus_wireless_data *data = acpi_driver_data(adev);
platform/x86: asus-wireless: Fix NULL pointer dereference When the module is removed the led workqueue is destroyed in the remove callback, before the led device is unregistered from the led subsystem. This leads to a NULL pointer derefence when the led device is unregistered automatically later as part of the module removal cleanup. Bellow is the backtrace showing the problem. BUG: unable to handle kernel NULL pointer dereference at (null) IP: __queue_work+0x8c/0x410 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Modules linked in: ccm edac_mce_amd kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 joydev crypto_simd asus_nb_wmi glue_helper uvcvideo snd_hda_codec_conexant snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel asus_wmi snd_hda_codec cryptd snd_hda_core sparse_keymap videobuf2_vmalloc arc4 videobuf2_memops snd_hwdep input_leds videobuf2_v4l2 ath9k psmouse videobuf2_core videodev ath9k_common snd_pcm ath9k_hw media fam15h_power ath k10temp snd_timer mac80211 i2c_piix4 r8169 mii mac_hid cfg80211 asus_wireless(-) snd soundcore wmi shpchp 8250_dw ip_tables x_tables amdkfd amd_iommu_v2 amdgpu radeon chash i2c_algo_bit drm_kms_helper syscopyarea serio_raw sysfillrect sysimgblt fb_sys_fops ahci ttm libahci drm video CPU: 3 PID: 2177 Comm: rmmod Not tainted 4.15.0-5-generic #6+dev94.b4287e5bem1-Endless Hardware name: ASUSTeK COMPUTER INC. X555DG/X555DG, BIOS 5.011 05/05/2015 RIP: 0010:__queue_work+0x8c/0x410 RSP: 0018:ffffbe8cc249fcd8 EFLAGS: 00010086 RAX: ffff992ac6810800 RBX: 0000000000000000 RCX: 0000000000000008 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff992ac6400e18 RBP: ffffbe8cc249fd18 R08: ffff992ac6400db0 R09: 0000000000000000 R10: 0000000000000040 R11: ffff992ac6400dd8 R12: 0000000000002000 R13: ffff992abd762e00 R14: ffff992abd763e38 R15: 000000000001ebe0 FS: 00007f318203e700(0000) GS:ffff992aced80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001c720e000 CR4: 00000000001406e0 Call Trace: queue_work_on+0x38/0x40 led_state_set+0x2c/0x40 [asus_wireless] led_set_brightness_nopm+0x14/0x40 led_set_brightness+0x37/0x60 led_trigger_set+0xfc/0x1d0 led_classdev_unregister+0x32/0xd0 devm_led_classdev_release+0x11/0x20 release_nodes+0x109/0x1f0 devres_release_all+0x3c/0x50 device_release_driver_internal+0x16d/0x220 driver_detach+0x3f/0x80 bus_remove_driver+0x55/0xd0 driver_unregister+0x2c/0x40 acpi_bus_unregister_driver+0x15/0x20 asus_wireless_driver_exit+0x10/0xb7c [asus_wireless] SyS_delete_module+0x1da/0x2b0 entry_SYSCALL_64_fastpath+0x24/0x87 RIP: 0033:0x7f3181b65fd7 RSP: 002b:00007ffe74bcbe18 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3181b65fd7 RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000555ea2559258 RBP: 0000555ea25591f0 R08: 00007ffe74bcad91 R09: 000000000000000a R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000003 R13: 00007ffe74bcae00 R14: 0000000000000000 R15: 0000555ea25591f0 Code: 01 00 00 02 0f 85 7d 01 00 00 48 63 45 d4 48 c7 c6 00 f4 fa 87 49 8b 9d 08 01 00 00 48 03 1c c6 4c 89 f7 e8 87 fb ff ff 48 85 c0 <48> 8b 3b 0f 84 c5 01 00 00 48 39 f8 0f 84 bc 01 00 00 48 89 c7 RIP: __queue_work+0x8c/0x410 RSP: ffffbe8cc249fcd8 CR2: 0000000000000000 ---[ end trace 7aa4f4a232e9c39c ]--- Unregistering the led device on the remove callback before destroying the workqueue avoids this problem. https://bugzilla.kernel.org/show_bug.cgi?id=196097 Reported-by: Dun Hum <bitter.taste@gmx.com> Cc: stable@vger.kernel.org Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2018-04-19 22:04:34 +08:00
if (data->wq) {
devm_led_classdev_unregister(&adev->dev, &data->led);
destroy_workqueue(data->wq);
platform/x86: asus-wireless: Fix NULL pointer dereference When the module is removed the led workqueue is destroyed in the remove callback, before the led device is unregistered from the led subsystem. This leads to a NULL pointer derefence when the led device is unregistered automatically later as part of the module removal cleanup. Bellow is the backtrace showing the problem. BUG: unable to handle kernel NULL pointer dereference at (null) IP: __queue_work+0x8c/0x410 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Modules linked in: ccm edac_mce_amd kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 joydev crypto_simd asus_nb_wmi glue_helper uvcvideo snd_hda_codec_conexant snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel asus_wmi snd_hda_codec cryptd snd_hda_core sparse_keymap videobuf2_vmalloc arc4 videobuf2_memops snd_hwdep input_leds videobuf2_v4l2 ath9k psmouse videobuf2_core videodev ath9k_common snd_pcm ath9k_hw media fam15h_power ath k10temp snd_timer mac80211 i2c_piix4 r8169 mii mac_hid cfg80211 asus_wireless(-) snd soundcore wmi shpchp 8250_dw ip_tables x_tables amdkfd amd_iommu_v2 amdgpu radeon chash i2c_algo_bit drm_kms_helper syscopyarea serio_raw sysfillrect sysimgblt fb_sys_fops ahci ttm libahci drm video CPU: 3 PID: 2177 Comm: rmmod Not tainted 4.15.0-5-generic #6+dev94.b4287e5bem1-Endless Hardware name: ASUSTeK COMPUTER INC. X555DG/X555DG, BIOS 5.011 05/05/2015 RIP: 0010:__queue_work+0x8c/0x410 RSP: 0018:ffffbe8cc249fcd8 EFLAGS: 00010086 RAX: ffff992ac6810800 RBX: 0000000000000000 RCX: 0000000000000008 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff992ac6400e18 RBP: ffffbe8cc249fd18 R08: ffff992ac6400db0 R09: 0000000000000000 R10: 0000000000000040 R11: ffff992ac6400dd8 R12: 0000000000002000 R13: ffff992abd762e00 R14: ffff992abd763e38 R15: 000000000001ebe0 FS: 00007f318203e700(0000) GS:ffff992aced80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001c720e000 CR4: 00000000001406e0 Call Trace: queue_work_on+0x38/0x40 led_state_set+0x2c/0x40 [asus_wireless] led_set_brightness_nopm+0x14/0x40 led_set_brightness+0x37/0x60 led_trigger_set+0xfc/0x1d0 led_classdev_unregister+0x32/0xd0 devm_led_classdev_release+0x11/0x20 release_nodes+0x109/0x1f0 devres_release_all+0x3c/0x50 device_release_driver_internal+0x16d/0x220 driver_detach+0x3f/0x80 bus_remove_driver+0x55/0xd0 driver_unregister+0x2c/0x40 acpi_bus_unregister_driver+0x15/0x20 asus_wireless_driver_exit+0x10/0xb7c [asus_wireless] SyS_delete_module+0x1da/0x2b0 entry_SYSCALL_64_fastpath+0x24/0x87 RIP: 0033:0x7f3181b65fd7 RSP: 002b:00007ffe74bcbe18 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3181b65fd7 RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000555ea2559258 RBP: 0000555ea25591f0 R08: 00007ffe74bcad91 R09: 000000000000000a R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000003 R13: 00007ffe74bcae00 R14: 0000000000000000 R15: 0000555ea25591f0 Code: 01 00 00 02 0f 85 7d 01 00 00 48 63 45 d4 48 c7 c6 00 f4 fa 87 49 8b 9d 08 01 00 00 48 03 1c c6 4c 89 f7 e8 87 fb ff ff 48 85 c0 <48> 8b 3b 0f 84 c5 01 00 00 48 39 f8 0f 84 bc 01 00 00 48 89 c7 RIP: __queue_work+0x8c/0x410 RSP: ffffbe8cc249fcd8 CR2: 0000000000000000 ---[ end trace 7aa4f4a232e9c39c ]--- Unregistering the led device on the remove callback before destroying the workqueue avoids this problem. https://bugzilla.kernel.org/show_bug.cgi?id=196097 Reported-by: Dun Hum <bitter.taste@gmx.com> Cc: stable@vger.kernel.org Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2018-04-19 22:04:34 +08:00
}
return 0;
}
static struct acpi_driver asus_wireless_driver = {
.name = "Asus Wireless Radio Control Driver",
.class = "hotkey",
.ids = device_ids,
.ops = {
.add = asus_wireless_add,
.remove = asus_wireless_remove,
.notify = asus_wireless_notify,
},
};
module_acpi_driver(asus_wireless_driver);
MODULE_DESCRIPTION("Asus Wireless Radio Control Driver");
MODULE_AUTHOR("João Paulo Rechi Vita <jprvita@gmail.com>");
MODULE_LICENSE("GPL");