| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Replace open coded acpi_match_acpi_device() in asus_wireless_add().
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231010134019.3892062-1-andriy.shevchenko@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
For bus-based driver, device removal is implemented as:
1 device_remove()->
2 bus->remove()->
3 driver->remove()
Driver core needs no inform from callee(bus driver) about the
result of remove callback. In that case, commit fc7a6209d571
("bus: Make remove callback return void") forces bus_type::remove
be void-returned.
Now we have the situation that both 1 & 2 of calling chain are
void-returned, so it does not make much sense for 3(driver->remove)
to return non-void to its caller.
So the basic idea behind this change is making remove() callback of
any bus-based driver to be void-returned.
This change, for itself, is for device drivers based on acpi-bus.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Lee Jones <lee@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dawei Li <set_pte_at@outlook.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for drivers/platform/surface/*
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
'ret' will not be initialized if acpi_evaluate_integer() returns through
an error path, so it should not be used in this case. This fixes the
following Smatch static analyser error:
drivers/platform/x86/asus-wireless.c:76 asus_wireless_method() error:
uninitialized symbol 'ret'.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
This commit makes use of a newly implemented RFKill LED trigger to
trigger the LED when all radios are blocked.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
u64 should be printed with %llx instead of %x and cast to uint.
Signed-off-by: João Paulo Rechi Vita <jprvita@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
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>
|
|
Sending the switch state change twice within the same frame is invalid
evdev protocol and only works if the client handles keys immediately as
well. Processing events immediately is incorrect, it forces a fake
order of events that does not exist on the device.
Recent versions of libinput changed to only process the device state and
SYN_REPORT time, so now the key event is lost.
https://bugs.freedesktop.org/show_bug.cgi?id=104041
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
|
|
Fix indentation problem introduced when this driver was first merged into
the kernel.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
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>
|
|
In the ASHS device we have the HSWC method, which calls either OWGD or
OWGS, depending on its parameter:
Device (ASHS)
{
Name (_HID, "ATK4002") // _HID: Hardware ID
Method (HSWC, 1, Serialized)
{
If ((Arg0 < 0x02))
{
OWGD (Arg0)
Return (One)
}
If ((Arg0 == 0x02))
{
Local0 = OWGS ()
If (Local0)
{
Return (0x05)
}
Else
{
Return (0x04)
}
}
If ((Arg0 == 0x03))
{
Return (0xFF)
}
If ((Arg0 == 0x04))
{
OWGD (Zero)
Return (One)
}
If ((Arg0 == 0x05))
{
OWGD (One)
Return (One)
}
If ((Arg0 == 0x80))
{
Return (One)
}
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
If ((MSOS () >= OSW8))
{
Return (0x0F)
}
Else
{
Return (Zero)
}
}
}
On the Asus laptops that do not have an airplane mode LED, OWGD has an
empty implementation and OWGS simply returns 0. On the ones that have an
airplane mode LED these methods have the following implementation:
Method (OWGD, 1, Serialized)
{
SGPL (0x0203000F, Arg0)
SGPL (0x0203000F, Arg0)
}
Method (OWGS, 0, Serialized)
{
Store (RGPL (0x0203000F), Local0)
Return (Local0)
}
Where OWGD(1) sets the airplane mode LED ON, OWGD(0) set it off, and
OWGS() returns its state.
This commit exposes the airplane mode indicator LED to userspace under
the name asus-wireless::airplane, so it can be driven according to
userspace's policy.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Reviewed-by: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
As reported in https://bugzilla.kernel.org/show_bug.cgi?id=98931#c22 in
the Asus UX31A the Asus Wireless Radio Control device (ASHS) uses the
HID "ATK4001".
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Reported-by: Tasev Nikola <tasev.stefanoska@skynet.be>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
Some Asus notebooks like the Asus E202SA and the Asus X555UB have a
separate ACPI device for notifications from the airplane mode hotkey.
This device is called "Wireless Radio Control" in Asus websites and ASHS
in the DSDT, and its ACPI _HID is ATK4002 in the two models mentioned
above.
For these models, when the airplane mode hotkey (Fn+F2) is pressed, a
query 0x0B is started in the Embedded Controller, and all this query does
is a notify ASHS with the value 0x88 (for acpi_osi >= "Windows 2012"):
Scope (_SB.PCI0.SBRG.EC0)
{
(...)
Method (_Q0B, 0, NotSerialized) // _Qxx: EC Query
{
If ((MSOS () >= OSW8))
{
Notify (ASHS, 0x88) // Device-Specific
}
Else
{
(...)
}
}
}
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
