Re: [PATCH] platform/x86: huawei-wmi: add ACPI fallback for Fn-lock on newer models

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 8875 bytes --]

On Tue, 26 May 2026, Superstes wrote:

> >> Thank you for working on this. Could you open an issue and/or send a PR
> to https://github.com/aymanbagabas/Huawei-WMI ?
> Yes, I can send PR in the next two-three days.
> >> This is very specific to the FLMH-XX model. Can you confirm this is the case for
> other newer models?No, it is the latest model in the Matebook 14 series, I've just
> bought it recently and faced multiple issues, which I try to resolve. I can't found
> any information about that issues from another users, but i think that it can be
> related with other recent laptop based on Intel Core Ultra processors, it will be
> good to have someone with following models:
> MateBook Fold (2025)
> MateBook X Pro (2024)
> MateBook GT 14 (2024)
> MateBook D 14 (2024)
> >> Wouldn't it be better to put this behavior behind a quirk instead of enforcing it
> on the whole module?
> I haven't found a better place to make such changes. But you can suggest something.
> But I think that my workaround is safe because it calls very specific ACPI objects
> and uses default fallbacks.
> 
> By the way, maybe You, or Ilpo knows a good place to implement board specific i2c
> acpi fixes? It Looks like there is a race condition situation which leads to
> arbitration loss when kernel tries to initialize multiple devices on the i2c bus. To
> fix this I've disabled light sensor and made systemd service to remove and enable
> the i2c_hid_acpi module, but I haven't found a place where to implement a quirk that
> fixes that issue.

Do you mean you'd want to serialize .probe()s of those devices?

--
 i.

> пн, 25 мая 2026 г. в 23:38, Ayman Bagabas <ayman.bagabas@gmail.com>:
>       >
>       > Newer Huawei laptops (e.g. FLMH-XX / MateBook 14 2024) no longer
>       support
>       > the legacy WMI interface for Fn-lock control. Instead, they expose
>       direct
>       > ACPI methods \GFRS and \SFRS (Get/Set Fn key Reversal Status) which
>       > communicate with the EC via registers 0x6B (read) and 0x6C (write).
>       >
>       > Add huawei_acpi_fn_lock_get() and huawei_acpi_fn_lock_set() helpers
>       that
>       > use acpi_evaluate_object() to call these methods. Both
>       > huawei_wmi_fn_lock_get() and huawei_wmi_fn_lock_set() now probe for
>       > \GFRS/\SFRS via acpi_has_method() first and fall back to the legacy WMI
>       > path if not present.
> 
>       Thank you for working on this. Could you open an issue and/or send a PR
>       to https://github.com/aymanbagabas/Huawei-WMI ?
> 
>       >
>       > Tested on: HUAWEI FLMH-XX (MateBook 14 2024),
>       > CachyOS (kernel 7.0.9-1-cachyos).
>       >
>       > Signed-off-by: Shaposhnikov Daniil <2minesweeper2@gmail.com>
>       > ---
>       >  drivers/platform/x86/huawei-wmi.c | 95 +++++++++++++++++++++++++++++++
>       >  1 file changed, 95 insertions(+)
>       >
>       > diff --git a/drivers/platform/x86/huawei-wmi.c
>       b/drivers/platform/x86/huawei-wmi.c
>       > index 93cca17fdf58..19cd8f1a8e33 100644
>       > --- a/drivers/platform/x86/huawei-wmi.c
>       > +++ b/drivers/platform/x86/huawei-wmi.c
>       > @@ -527,11 +527,101 @@ static void huawei_wmi_battery_exit(struct
>       device *dev)
>       >
>       >  /* Fn lock */
>       >
>       > +/*
>       > + * Newer Huawei models (e.g. HUAWEI FLMH-XX / MateBook 14 2024) use
>       direct
>       > + * ACPI methods \GFRS / \SFRS (Get/Set Fn key Reversal Status) to
>       control
>       > + * Fn-lock via EC registers 0x6B (read) and 0x6C (write).
>       > + *
>       > + * GFRS response buffer layout:
>       > + *   byte[0] = STAT (0 = success)
>       > + *   byte[1] = 0x01 (fn-lock off) or 0x02 (fn-lock on)
>       > + *
>       > + * SFRS argument layout (CreateByteField(Arg0, 0x02, FRSR)):
>       > + *   Value is read from byte[2] of the integer argument, so it must be
>       > + *   passed as (value << 16):
>       > + *   (1 << 16) = fn-lock off (writes 0x55 to EC 0x6C)
>       > + *   (2 << 16) = fn-lock on  (writes 0x5A to EC 0x6C)
>       > + */
> 
>       This is very specific to the FLMH-XX model. Can you confirm this is the
>       case for other newer models?
> 
>       > +
>       > +static int huawei_acpi_fn_lock_get(int *on)
>       > +{
>       > +       union acpi_object acpi_arg, *obj;
>       > +       struct acpi_object_list arg_list = { .count = 1, .pointer =
>       &acpi_arg };
>       > +       struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
>       > +       acpi_status status;
>       > +       u8 val;
>       > +
>       > +       acpi_arg.type = ACPI_TYPE_INTEGER;
>       > +       acpi_arg.integer.value = 0;
>       > +
>       > +       status = acpi_evaluate_object(NULL, "\\GFRS", &arg_list,
>       &output);
>       > +       if (ACPI_FAILURE(status))
>       > +               return -EIO;
>       > +
>       > +       obj = output.pointer;
>       > +       if (!obj || obj->type != ACPI_TYPE_BUFFER || obj->buffer.length
>       < 2) {
>       > +               kfree(obj);
>       > +               return -ENODATA;
>       > +       }
>       > +
>       > +       /* byte[0] = STAT (0 = success), byte[1] = 1 (off) or 2 (on) */
>       > +       if (obj->buffer.pointer[0] != 0) {
>       > +               kfree(obj);
>       > +               return -EIO;
>       > +       }
>       > +
>       > +       val = obj->buffer.pointer[1];
>       > +       if (val != 1 && val != 2) {
>       > +               kfree(obj);
>       > +               return -ENODATA;
>       > +       }
>       > +
>       > +       if (on)
>       > +               *on = val - 1; /* 1→0 (off), 2→1 (on) */
>       > +
>       > +       kfree(obj);
>       > +       return 0;
>       > +}
>       > +
>       > +static int huawei_acpi_fn_lock_set(int on)
>       > +{
>       > +       union acpi_object acpi_arg, *obj;
>       > +       struct acpi_object_list arg_list = { .count = 1, .pointer =
>       &acpi_arg };
>       > +       struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
>       > +       acpi_status status;
>       > +       int ret = 0;
>       > +
>       > +       /*
>       > +        * SFRS reads byte[2] of its argument via CreateByteField(Arg0,
>       0x02).
>       > +        * on=0 → FRSR=1 → EC gets 0x55 (fn-lock off)
>       > +        * on=1 → FRSR=2 → EC gets 0x5A (fn-lock on)
>       > +        */
>       > +       acpi_arg.type = ACPI_TYPE_INTEGER;
>       > +       acpi_arg.integer.value = (u64)(on + 1) << 16;
>       > +
>       > +       status = acpi_evaluate_object(NULL, "\\SFRS", &arg_list,
>       &output);
>       > +       if (ACPI_FAILURE(status))
>       > +               return -EIO;
>       > +
>       > +       obj = output.pointer;
>       > +       if (obj && obj->type == ACPI_TYPE_BUFFER &&
>       > +           obj->buffer.length >= 1 && obj->buffer.pointer[0] != 0)
>       > +               ret = -EIO;
>       > +
>       > +       kfree(obj);
>       > +       return ret;
>       > +}
>       > +
>       >  static int huawei_wmi_fn_lock_get(int *on)
>       >  {
>       >         u8 ret[0x100] = { 0 };
>       >         int err, i;
>       >
>       > +       /* Newer models: use direct ACPI \GFRS method */
>       > +       if (acpi_has_method(NULL, "\\GFRS"))
>       > +               return huawei_acpi_fn_lock_get(on);
> 
>       Wouldn't it be better to put this behavior behind a quirk instead
>       of enforcing it on the whole module? Keep in mind that this is
>       also used by Honor devices that have the same WMI method.
> 
>       > +
>       > +       /* Legacy WMI fallback */
>       >         err = huawei_wmi_cmd(FN_LOCK_GET, ret, 0x100);
>       >         if (err)
>       >                 return err;
>       > @@ -550,6 +640,11 @@ static int huawei_wmi_fn_lock_set(int on)
>       >  {
>       >         union hwmi_arg arg;
>       >
>       > +       /* Newer models: use direct ACPI \SFRS method */
>       > +       if (acpi_has_method(NULL, "\\SFRS"))
>       > +               return huawei_acpi_fn_lock_set(on);
>       > +
>       > +       /* Legacy WMI fallback */
>       >         arg.cmd = FN_LOCK_SET;
>       >         arg.args[2] = on + 1; // 0 undefined, 1 off, 2 on.
>       >
>       > --
>       > 2.54.0
>       >
> 
> 
>