Message ID | 20190920003938.21617-3-ayman.bagabas@gmail.com (mailing list archive) |
---|---|
State | Changes Requested, archived |
Headers | show |
Series | platform/x86: Huawei WMI laptop extras driver | expand |
On Thu, Sep 19, 2019 at 08:39:07PM -0400, Ayman Bagabas wrote: > Introduce quirks and module parameters. 3 quirks are added: > 1. Fixes reporting brightness keys twice since it's already handled by > acpi-video. > 2. Some models need a short delay when setting battery thresholds to > prevent a race condition when two processes read/write. (will be used later) > 3. Matebook X (2017) handles micmute led through the "legacy" interface > which is not currently implemented. Use ACPI EC method to control > this led. (will be used later) > > 2 module parameters are added to enable this short delay and/or report > brightness keys through this driver. module parameters are a pain to manage and handle over time. Is there any way you can "automatically" figure this out, or use a sysfs file instead? thanks, greg k-h
Hi, On 20-09-2019 08:08, Greg Kroah-Hartman wrote: > On Thu, Sep 19, 2019 at 08:39:07PM -0400, Ayman Bagabas wrote: >> Introduce quirks and module parameters. 3 quirks are added: >> 1. Fixes reporting brightness keys twice since it's already handled by >> acpi-video. >> 2. Some models need a short delay when setting battery thresholds to >> prevent a race condition when two processes read/write. (will be used later) >> 3. Matebook X (2017) handles micmute led through the "legacy" interface >> which is not currently implemented. Use ACPI EC method to control >> this led. (will be used later) >> >> 2 module parameters are added to enable this short delay and/or report >> brightness keys through this driver. > > module parameters are a pain to manage and handle over time. Is there > any way you can "automatically" figure this out, or use a sysfs file > instead? The patch also adds dmi matches to set the quirks, so the module params are there to override those and/or to easily test which are the right options with new modules. The normal / expected use-case for everything to be set automatically based on the DMI table. With that said, the module-params should really always override the dmi values, so I would like to suggest to make the module-params int-s instead of bool-s and to do something like this: static int battery_reset = -1; static int report_brightness = -1; quirks = &quirk_unknown; dmi_check_system(huawei_quirks); /* If set the module options override the vale from the DMI table */ if (battery_reset != -1) quirks->battery_reset = battery_reset; if (report_brightness != -1) quirks->report_brightness = report_brightness; Regards, Hans
On Fri, 20 Sep 2019 09:24:08 +0200, Hans de Goede wrote: > > Hi, > > On 20-09-2019 08:08, Greg Kroah-Hartman wrote: > > On Thu, Sep 19, 2019 at 08:39:07PM -0400, Ayman Bagabas wrote: > >> Introduce quirks and module parameters. 3 quirks are added: > >> 1. Fixes reporting brightness keys twice since it's already handled by > >> acpi-video. > >> 2. Some models need a short delay when setting battery thresholds to > >> prevent a race condition when two processes read/write. (will be used later) > >> 3. Matebook X (2017) handles micmute led through the "legacy" interface > >> which is not currently implemented. Use ACPI EC method to control > >> this led. (will be used later) > >> > >> 2 module parameters are added to enable this short delay and/or report > >> brightness keys through this driver. > > > > module parameters are a pain to manage and handle over time. Is there > > any way you can "automatically" figure this out, or use a sysfs file > > instead? > > The patch also adds dmi matches to set the quirks, so the module params > are there to override those and/or to easily test which are the right options > with new modules. The normal / expected use-case for everything to be set > automatically based on the DMI table. > > With that said, the module-params should really always override the dmi values, > so I would like to suggest to make the module-params int-s instead of bool-s > and to do something like this: > > static int battery_reset = -1; > static int report_brightness = -1; > > quirks = &quirk_unknown; > dmi_check_system(huawei_quirks); > /* If set the module options override the vale from the DMI table */ > if (battery_reset != -1) > quirks->battery_reset = battery_reset; > if (report_brightness != -1) > quirks->report_brightness = report_brightness; ... and use "bint" for module_param() type. thanks, Takashi
Hi, On 20-09-2019 09:29, Takashi Iwai wrote: > On Fri, 20 Sep 2019 09:24:08 +0200, > Hans de Goede wrote: >> >> Hi, >> >> On 20-09-2019 08:08, Greg Kroah-Hartman wrote: >>> On Thu, Sep 19, 2019 at 08:39:07PM -0400, Ayman Bagabas wrote: >>>> Introduce quirks and module parameters. 3 quirks are added: >>>> 1. Fixes reporting brightness keys twice since it's already handled by >>>> acpi-video. >>>> 2. Some models need a short delay when setting battery thresholds to >>>> prevent a race condition when two processes read/write. (will be used later) >>>> 3. Matebook X (2017) handles micmute led through the "legacy" interface >>>> which is not currently implemented. Use ACPI EC method to control >>>> this led. (will be used later) >>>> >>>> 2 module parameters are added to enable this short delay and/or report >>>> brightness keys through this driver. >>> >>> module parameters are a pain to manage and handle over time. Is there >>> any way you can "automatically" figure this out, or use a sysfs file >>> instead? >> >> The patch also adds dmi matches to set the quirks, so the module params >> are there to override those and/or to easily test which are the right options >> with new modules. The normal / expected use-case for everything to be set >> automatically based on the DMI table. Ugh lots of typos / missing words I need to learn to re-read before hitting send ... "modules" -> "models" "use-case" -> "use-case is" >> >> With that said, the module-params should really always override the dmi values, >> so I would like to suggest to make the module-params int-s instead of bool-s >> and to do something like this: >> >> static int battery_reset = -1; >> static int report_brightness = -1; >> >> quirks = &quirk_unknown; >> dmi_check_system(huawei_quirks); >> /* If set the module options override the vale from the DMI table */ "vale" here should be "values" of course. >> if (battery_reset != -1) >> quirks->battery_reset = battery_reset; >> if (report_brightness != -1) >> quirks->report_brightness = report_brightness; > > ... and use "bint" for module_param() type. Ack. Regards, Hans
diff --git a/drivers/platform/x86/huawei-wmi.c b/drivers/platform/x86/huawei-wmi.c index 9496ea3c78b5..97ff3d868765 100644 --- a/drivers/platform/x86/huawei-wmi.c +++ b/drivers/platform/x86/huawei-wmi.c @@ -6,6 +6,7 @@ */ #include <linux/acpi.h> +#include <linux/dmi.h> #include <linux/input.h> #include <linux/input/sparse-keymap.h> #include <linux/leds.h> @@ -22,7 +23,21 @@ #define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100" #define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100" +struct quirk_entry { + bool battery_reset; + bool ec_micmute; + bool report_brightness; +}; + +static struct quirk_entry *quirks; + +struct huawei_wmi_debug { + struct dentry *root; + u64 arg; +}; + struct huawei_wmi { + struct huawei_wmi_debug debug; struct input_dev *idev[2]; struct led_classdev cdev; struct platform_device *pdev; @@ -49,6 +64,58 @@ static const struct key_entry huawei_wmi_keymap[] = { { KE_END, 0 } }; +static bool battery_reset; +static bool report_brightness; + +module_param(battery_reset, bool, 0444); +MODULE_PARM_DESC(battery_reset, + "Reset battery charge values to (0-0) before disabling it using (0-100)"); +module_param(report_brightness, bool, 0444); +MODULE_PARM_DESC(report_brightness, + "Report brightness keys."); + +/* Quirks */ + +static int __init dmi_matched(const struct dmi_system_id *dmi) +{ + quirks = dmi->driver_data; + return 1; +} + +static struct quirk_entry quirk_unknown = { +}; + +static struct quirk_entry quirk_battery_reset = { + .battery_reset = true, +}; + +static struct quirk_entry quirk_matebook_x = { + .ec_micmute = true, + .report_brightness = true, +}; + +static const struct dmi_system_id huawei_quirks[] = { + { + .callback = dmi_matched, + .ident = "Huawei MACH-WX9", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"), + DMI_MATCH(DMI_PRODUCT_NAME, "MACH-WX9"), + }, + .driver_data = &quirk_battery_reset + }, + { + .callback = dmi_matched, + .ident = "Huawei MateBook X", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"), + DMI_MATCH(DMI_PRODUCT_NAME, "HUAWEI MateBook X") + }, + .driver_data = &quirk_matebook_x + }, + { } +}; + static int huawei_wmi_micmute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { @@ -139,6 +206,11 @@ static void huawei_wmi_process_key(struct input_dev *idev, int code) return; } + if (quirks && !quirks->report_brightness && + (key->sw.code == KEY_BRIGHTNESSDOWN || + key->sw.code == KEY_BRIGHTNESSUP)) + return; + sparse_keymap_report_entry(idev, key, 1, true); } @@ -253,6 +325,11 @@ static __init int huawei_wmi_init(void) if (!huawei_wmi) return -ENOMEM; + quirks = &quirk_unknown; + dmi_check_system(huawei_quirks); + quirks->battery_reset |= battery_reset; + quirks->report_brightness |= report_brightness; + err = platform_driver_register(&huawei_wmi_driver); if (err) goto pdrv_err;
Introduce quirks and module parameters. 3 quirks are added: 1. Fixes reporting brightness keys twice since it's already handled by acpi-video. 2. Some models need a short delay when setting battery thresholds to prevent a race condition when two processes read/write. (will be used later) 3. Matebook X (2017) handles micmute led through the "legacy" interface which is not currently implemented. Use ACPI EC method to control this led. (will be used later) 2 module parameters are added to enable this short delay and/or report brightness keys through this driver. Signed-off-by: Ayman Bagabas <ayman.bagabas@gmail.com> --- drivers/platform/x86/huawei-wmi.c | 77 +++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+)