[PATCH v3 0/3] platform/x86: fix fn-lock on ASUS ProArt P16 (WMI DEVS no-op)

["Marcus Grenängen" <marcus@grenangen.se>]

Changes since v2 (addressing Denis's and Randy's review):

Patch 1 (HID: asus):
 - Renamed asus_hid_fnlock_notify() to asus_hid_fnlock_set() (Denis)
 - Replaced "if (ret > 0) ret = 0" with "if (ret < 0) return ret; return 0;"
   pattern (Denis)
 - Fixed Returns tag format to "Returns:" (Randy)
 - Added #if IS_REACHABLE(CONFIG_HID_ASUS) guard for asus_hid_fnlock_set()
   declaration in asus-wmi.h so asus-wmi.c can call it without a missing
   prototype warning

Patch 2 (asus-nb-wmi):
 - Added asus_wmi_fnlock_use_hid() export so asus-armoury can query the
   quirk flag without reading the quirk struct directly, keeping DMI and
   quirk knowledge inside asus-wmi (Denis)
 - Fixed Returns tag format to "Returns:" (Randy)

Patch 3 (asus-armoury):
 - Replaced the stored fnlock_use_hid flag and dmi_match() call with
   asus_wmi_fnlock_use_hid(), routing the DMI/quirk check through asus-wmi
   as Denis suggested
 - Added fn_lock_registered bool to properly guard sysfs_remove_group in
   both the error unwind path and __exit, mirroring the gpu_mux/mini_led
   pattern (Denis)
 - NOTE/Question: Since we have proper fn+esc hardware key handling working 
   now we could eliminate this patch completely if we don't care about 
   being able to control the fn state from user space 
   eg. asusctl and/or rog control center?
   The nice thing of having it controllable via asusctl is the
   scripting possibilibilities like setting prefered mode when 
   starting a DE as one example.

Regarding the if/else dispatch in fn_lock_current_value_store: Denis
suggested routing everything through a single asus_wmi_fnlock_set()
exported from asus-wmi. This was implemented but had to be reverted: it
introduced a module dependency cycle (hid_asus -> asus_wmi -> hid_asus)
that depmod detects and rejects. asus-armoury therefore retains the
if/else, calling asus_hid_fnlock_set() on HID-path platforms and
armoury_set_devstate() on WMI-path platforms. The asus-armoury -> hid-asus
dependency is a soft one (the stub in asus-wmi.h returns -ENODEV when
CONFIG_HID_ASUS is not reachable). But since I'm new to this maybe I'm 
missing something critical here?

Marcus Grenängen (3):
  HID: asus: export asus_hid_fnlock_set() for direct fn-lock control
  platform/x86: asus-nb-wmi: add fnlock_use_hid quirk and asus_wmi_fnlock_use_hid()
  platform/x86: asus-armoury: add fn_lock firmware attribute

 drivers/hid/hid-asus.c                     | 44 ++++++++++++++++++-
 drivers/platform/x86/asus-armoury.c        | 70 ++++++++++++++++++++++++++++++
 drivers/platform/x86/asus-nb-wmi.c         | 13 ++++++
 drivers/platform/x86/asus-wmi.c            | 22 ++++++++++
 drivers/platform/x86/asus-wmi.h            |  5 +++
 include/linux/platform_data/x86/asus-wmi.h | 15 +++++++
 6 files changed, 168 insertions(+), 1 deletion(-)

-- 
2.54.0