mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: xiazq123666@gmail.com, "Hans de Goede" <hansg@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Guenter Roeck" <linux@roeck-us.net>
Cc: platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org
Subject: Re: [PATCH RFC 0/2] platform/x86: Add Emdoor Intel EWMI platform driver
Date: Fri, 13 Nov 2026 21:37:44 +0100	[thread overview]
Message-ID: <739e089d-fab1-4ade-9373-fe4c5b3924ad@gmx.de> (raw)
In-Reply-To: <20261113-emdoor-intel-wmi-rfc-v1-0-d77ecf23693b@gmail.com>

Am 13.11.26 um 19:01 schrieb Ziqiang Xia via B4 Relay:
> This RFC patch series adds initial Linux support for the Intel EWMI
> (\_SB.EWMI) WMI interface found on Emdoor-based Intel laptops, initially
> matched strictly by DMI and BIOS version to the MECHREVO Wujie 14 2026
> (WUJIE Series-Lark4-LNL, Intel Core Ultra 5 226V Lunar Lake, BIOS
> EM_LNL326_V1.0.19).
> 
> Note on naming and scope:
> - Community out-of-tree projects such as fewtarius/emdoor-wmi target AMD
>    Emdoor platforms using different WMI GUIDs (8600ACCE-...) and AMD SMU
>    ports. This Intel EWMI implementation (0B30FD67-1B62-4FCA-B10B-50DC7ADE6A39,
>    0B30FD67-1B62-4FCA-B10B-50DC7ADE6DDD, C75665A3-4382-4646-ADC8-C81AE146E455)
>    is unrelated in protocol and EC register layout, so the driver is named
>    emdoor-intel-wmi.
> - Legacy WMAA-WMCA WMI methods on this DSDT trigger AE_AML_BUFFER_LIMIT due
>    to an out-of-bounds CreateField() and are deliberately unused. The driver
>    only uses the clean WMCD, _WED(0xD0), and WMCC interfaces through modern
>    wmi_driver / wmidev_invoke_method().

Interesting.

IMHO using direct EC addresses will eventually turn into a 
maintainability nightmare. I am aware of the issue with CreateField(), 
AFAIK you can workaround this issue by simply submitting an oversized 
buffer to wmidev_invoke_method().

Can you share the output of acpidump please?

Thanks,
Armin Wolf

> 
> Hardware quirks handled and verified on real hardware:
> 1. Shared EC5D mailbox lag and hotkey collision:
>     AML methods GWLS (0x03/01) and GFLS (0x03/03) time out after 20 ms on
>     this BIOS and return the previous mailbox byte on the call itself. After
>     invoking WMCD and waiting 100 ms, the driver reads the settled mailbox
>     register directly and retries up to 3 times if concurrent _QF6/_QF9
>     hotkey events overwrite EC5D in flight.
> 2. SPFM stale-EC5F drop race:
>     AML method SPFM (0x03/0a) arms ZZTT/TIZZ before Notify(IETM, 0x88) and
>     before writing EC5F, so an EC scan during the notify can consume a stale
>     EC5F and return RTNC=0 without updating PPMD (or return RTNC=1). The
>     driver verifies 03/09 readback and reissues the absolute mode up to 3 times.
> 
> Validation summary on Linux 7.3.4 (MECHREVO WUJIE Series-Lark4-LNL,
> EM_LNL326_V1.0.19):
> - 1500 readonly attribute/hwmon stress reads (battery & AC online): 0 errors
> - 20 platform_profile switches + 40 idempotent writes: 0 errors
> - Fn-lock, Win-lock, and auto_power_on write/readback cycles: pass
> - High-frequency Fn+Esc / F8 hotkey concurrency stress & s2idle: pass
> 
> Specific RFC questions for reviewers:
> 1. Should fn_lock, win_lock, and auto_power_on stay as WMI device sysfs
>     attributes (documented in Patch 1), or would pdx86 maintainers prefer a
>     firmware-attributes class interface or moving any of them?
> 2. Event codes 0xA1 (F7 mic-mute hotkey, _QF8) and 0xA2 (Fn+R refresh rate,
>     _QF5) are conservatively mapped to KEY_PROG2 / KEY_PROG3 for now while
>     verifying whether i8042 also emits scancodes on some desktops/DEs. Is
>     KEY_MICMUTE / KEY_REFRESH_RATE_TOGGLE preferred once verified, or
>     separate input mapping?
> 3. Exact DMI_BIOS_VERSION matching is used because board EC offsets (0x5d,
>     0xf5, temp_regs {0x70, 0x73, 0x72, 0x62}) are board/BIOS-specific. Is
>     this strict match appropriate for initial upstreaming?
> 
> Signed-off-by: Ziqiang Xia <xiazq123666@gmail.com>
> ---
> Ziqiang Xia (2):
>        Documentation: ABI: testing: Add emdoor-intel-wmi sysfs ABI
>        platform/x86: Add Emdoor Intel EWMI platform driver
> 
>   .../ABI/testing/sysfs-bus-wmi-devices-emdoor-ewmi  |  28 +
>   MAINTAINERS                                        |   7 +
>   drivers/platform/x86/Kconfig                       |  18 +
>   drivers/platform/x86/Makefile                      |   1 +
>   drivers/platform/x86/emdoor-intel-wmi.c            | 873 +++++++++++++++++++++
>   5 files changed, 927 insertions(+)
> ---
> base-commit: 5680519168f65666d2c03cc6ed8fe2b7052aee12
> change-id: 20261113-emdoor-intel-wmi-rfc-2173530b3df6
> 
> Best regards,
> --
> Ziqiang Xia <xiazq123666@gmail.com>
> 
> 


  parent reply	other threads:[~2026-11-13 20:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 18:01 Ziqiang Xia via B4 Relay
2026-11-13 18:01 ` [PATCH RFC 1/2] Documentation: ABI: testing: Add emdoor-intel-wmi sysfs ABI Ziqiang Xia via B4 Relay
2026-11-13 18:01 ` [PATCH RFC 2/2] platform/x86: Add Emdoor Intel EWMI platform driver Ziqiang Xia via B4 Relay
2026-11-13 20:37 ` Armin Wolf [this message]
2026-11-14  3:30   ` [PATCH RFC 0/2] " Ziqiang Xia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=739e089d-fab1-4ade-9373-fe4c5b3924ad@gmx.de \
    --to=w_armin@gmx.de \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=xiazq123666@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®