ideapad_laptop disables WiFi/BT radios on Lenovo Y530

[TJ]

I've been working with a user that has a Lenovo Legion Y530-15ICH where booting Ubuntu 18.10 (kernel 4.18.0-8) results in the radios being disabled by the platform driver "ideapad-laptop".

Unloading or blacklisting the module solves the issue but disables other platform ACPI interfaces:

$ sudo tee /etc/modprobe.d/ideapad.conf <<< "blacklist ideapad_laptop"

The system has the most recent firmware:

[ 0.000000] DMI: LENOVO 81FV/LNVNB161216, BIOS 8JCN44WW 08/13/2018

The wifi device is:

00:14.3 Network controller [0280]: Intel Corporation Wireless-AC 9560 [Jefferson Peak] [8086:a370] (rev 10)
 Subsystem: Intel Corporation Wireless-AC 9560 [Jefferson Peak] [8086:0034]
 Kernel driver in use: iwlwifi

We investigated the issue extensively and built the module with additional logic without solving the issue. It is well-known that some Lenovo models do not have a separate hardware radio kill switch (this model uses hot-keys Fn + F7 for 'Airplane mode') and need to use a DMI match to disable the rfkill logic.

We used dmidecode to get the correct Version string:

Handle 0x0001, DMI type 1, 27 bytes
System Information
 Manufacturer: LENOVO
 Product Name: 81FV
 Version: Lenovo Legion Y530-15ICH
 Serial Number: PF18CD10
 UUID: A44F71C1-5E3D-11E8-9379-8C16458E3F9D
 Wake-up Type: Power Switch
 SKU Number: LENOVO_MT_81FV_BU_idea_FM_Legion Y530-15ICH
 Family: Legion Y530-15ICH

and added it to no_hw_rfkill_list[]:

    {
        .ident = "Lenovo Legion Y530-15ICH",
        .matches = {
            DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
            DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo Legion Y530-15ICH"),
        },
    },

However, rfkill was still listing the platform devices "ideapad_wlan" and "ideapad_bluetooth":

0: ideapad_wlan: Wireless LAN
 Soft blocked: no
 Hard blocked: yes
1: ideapad_bluetooth: Bluetooth
 Soft blocked: yes
 Hard blocked: yes
3: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
4: hci0: Bluetooth
 Soft blocked: yes
 Hard blocked: no

/sys/class/rfkill/rfkill0/hard=1
/sys/class/rfkill/rfkill0/index=0
/sys/class/rfkill/rfkill0/name=ideapad_wlan
/sys/class/rfkill/rfkill0/persistent=1
/sys/class/rfkill/rfkill0/soft=0
/sys/class/rfkill/rfkill0/state=2
/sys/class/rfkill/rfkill0/type=wlan
/sys/class/rfkill/rfkill0/uevent=RFKILL_NAME=ideapad_wlan RFKILL_TYPE=wlan RFKILL_STATE=2
/sys/class/rfkill/rfkill1/hard=1
/sys/class/rfkill/rfkill1/index=1
/sys/class/rfkill/rfkill1/name=ideapad_bluetooth
/sys/class/rfkill/rfkill1/persistent=1
/sys/class/rfkill/rfkill1/soft=1
/sys/class/rfkill/rfkill1/state=2
/sys/class/rfkill/rfkill1/type=bluetooth
/sys/class/rfkill/rfkill1/uevent=RFKILL_NAME=ideapad_bluetooth RFKILL_TYPE=bluetooth RFKILL_STATE=2
/sys/class/rfkill/rfkill3/hard=0
/sys/class/rfkill/rfkill3/index=3
/sys/class/rfkill/rfkill3/name=phy0
/sys/class/rfkill/rfkill3/persistent=0
/sys/class/rfkill/rfkill3/soft=0
/sys/class/rfkill/rfkill3/state=1
/sys/class/rfkill/rfkill3/type=wlan
/sys/class/rfkill/rfkill3/uevent=RFKILL_NAME=phy0 RFKILL_TYPE=wlan RFKILL_STATE=1
/sys/class/rfkill/rfkill4/hard=0
/sys/class/rfkill/rfkill4/index=4
/sys/class/rfkill/rfkill4/name=hci0
/sys/class/rfkill/rfkill4/persistent=0
/sys/class/rfkill/rfkill4/soft=1
/sys/class/rfkill/rfkill4/state=0
/sys/class/rfkill/rfkill4/type=bluetooth
/sys/class/rfkill/rfkill4/uevent=RFKILL_NAME=hci0 RFKILL_TYPE=bluetooth RFKILL_STATE=0

We then added printk(KERN_NOTICE ... in the module's platform_driver.probe function ideapad_acpi_add() both at entry and later to report the DMI and status of the hardware switch control flag:

diff -u /home/all/SourceCode/linux/linux/drivers/platform/x86/ideapad-laptop.c ./ideapad-laptop.c
--- /home/all/SourceCode/linux/linux/drivers/platform/x86/ideapad-laptop.c 2018-10-14 01:46:49.506088219 +0100
+++ ./ideapad-laptop.c 2018-10-14 06:19:48.843813865 +0100
@@ -1147,6 +1147,13 @@
                },
        },
        {
+ .ident = "Lenovo Legion Y530-15ICH",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo Legion Y530-15ICH"),
+ },
+ },
+ {
                .ident = "Lenovo Legion Y720-15IKB",
                .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
@@ -1239,6 +1246,7 @@
        int cfg;
        struct ideapad_private *priv;
        struct acpi_device *adev;
+ const char *dmi_vendor, *dmi_version;

        ret = acpi_bus_get_device(ACPI_HANDLE(&pdev->dev), &adev);
        if (ret)
@@ -1257,6 +1265,10 @@
        priv->platform_device = pdev;
        priv->has_hw_rfkill_switch = !dmi_check_system(no_hw_rfkill_list);

+ dmi_vendor = dmi_get_system_info(DMI_SYS_VENDOR);
+ dmi_version = dmi_get_system_info(DMI_PRODUCT_VERSION);
+ printk(KERN_NOTICE "DMI: %s, %s. has_hw_rfkill_switch=%d\n", dmi_vendor, dmi_version, priv->has_hw_rfkill_switch);
+
        ret = ideapad_sysfs_init(priv);
        if (ret)
                return ret;

And this revealed that the function is not being called - the KERN_NOTICE messages do not appear in 'dmesg' output.

This suggests:

static const struct acpi_device_id ideapad_device_ids[] = {
    { "VPC2004", 0},

is not being matched via platform_driver.driver.acpi_match_table = ACPI_PTR(ideapad_device_ids),

We then decompiled the ACPI DSDT and confirmed that _HID is being set to VPC2004:

grep -C4 VPC2004 dsdt.dsl
            Scope (\_SB.PCI0.LPCB.EC0)
            {
                Device (VPC0)
                {
                    Name (_HID, "VPC2004") // _HID: Hardware ID
                    Name (_UID, Zero) // _UID: Unique ID
                    Name (_VPC, 0xFC0DF516)
                    Name (VPCD, Zero)
                    Method (_STA, 0, NotSerialized) // _STA: Status

At this point we're not sure what the next step should be. Wifi works correctly with the module blacklisted but it would be good to fix this properly.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1797772

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.19 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19-rc8

[TJ (tj)]

It was a clean install of 18.10. The mainline module doesn't have support for this device as yet. Since the blacklist the user has gone quite so additional testing is not possible

[Anthony Wong (anthonywong)]

Hi TJ, do you still have the machine? Can it be fixed with the similar approach as you did in bug 1811815?

[forevertheuni (forevertheuni)]

I have the same problem in lenovo y540, can you help me get it working there? I lose the acpi from this module :(

[forevertheuni (forevertheuni)]

I solved it in my Y540 by compiling a new ideapad_laptop with dkms adding "legion Y54015IRH" to the no_hw_rfkill_list.

This post and bug 1811815 helped me quite a bit, so, thank you.

[forevertheuni (forevertheuni)]

By the way. I went to linux kernel 5.2.1 ideapad_laptop.c and now there's no no_hw_rfkill_list. It's the opposite, now it has to be specified if there is a hw-rfkill. So that new laptops don't get this problem.

One option is to install a ppa with a recent kernel.

From the file:
* Some ideapads have a hardware rfkill switch, but most do not have one.
 * Reading VPCCMD_R_RF always results in 0 on models without a hardware rfkill,
 * switch causing ideapad_laptop to wrongly report all radios as hw-blocked.
 * There used to be a long list of DMI ids for models without a hw rfkill
 * switch here, but that resulted in playing whack a mole.
 * More importantly wrongly reporting the wifi radio as hw-blocked, results in
 * non working wifi. Whereas not reporting it hw-blocked, when it actually is
 * hw-blocked results in an empty SSID list, which is a much more benign
 * failure mode.
 * So the default now is the much safer option of assuming there is no
 * hardware rfkill switch. This default also actually matches most hardware,
 * since having a hw rfkill switch is quite rare on modern hardware, so this
 * also leads to a much shorter list.
 */

[Kai-Heng Feng (kaihengfeng)]

forevertheuni,
Please try https://people.canonical.com/~khfeng/lp1833630/

[Chris Kuethe (ckuethe)]

Also happens on the c930

Uname: Linux yoga 5.0.0-23-generic #24-Ubuntu SMP Mon Jul 29 15:36:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

From dmidecode:

System Information
 Manufacturer: LENOVO
 Product Name: 81C4
 Version: Lenovo YOGA C930-13IKB

BIOS Information
 Vendor: LENOVO
 Version: 8GCN32WW
 Release Date: 10/09/2018

From lshw:
          *-network
                description: Wireless interface
                product: Wireless-AC 9260
                vendor: Intel Corporation
                physical id: 0
                bus info: pci@0000:6b:00.0
                logical name: wlp107s0
                version: 29
                serial: 7a:a5:3b:xx:xx:xx
                width: 64 bits
                clock: 33MHz
                capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical wireless
                configuration: broadcast=yes driver=iwlwifi driverversion=5.0.0-23-generic firmware=43.95eb4e97.0 ip=192.168.1.67 latency=0 link=yes multicast=yes wireless=IEEE 802.11
                resources: irq:16 memory:6e200000-6e203fff

Because I have secure boot enabled, the patch in #8 doesn't boot on my machine