2019-05-27 08:55:05 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2011-02-26 10:20:40 +01:00
|
|
|
/*
|
|
|
|
* Asus Notebooks WMI hotkey driver
|
|
|
|
*
|
|
|
|
* Copyright(C) 2010 Corentin Chary <corentin.chary@gmail.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/input.h>
|
|
|
|
#include <linux/input/sparse-keymap.h>
|
2012-03-20 09:53:11 +01:00
|
|
|
#include <linux/fb.h>
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
#include <linux/dmi.h>
|
platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A
Some revisions of the ASUS Q500A series have a keyboard related
issue which is reproducible only after Windows with installed ASUS
tools is started.
In this case the Linux side will have a blocked keyboard or
report incorrect or incomplete hotkey events.
To make Linux work properly again, a complete power down
(unplug power supply and remove battery) is needed.
Linux/atkbd after a clean start will get the following code on VOLUME_UP
key: {0xe0, 0x30, 0xe0, 0xb0}. After Windows, the same key will generate
this codes: {0xe1, 0x23, 0xe0, 0x30, 0xe0, 0xb0}. As result atkdb will
be confused by buggy codes.
This patch is filtering this buggy code out.
https://bugzilla.kernel.org/show_bug.cgi?id=119391
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: Alex Henrie <alexhenrie24@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: acpi4asus-user@lists.sourceforge.net
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
[dvhart: Add return after pr_warn to avoid false confirmation of filter]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-09-12 17:48:17 +02:00
|
|
|
#include <linux/i8042.h>
|
2011-02-26 10:20:40 +01:00
|
|
|
|
|
|
|
#include "asus-wmi.h"
|
|
|
|
|
|
|
|
#define ASUS_NB_WMI_FILE "asus-nb-wmi"
|
|
|
|
|
2012-12-18 01:00:05 +01:00
|
|
|
MODULE_AUTHOR("Corentin Chary <corentin.chary@gmail.com>");
|
2011-02-26 10:20:40 +01:00
|
|
|
MODULE_DESCRIPTION("Asus Notebooks WMI Hotkey Driver");
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
|
|
|
#define ASUS_NB_WMI_EVENT_GUID "0B3CBB35-E3C2-45ED-91C2-4C5A6D195D1C"
|
|
|
|
|
|
|
|
MODULE_ALIAS("wmi:"ASUS_NB_WMI_EVENT_GUID);
|
|
|
|
|
2011-07-01 11:34:39 +02:00
|
|
|
/*
|
|
|
|
* WAPF defines the behavior of the Fn+Fx wlan key
|
|
|
|
* The significance of values is yet to be found, but
|
|
|
|
* most of the time:
|
|
|
|
* Bit | Bluetooth | WLAN
|
|
|
|
* 0 | Hardware | Hardware
|
|
|
|
* 1 | Hardware | Software
|
|
|
|
* 4 | Software | Software
|
|
|
|
*/
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
static int wapf = -1;
|
2011-07-01 11:34:39 +02:00
|
|
|
module_param(wapf, uint, 0444);
|
|
|
|
MODULE_PARM_DESC(wapf, "WAPF value");
|
|
|
|
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
static struct quirk_entry *quirks;
|
|
|
|
|
platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A
Some revisions of the ASUS Q500A series have a keyboard related
issue which is reproducible only after Windows with installed ASUS
tools is started.
In this case the Linux side will have a blocked keyboard or
report incorrect or incomplete hotkey events.
To make Linux work properly again, a complete power down
(unplug power supply and remove battery) is needed.
Linux/atkbd after a clean start will get the following code on VOLUME_UP
key: {0xe0, 0x30, 0xe0, 0xb0}. After Windows, the same key will generate
this codes: {0xe1, 0x23, 0xe0, 0x30, 0xe0, 0xb0}. As result atkdb will
be confused by buggy codes.
This patch is filtering this buggy code out.
https://bugzilla.kernel.org/show_bug.cgi?id=119391
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: Alex Henrie <alexhenrie24@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: acpi4asus-user@lists.sourceforge.net
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
[dvhart: Add return after pr_warn to avoid false confirmation of filter]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-09-12 17:48:17 +02:00
|
|
|
static bool asus_q500a_i8042_filter(unsigned char data, unsigned char str,
|
|
|
|
struct serio *port)
|
|
|
|
{
|
|
|
|
static bool extended;
|
|
|
|
bool ret = false;
|
|
|
|
|
|
|
|
if (str & I8042_STR_AUXDATA)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (unlikely(data == 0xe1)) {
|
|
|
|
extended = true;
|
|
|
|
ret = true;
|
|
|
|
} else if (unlikely(extended)) {
|
|
|
|
extended = false;
|
|
|
|
ret = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-03-20 09:53:10 +01:00
|
|
|
static struct quirk_entry quirk_asus_unknown = {
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
.wapf = 0,
|
2019-06-12 09:02:02 +02:00
|
|
|
.wmi_backlight_set_devstate = true,
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
};
|
|
|
|
|
platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A
Some revisions of the ASUS Q500A series have a keyboard related
issue which is reproducible only after Windows with installed ASUS
tools is started.
In this case the Linux side will have a blocked keyboard or
report incorrect or incomplete hotkey events.
To make Linux work properly again, a complete power down
(unplug power supply and remove battery) is needed.
Linux/atkbd after a clean start will get the following code on VOLUME_UP
key: {0xe0, 0x30, 0xe0, 0xb0}. After Windows, the same key will generate
this codes: {0xe1, 0x23, 0xe0, 0x30, 0xe0, 0xb0}. As result atkdb will
be confused by buggy codes.
This patch is filtering this buggy code out.
https://bugzilla.kernel.org/show_bug.cgi?id=119391
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: Alex Henrie <alexhenrie24@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: acpi4asus-user@lists.sourceforge.net
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
[dvhart: Add return after pr_warn to avoid false confirmation of filter]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-09-12 17:48:17 +02:00
|
|
|
static struct quirk_entry quirk_asus_q500a = {
|
|
|
|
.i8042_filter = asus_q500a_i8042_filter,
|
2019-06-12 09:02:02 +02:00
|
|
|
.wmi_backlight_set_devstate = true,
|
platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A
Some revisions of the ASUS Q500A series have a keyboard related
issue which is reproducible only after Windows with installed ASUS
tools is started.
In this case the Linux side will have a blocked keyboard or
report incorrect or incomplete hotkey events.
To make Linux work properly again, a complete power down
(unplug power supply and remove battery) is needed.
Linux/atkbd after a clean start will get the following code on VOLUME_UP
key: {0xe0, 0x30, 0xe0, 0xb0}. After Windows, the same key will generate
this codes: {0xe1, 0x23, 0xe0, 0x30, 0xe0, 0xb0}. As result atkdb will
be confused by buggy codes.
This patch is filtering this buggy code out.
https://bugzilla.kernel.org/show_bug.cgi?id=119391
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: Alex Henrie <alexhenrie24@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: acpi4asus-user@lists.sourceforge.net
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
[dvhart: Add return after pr_warn to avoid false confirmation of filter]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-09-12 17:48:17 +02:00
|
|
|
};
|
|
|
|
|
asus-wmi: add display toggle quirk
For machines with AMD graphic chips, it will send out WMI event and ACPI
interrupt at the same time while hitting the hotkey. BIOS will notify the
system the next display output mode throught WMI event code, so that
windows' application can show an OSD to tell the user which mode will be
taken effect. User can hit the display toggle key many times within 2
seconds to choose the mode they want. After 2 seconds, WMI dirver should
send a WMIMethod(SDSP) command to tell the BIOS which mode the user chose.
And then BIOS will raise another ACPI interrupt to tell the system to
really switch the display mode.
In Linux desktop, we don't have this kind of OSD to let users to choose
the mode they want, so we don't need to call WMIMethod(SDSP) to have
another ACPI interrupt. To simplify the problem, we just have to ignore
the WMI event, and let the first ACPI interrupt to send out the key event.
For the need, here comes another quirk to add machines with this kind of
behavior. When the WMI driver receives the display toggle WMI event, and
found the machin is in the list, it will do nothing and let ACPI video
driver to report the key event.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2012-10-03 11:26:31 +02:00
|
|
|
/*
|
|
|
|
* For those machines that need software to control bt/wifi status
|
|
|
|
* and can't adjust brightness through ACPI interface
|
|
|
|
* and have duplicate events(ACPI and WMI) for display toggle
|
|
|
|
*/
|
|
|
|
static struct quirk_entry quirk_asus_x55u = {
|
|
|
|
.wapf = 4,
|
|
|
|
.wmi_backlight_power = true,
|
2019-06-12 09:02:02 +02:00
|
|
|
.wmi_backlight_set_devstate = true,
|
asus-wmi: add display toggle quirk
For machines with AMD graphic chips, it will send out WMI event and ACPI
interrupt at the same time while hitting the hotkey. BIOS will notify the
system the next display output mode throught WMI event code, so that
windows' application can show an OSD to tell the user which mode will be
taken effect. User can hit the display toggle key many times within 2
seconds to choose the mode they want. After 2 seconds, WMI dirver should
send a WMIMethod(SDSP) command to tell the BIOS which mode the user chose.
And then BIOS will raise another ACPI interrupt to tell the system to
really switch the display mode.
In Linux desktop, we don't have this kind of OSD to let users to choose
the mode they want, so we don't need to call WMIMethod(SDSP) to have
another ACPI interrupt. To simplify the problem, we just have to ignore
the WMI event, and let the first ACPI interrupt to send out the key event.
For the need, here comes another quirk to add machines with this kind of
behavior. When the WMI driver receives the display toggle WMI event, and
found the machin is in the list, it will do nothing and let ACPI video
driver to report the key event.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2012-10-03 11:26:31 +02:00
|
|
|
.no_display_toggle = true,
|
|
|
|
};
|
|
|
|
|
2014-07-14 09:14:34 +02:00
|
|
|
static struct quirk_entry quirk_asus_wapf4 = {
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
.wapf = 4,
|
2019-06-12 09:02:02 +02:00
|
|
|
.wmi_backlight_set_devstate = true,
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
};
|
|
|
|
|
2014-07-09 10:18:19 +02:00
|
|
|
static struct quirk_entry quirk_asus_x200ca = {
|
|
|
|
.wapf = 2,
|
2019-06-12 09:02:02 +02:00
|
|
|
.wmi_backlight_set_devstate = true,
|
2014-07-09 10:18:19 +02:00
|
|
|
};
|
|
|
|
|
2016-08-28 10:12:06 +02:00
|
|
|
static struct quirk_entry quirk_asus_ux303ub = {
|
|
|
|
.wmi_backlight_native = true,
|
2019-06-12 09:02:02 +02:00
|
|
|
.wmi_backlight_set_devstate = true,
|
2016-08-28 10:12:06 +02:00
|
|
|
};
|
|
|
|
|
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 17:55:55 +02:00
|
|
|
static struct quirk_entry quirk_asus_x550lb = {
|
2019-06-12 09:02:02 +02:00
|
|
|
.wmi_backlight_set_devstate = true,
|
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 17:55:55 +02:00
|
|
|
.xusb2pr = 0x01D9,
|
|
|
|
};
|
|
|
|
|
2017-11-20 22:18:44 +01:00
|
|
|
static struct quirk_entry quirk_asus_forceals = {
|
2019-06-12 09:02:02 +02:00
|
|
|
.wmi_backlight_set_devstate = true,
|
2017-04-28 16:19:49 +02:00
|
|
|
.wmi_force_als_set = true,
|
|
|
|
};
|
|
|
|
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
static int dmi_matched(const struct dmi_system_id *dmi)
|
|
|
|
{
|
2016-11-30 02:08:49 +01:00
|
|
|
pr_info("Identified laptop model '%s'\n", dmi->ident);
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
quirks = dmi->driver_data;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-07-16 19:43:08 +02:00
|
|
|
static const struct dmi_system_id asus_quirks[] = {
|
platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A
Some revisions of the ASUS Q500A series have a keyboard related
issue which is reproducible only after Windows with installed ASUS
tools is started.
In this case the Linux side will have a blocked keyboard or
report incorrect or incomplete hotkey events.
To make Linux work properly again, a complete power down
(unplug power supply and remove battery) is needed.
Linux/atkbd after a clean start will get the following code on VOLUME_UP
key: {0xe0, 0x30, 0xe0, 0xb0}. After Windows, the same key will generate
this codes: {0xe1, 0x23, 0xe0, 0x30, 0xe0, 0xb0}. As result atkdb will
be confused by buggy codes.
This patch is filtering this buggy code out.
https://bugzilla.kernel.org/show_bug.cgi?id=119391
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: Alex Henrie <alexhenrie24@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: acpi4asus-user@lists.sourceforge.net
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
[dvhart: Add return after pr_warn to avoid false confirmation of filter]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-09-12 17:48:17 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. Q500A",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Q500A"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_q500a,
|
|
|
|
},
|
2014-07-29 11:59:57 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. U32U",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "U32U"),
|
|
|
|
},
|
|
|
|
/*
|
|
|
|
* Note this machine has a Brazos APU, and most Brazos Asus
|
|
|
|
* machines need quirk_asus_x55u / wmi_backlight_power but
|
|
|
|
* here acpi-video seems to work fine for backlight control.
|
|
|
|
*/
|
|
|
|
.driver_data = &quirk_asus_wapf4,
|
|
|
|
},
|
2017-04-04 20:09:00 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X302UA",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X302UA"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_wapf4,
|
|
|
|
},
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X401U",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X401U"),
|
|
|
|
},
|
asus-wmi: add display toggle quirk
For machines with AMD graphic chips, it will send out WMI event and ACPI
interrupt at the same time while hitting the hotkey. BIOS will notify the
system the next display output mode throught WMI event code, so that
windows' application can show an OSD to tell the user which mode will be
taken effect. User can hit the display toggle key many times within 2
seconds to choose the mode they want. After 2 seconds, WMI dirver should
send a WMIMethod(SDSP) command to tell the BIOS which mode the user chose.
And then BIOS will raise another ACPI interrupt to tell the system to
really switch the display mode.
In Linux desktop, we don't have this kind of OSD to let users to choose
the mode they want, so we don't need to call WMIMethod(SDSP) to have
another ACPI interrupt. To simplify the problem, we just have to ignore
the WMI event, and let the first ACPI interrupt to send out the key event.
For the need, here comes another quirk to add machines with this kind of
behavior. When the WMI driver receives the display toggle WMI event, and
found the machin is in the list, it will do nothing and let ACPI video
driver to report the key event.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2012-10-03 11:26:31 +02:00
|
|
|
.driver_data = &quirk_asus_x55u,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X401A",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X401A"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X401A1",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X401A1"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
},
|
2016-11-30 02:23:06 +01:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X45U",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X45U"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_wapf4,
|
|
|
|
},
|
2015-09-03 00:10:34 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X456UA",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X456UA"),
|
|
|
|
},
|
2017-02-20 20:50:23 +01:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
2015-09-03 00:10:34 +02:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X456UF",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X456UF"),
|
|
|
|
},
|
2017-02-20 20:50:23 +01:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
2015-09-03 00:10:34 +02:00
|
|
|
},
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X501U",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X501U"),
|
|
|
|
},
|
asus-wmi: add display toggle quirk
For machines with AMD graphic chips, it will send out WMI event and ACPI
interrupt at the same time while hitting the hotkey. BIOS will notify the
system the next display output mode throught WMI event code, so that
windows' application can show an OSD to tell the user which mode will be
taken effect. User can hit the display toggle key many times within 2
seconds to choose the mode they want. After 2 seconds, WMI dirver should
send a WMIMethod(SDSP) command to tell the BIOS which mode the user chose.
And then BIOS will raise another ACPI interrupt to tell the system to
really switch the display mode.
In Linux desktop, we don't have this kind of OSD to let users to choose
the mode they want, so we don't need to call WMIMethod(SDSP) to have
another ACPI interrupt. To simplify the problem, we just have to ignore
the WMI event, and let the first ACPI interrupt to send out the key event.
For the need, here comes another quirk to add machines with this kind of
behavior. When the WMI driver receives the display toggle WMI event, and
found the machin is in the list, it will do nothing and let ACPI video
driver to report the key event.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2012-10-03 11:26:31 +02:00
|
|
|
.driver_data = &quirk_asus_x55u,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X501A",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X501A"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X501A1",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X501A1"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
},
|
2014-05-06 22:27:45 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X550CA",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X550CA"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
2014-05-06 22:27:45 +02:00
|
|
|
},
|
2014-07-18 12:15:09 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X550CC",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X550CC"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_wapf4,
|
|
|
|
},
|
2014-07-14 09:14:35 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X550CL",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X550CL"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_wapf4,
|
|
|
|
},
|
2014-10-26 11:23:55 +01:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X550VB",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X550VB"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_wapf4,
|
|
|
|
},
|
2014-11-24 11:26:32 +01:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X551CA",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X551CA"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_wapf4,
|
|
|
|
},
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X55A",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X55A"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X55C",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X55C"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X55U",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X55U"),
|
|
|
|
},
|
asus-wmi: add display toggle quirk
For machines with AMD graphic chips, it will send out WMI event and ACPI
interrupt at the same time while hitting the hotkey. BIOS will notify the
system the next display output mode throught WMI event code, so that
windows' application can show an OSD to tell the user which mode will be
taken effect. User can hit the display toggle key many times within 2
seconds to choose the mode they want. After 2 seconds, WMI dirver should
send a WMIMethod(SDSP) command to tell the BIOS which mode the user chose.
And then BIOS will raise another ACPI interrupt to tell the system to
really switch the display mode.
In Linux desktop, we don't have this kind of OSD to let users to choose
the mode they want, so we don't need to call WMIMethod(SDSP) to have
another ACPI interrupt. To simplify the problem, we just have to ignore
the WMI event, and let the first ACPI interrupt to send out the key event.
For the need, here comes another quirk to add machines with this kind of
behavior. When the WMI driver receives the display toggle WMI event, and
found the machin is in the list, it will do nothing and let ACPI video
driver to report the key event.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2012-10-03 11:26:31 +02:00
|
|
|
.driver_data = &quirk_asus_x55u,
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X55VD",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X55VD"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
2013-04-25 09:11:07 +02:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X75A",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X75A"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
},
|
2014-05-06 22:03:38 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X75VBP",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X75VBP"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
2014-05-06 22:03:38 +02:00
|
|
|
},
|
2016-02-17 12:35:46 +01:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X75VD",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X75VD"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_wapf4,
|
|
|
|
},
|
2013-07-03 08:35:15 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. 1015E",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "1015E"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
2013-07-03 08:35:15 +02:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. 1015U",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "1015U"),
|
|
|
|
},
|
2014-07-14 09:14:34 +02:00
|
|
|
.driver_data = &quirk_asus_wapf4,
|
2013-07-03 08:35:15 +02:00
|
|
|
},
|
2014-07-09 10:18:19 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X200CA",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X200CA"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_x200ca,
|
|
|
|
},
|
2016-08-28 10:12:06 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. UX303UB",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_ux303ub,
|
|
|
|
},
|
2017-04-28 16:19:49 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. UX330UAK",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "UX330UAK"),
|
|
|
|
},
|
2017-11-20 22:18:44 +01:00
|
|
|
.driver_data = &quirk_asus_forceals,
|
2017-04-28 16:19:49 +02:00
|
|
|
},
|
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 17:55:55 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. X550LB",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X550LB"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_x550lb,
|
|
|
|
},
|
2017-11-20 22:18:44 +01:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. UX430UQ",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "UX430UQ"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_forceals,
|
|
|
|
},
|
2019-08-04 17:21:43 +02:00
|
|
|
{
|
|
|
|
.callback = dmi_matched,
|
|
|
|
.ident = "ASUSTeK COMPUTER INC. UX430UNR",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "UX430UNR"),
|
|
|
|
},
|
|
|
|
.driver_data = &quirk_asus_forceals,
|
|
|
|
},
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
{},
|
2012-03-20 09:53:10 +01:00
|
|
|
};
|
|
|
|
|
2011-07-01 11:34:39 +02:00
|
|
|
static void asus_nb_wmi_quirks(struct asus_wmi_driver *driver)
|
|
|
|
{
|
platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A
Some revisions of the ASUS Q500A series have a keyboard related
issue which is reproducible only after Windows with installed ASUS
tools is started.
In this case the Linux side will have a blocked keyboard or
report incorrect or incomplete hotkey events.
To make Linux work properly again, a complete power down
(unplug power supply and remove battery) is needed.
Linux/atkbd after a clean start will get the following code on VOLUME_UP
key: {0xe0, 0x30, 0xe0, 0xb0}. After Windows, the same key will generate
this codes: {0xe1, 0x23, 0xe0, 0x30, 0xe0, 0xb0}. As result atkdb will
be confused by buggy codes.
This patch is filtering this buggy code out.
https://bugzilla.kernel.org/show_bug.cgi?id=119391
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: Alex Henrie <alexhenrie24@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: acpi4asus-user@lists.sourceforge.net
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
[dvhart: Add return after pr_warn to avoid false confirmation of filter]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-09-12 17:48:17 +02:00
|
|
|
int ret;
|
|
|
|
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
quirks = &quirk_asus_unknown;
|
|
|
|
dmi_check_system(asus_quirks);
|
|
|
|
|
|
|
|
driver->quirks = quirks;
|
2012-03-20 09:53:11 +01:00
|
|
|
driver->panel_power = FB_BLANK_UNBLANK;
|
asus-nb-wmi: add wapf quirk for ASUS machines
The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.
To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.
With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.
1. https://lkml.org/lkml/2012/5/21/75
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-04 05:19:08 +02:00
|
|
|
|
|
|
|
/* overwrite the wapf setting if the wapf paramater is specified */
|
|
|
|
if (wapf != -1)
|
|
|
|
quirks->wapf = wapf;
|
|
|
|
else
|
|
|
|
wapf = quirks->wapf;
|
platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A
Some revisions of the ASUS Q500A series have a keyboard related
issue which is reproducible only after Windows with installed ASUS
tools is started.
In this case the Linux side will have a blocked keyboard or
report incorrect or incomplete hotkey events.
To make Linux work properly again, a complete power down
(unplug power supply and remove battery) is needed.
Linux/atkbd after a clean start will get the following code on VOLUME_UP
key: {0xe0, 0x30, 0xe0, 0xb0}. After Windows, the same key will generate
this codes: {0xe1, 0x23, 0xe0, 0x30, 0xe0, 0xb0}. As result atkdb will
be confused by buggy codes.
This patch is filtering this buggy code out.
https://bugzilla.kernel.org/show_bug.cgi?id=119391
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: Alex Henrie <alexhenrie24@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: acpi4asus-user@lists.sourceforge.net
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
[dvhart: Add return after pr_warn to avoid false confirmation of filter]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-09-12 17:48:17 +02:00
|
|
|
|
|
|
|
if (quirks->i8042_filter) {
|
|
|
|
ret = i8042_install_filter(quirks->i8042_filter);
|
|
|
|
if (ret) {
|
|
|
|
pr_warn("Unable to install key filter\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
pr_info("Using i8042 filter function for receiving events\n");
|
|
|
|
}
|
2011-07-01 11:34:39 +02:00
|
|
|
}
|
|
|
|
|
2011-02-26 10:20:40 +01:00
|
|
|
static const struct key_entry asus_nb_wmi_keymap[] = {
|
2012-11-29 09:12:38 +01:00
|
|
|
{ KE_KEY, ASUS_WMI_BRN_DOWN, { KEY_BRIGHTNESSDOWN } },
|
|
|
|
{ KE_KEY, ASUS_WMI_BRN_UP, { KEY_BRIGHTNESSUP } },
|
2011-02-26 10:20:40 +01:00
|
|
|
{ KE_KEY, 0x30, { KEY_VOLUMEUP } },
|
|
|
|
{ KE_KEY, 0x31, { KEY_VOLUMEDOWN } },
|
|
|
|
{ KE_KEY, 0x32, { KEY_MUTE } },
|
2018-11-01 01:21:27 +01:00
|
|
|
{ KE_KEY, 0x35, { KEY_SCREENLOCK } },
|
2011-02-26 10:20:40 +01:00
|
|
|
{ KE_KEY, 0x40, { KEY_PREVIOUSSONG } },
|
|
|
|
{ KE_KEY, 0x41, { KEY_NEXTSONG } },
|
2012-10-03 11:26:26 +02:00
|
|
|
{ KE_KEY, 0x43, { KEY_STOPCD } }, /* Stop/Eject */
|
2011-02-26 10:20:40 +01:00
|
|
|
{ KE_KEY, 0x45, { KEY_PLAYPAUSE } },
|
2012-10-03 11:26:26 +02:00
|
|
|
{ KE_KEY, 0x4c, { KEY_MEDIA } }, /* WMP Key */
|
2011-02-26 10:20:40 +01:00
|
|
|
{ KE_KEY, 0x50, { KEY_EMAIL } },
|
|
|
|
{ KE_KEY, 0x51, { KEY_WWW } },
|
|
|
|
{ KE_KEY, 0x55, { KEY_CALC } },
|
2012-03-20 09:53:02 +01:00
|
|
|
{ KE_IGNORE, 0x57, }, /* Battery mode */
|
|
|
|
{ KE_IGNORE, 0x58, }, /* AC mode */
|
2011-02-26 10:20:40 +01:00
|
|
|
{ KE_KEY, 0x5C, { KEY_F15 } }, /* Power Gear key */
|
2011-07-01 11:34:39 +02:00
|
|
|
{ KE_KEY, 0x5D, { KEY_WLAN } }, /* Wireless console Toggle */
|
|
|
|
{ KE_KEY, 0x5E, { KEY_WLAN } }, /* Wireless console Enable */
|
|
|
|
{ KE_KEY, 0x5F, { KEY_WLAN } }, /* Wireless console Disable */
|
2012-10-03 11:26:29 +02:00
|
|
|
{ KE_KEY, 0x60, { KEY_TOUCHPAD_ON } },
|
2012-10-03 11:26:30 +02:00
|
|
|
{ KE_KEY, 0x61, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD only */
|
|
|
|
{ KE_KEY, 0x62, { KEY_SWITCHVIDEOMODE } }, /* SDSP CRT only */
|
|
|
|
{ KE_KEY, 0x63, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + CRT */
|
|
|
|
{ KE_KEY, 0x64, { KEY_SWITCHVIDEOMODE } }, /* SDSP TV */
|
|
|
|
{ KE_KEY, 0x65, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + TV */
|
|
|
|
{ KE_KEY, 0x66, { KEY_SWITCHVIDEOMODE } }, /* SDSP CRT + TV */
|
|
|
|
{ KE_KEY, 0x67, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + CRT + TV */
|
2011-02-26 10:20:40 +01:00
|
|
|
{ KE_KEY, 0x6B, { KEY_TOUCHPAD_TOGGLE } },
|
2012-10-03 11:26:25 +02:00
|
|
|
{ KE_IGNORE, 0x6E, }, /* Low Battery notification */
|
2016-06-19 13:59:26 +02:00
|
|
|
{ KE_KEY, 0x7a, { KEY_ALS_TOGGLE } }, /* Ambient Light Sensor Toggle */
|
2019-05-14 21:02:58 +02:00
|
|
|
{ KE_KEY, 0x7c, { KEY_MICMUTE } },
|
2012-10-03 11:26:26 +02:00
|
|
|
{ KE_KEY, 0x7D, { KEY_BLUETOOTH } }, /* Bluetooth Enable */
|
|
|
|
{ KE_KEY, 0x7E, { KEY_BLUETOOTH } }, /* Bluetooth Disable */
|
2011-02-26 10:20:40 +01:00
|
|
|
{ KE_KEY, 0x82, { KEY_CAMERA } },
|
2012-10-03 11:26:26 +02:00
|
|
|
{ KE_KEY, 0x88, { KEY_RFKILL } }, /* Radio Toggle Key */
|
|
|
|
{ KE_KEY, 0x8A, { KEY_PROG1 } }, /* Color enhancement mode */
|
2012-10-03 11:26:30 +02:00
|
|
|
{ KE_KEY, 0x8C, { KEY_SWITCHVIDEOMODE } }, /* SDSP DVI only */
|
|
|
|
{ KE_KEY, 0x8D, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + DVI */
|
|
|
|
{ KE_KEY, 0x8E, { KEY_SWITCHVIDEOMODE } }, /* SDSP CRT + DVI */
|
|
|
|
{ KE_KEY, 0x8F, { KEY_SWITCHVIDEOMODE } }, /* SDSP TV + DVI */
|
|
|
|
{ KE_KEY, 0x90, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + CRT + DVI */
|
|
|
|
{ KE_KEY, 0x91, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + TV + DVI */
|
|
|
|
{ KE_KEY, 0x92, { KEY_SWITCHVIDEOMODE } }, /* SDSP CRT + TV + DVI */
|
|
|
|
{ KE_KEY, 0x93, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + CRT + TV + DVI */
|
2011-02-26 10:20:40 +01:00
|
|
|
{ KE_KEY, 0x95, { KEY_MEDIA } },
|
2019-05-14 21:02:58 +02:00
|
|
|
{ KE_KEY, 0x99, { KEY_PHONE } }, /* Conflicts with fan mode switch */
|
2012-07-04 09:20:14 +02:00
|
|
|
{ KE_KEY, 0xA0, { KEY_SWITCHVIDEOMODE } }, /* SDSP HDMI only */
|
|
|
|
{ KE_KEY, 0xA1, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + HDMI */
|
|
|
|
{ KE_KEY, 0xA2, { KEY_SWITCHVIDEOMODE } }, /* SDSP CRT + HDMI */
|
|
|
|
{ KE_KEY, 0xA3, { KEY_SWITCHVIDEOMODE } }, /* SDSP TV + HDMI */
|
2012-10-03 11:26:30 +02:00
|
|
|
{ KE_KEY, 0xA4, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + CRT + HDMI */
|
|
|
|
{ KE_KEY, 0xA5, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + TV + HDMI */
|
|
|
|
{ KE_KEY, 0xA6, { KEY_SWITCHVIDEOMODE } }, /* SDSP CRT + TV + HDMI */
|
|
|
|
{ KE_KEY, 0xA7, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + CRT + TV + HDMI */
|
2012-10-03 11:26:26 +02:00
|
|
|
{ KE_KEY, 0xB5, { KEY_CALC } },
|
|
|
|
{ KE_KEY, 0xC4, { KEY_KBDILLUMUP } },
|
|
|
|
{ KE_KEY, 0xC5, { KEY_KBDILLUMDOWN } },
|
2013-05-23 06:17:11 +02:00
|
|
|
{ KE_IGNORE, 0xC6, }, /* Ambient Light Sensor notification */
|
2018-08-10 22:07:25 +02:00
|
|
|
{ KE_KEY, 0xFA, { KEY_PROG2 } }, /* Lid flip action */
|
2011-02-26 10:20:40 +01:00
|
|
|
{ KE_END, 0},
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct asus_wmi_driver asus_nb_wmi_driver = {
|
|
|
|
.name = ASUS_NB_WMI_FILE,
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.event_guid = ASUS_NB_WMI_EVENT_GUID,
|
|
|
|
.keymap = asus_nb_wmi_keymap,
|
|
|
|
.input_name = "Asus WMI hotkeys",
|
|
|
|
.input_phys = ASUS_NB_WMI_FILE "/input0",
|
2012-03-20 09:53:08 +01:00
|
|
|
.detect_quirks = asus_nb_wmi_quirks,
|
2011-02-26 10:20:40 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
static int __init asus_nb_wmi_init(void)
|
|
|
|
{
|
|
|
|
return asus_wmi_register_driver(&asus_nb_wmi_driver);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit asus_nb_wmi_exit(void)
|
|
|
|
{
|
|
|
|
asus_wmi_unregister_driver(&asus_nb_wmi_driver);
|
|
|
|
}
|
|
|
|
|
|
|
|
module_init(asus_nb_wmi_init);
|
|
|
|
module_exit(asus_nb_wmi_exit);
|