Re: [PATCH] platform/x86: ideapad-laptop: add no_rfkill quirk for IdeaPad Slim 3 16IRH10

[qvkap]

Thanks for the feedback and clarification regarding the DCO and
submission process.

I have updated the patch to use my full real name (Ivan Vasilchenko)
in Signed-off-by, removed the external GitHub link, and prepared a
proper inline v2 patch below.

Regarding Mark's comment: I agree that modern IdeaPads/ThinkPads no
longer need ACPI rfkill and that a broader solution (or module
parameter) would be great long-term. Meanwhile, this quirk completely
resolves the erratic Wi-Fi/BT disconnects on this platform.

Please find the v2 patch below.

---
From: Ivan Vasilchenko <qvkapp@xxxxxxxxx>
Subject: [PATCH v2] platform/x86: ideapad-laptop: add no_rfkill quirk
for IdeaPad Slim 3 16IRH10

On Lenovo IdeaPad Slim 3 16IRH10 (83K2), the EC/ACPI firmware reports erratic
rfkill radio states through VPCCMD_R_WIFI and VPCCMD_R_RF, causing periodic
soft/hard blocks of the native Wi-Fi/Bluetooth interfaces (iwlwifi) without
any physical switch or user interaction.

Add a no_rfkill quirk and register IdeaPad Slim 3 16IRH10 (83K2) into the
no_rfkill_dmi_table to bypass ACPI rfkill device registration and let the
native wireless driver handle radio state management.

Tested and confirmed working on live hardware.

Signed-off-by: Ivan Vasilchenko <qvkapp@xxxxxxxxx>
---
 drivers/platform/x86/ideapad-laptop.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 2c9e78a609d8..e393a525da5f 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -148,6 +148,7 @@ struct ideapad_private {
  } fn_keys;
  struct {
  bool set_fn_lock_led;
+ bool no_rfkill;
  } features;
  struct {
  bool initialized;
@@ -1245,6 +1246,9 @@ static int ideapad_register_rfkill(struct
ideapad_private *priv, int dev)
 {
  int ret;

+ if (priv->features.no_rfkill)
+ return 0;
+
  if (!ideapad_is_rfkill_hw_present(priv, dev))
  return -ENODEV;

@@ -1588,6 +1592,15 @@ static const struct dmi_system_id
set_fn_lock_led_list[] = {
  {}
 };

+static const struct dmi_system_id no_rfkill_dmi_table[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Slim 3 16IRH10"),
+ },
+ },
+ {}
+};
+
 static void ideapad_check_features(struct ideapad_private *priv)
 {
  acpi_handle handle = priv->adev->handle;
@@ -1596,6 +1609,9 @@ static void ideapad_check_features(struct
ideapad_private *priv)
  if (dmi_check_system(set_fn_lock_led_list))
  priv->features.set_fn_lock_led = true;

+ if (dmi_check_system(no_rfkill_dmi_table))
+ priv->features.no_rfkill = true;
+
  if (acpi_has_method(handle, "GBMD") && acpi_has_method(handle, "SBMC"))
  priv->features.conservation_mode = true;


--
2.45.2

вт, 10 нояб. 2026 г. в 04:06, Mark Pearson <mpearson-lenovo@xxxxxxxxx>:
>
> Hi,
>
> On Mon, Nov 9, 2026, at 12:02 PM, qvkap wrote:
> > Hi Hans, Mark, Ilpo,
> >
> > On newer IdeaPad models such as the IdeaPad Slim 3 16IRH10 (83K2), the
> > EC/ACPI firmware reports erratic rfkill radio states through
> > VPCCMD_R_WIFI / VPCCMD_R_RF, causing periodic soft/hard blocks of the
> > native Wi-Fi/Bluetooth interfaces (iwlwifi) without any user
> > interaction or physical hardware switch.
> >
> > This patch introduces a no_rfkill quirk and adds IdeaPad Slim 3
> > 16IRH10 to skip registering defective ACPI rfkill devices. Tested and
> > confirmed working on live hardware.
> >
> > GitHub: https://github.com/qvkap/ideapad-slim3-rfkill-patch
> > Raw Patch:
> > https://raw.githubusercontent.com/qvkap/ideapad-slim3-rfkill-patch/master/0001-platform-x86-ideapad-laptop-add-no_rfkill-quirk-for-.patch
> >
> > Signed-off-by: qvkap <qvkapp@xxxxxxxxx>
>
> I assume posting a link to a patch is not going to be acceptable (I almost didn't bother looking at this one because of that because I'm behind on my overflowing inbox) but I'll let the experienced maintainers comment on that.
>
> I've been looking at a similar issue on Thinkpad's but have been trying to gather data on which platforms are impacted. We're finding the same thing there where the kill is powering down the device and it's never recovering - and we've been fixing FW for the last 3 years to make the APCI method a no-op where it has caused problems. Recently the FW team complained as the ACPI method is used for debug testing...so trying to find a better long term solution.
>
> I'm not a fan of the DMI approach as I don't think it's going to scale well - it means every new platform is (likely) going to need to be added; which is going to get really tedious fast.
> I don't think it's really a FW issue and more a fact that device drivers have caught up and the ACPI rfkill is no longer needed - but I'm guessing a bit. For Thinkpad I did get confirmation that it's not used on Windows FWIW.
>
> I have a patch that is almost the opposite - I was going to disable the rfkill mechanism unless a module parameter specifically enabled it.
> My logic is maybe some older models will need it - but so far in my testing newer (5 years or less) seem fine. I've been unable to determine the cut-off so far.
>
> If anybody on the list has opinions let me know. Gathering data on the impact is taking time (sadly in short supply)
>
> Mark
>