Bug 14775

Summary: thinkpad-acpi: rfkill persistency across hibernate doesn't work
Product: Drivers Reporter: Josip Rodin (joy+kernel)
Component: PlatformAssignee: Henrique de Moraes Holschuh (hmh)
Status: CLOSED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: hmh, lenb, rjw, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.32 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 7216, 13615, 56331    
Attachments: thinkpad-acpi: preserve rfkill state across suspend

Description Josip Rodin 2009-12-09 15:28:40 UTC
Hi,

I have an integrated wireless setup inside my Lenovo Thinkpad T400 which
normally works fine and provides WiFi, Bluetooth and WWAN connectivity.
The wifi card is utilized by the iwlagn driver, and WWAN modem as well
as Bluetooth appears separate devices, both managed by thinkpad_acpi. There's a single physical rfkill switch on the laptop.

I upgraded from 2.6.28.10 to 2.6.30 and that went well as far as iwlagn
was concerned, however, I started noticing that the WWAN device occasionally completely disappears.

After some discussions with Henrique de Moraes Holschuh on ibm-acpi* lists, it became apparent that the driver does something to manage the state of the availability these two devices. This is visible from userspace via:
/sys/devices/platform/thinkpad_acpi/wwan_enable
/sys/devices/platform/thinkpad_acpi/rfkill/rfkill1/*
and
/sys/devices/platform/thinkpad_acpi/bluetooth_enable
/sys/devices/platform/thinkpad_acpi/rfkill/rfkill0/*

At first I couldn't pinpoint the exact state change that fails me, but since upgrading to 2.6.32 and re-testing, I've confirmed that a normal reboot restores
the values to the setting of "enabled", whereas a hibernation sequence forces the values to "disabled". All the while BIOS setting remains intact - the device is enabled in it.

That looks to be according to drivers/platform/x86/thinkpad_acpi.c terminology: 

        TP_ACPI_WGSV_STATE_WWANEXIST    = 0x0001, /* WWAN hw available */
        TP_ACPI_WGSV_STATE_WWANPWR      = 0x0002, /* WWAN radio enabled */
        TP_ACPI_WGSV_STATE_WWANPWRRES   = 0x0004, /* WWAN state at resume */
        TP_ACPI_WGSV_STATE_WWANBIOSOFF  = 0x0008, /* WWAN disabled in BIOS */
        TP_ACPI_WGSV_STATE_BLTHEXIST    = 0x0001, /* BLTH hw available */
        TP_ACPI_WGSV_STATE_BLTHPWR      = 0x0002, /* BLTH radio enabled */
        TP_ACPI_WGSV_STATE_BLTHPWRRES   = 0x0004, /* BLTH state at resume */
        TP_ACPI_WGSV_STATE_BLTHBIOSOFF  = 0x0008, /* BLTH disabled in BIOS */

After the resume from hibernation I'm getting the sysctl settings in state 0, which is what disables the hardware.

This also has another annoying side-effect - I can't hibernate Linux and boot to Windows - there's nothing there that is able to enable the device again :)

If you need more information, don't hesitate to let me know.

Please fix it. TIA.
Comment 1 Henrique de Moraes Holschuh 2009-12-09 16:44:29 UTC
Known bug, although it might be less than straigthforward to fix.

The first approximation to fix it is to kill a driver bug where it expects the rfkill core to reset its state (doesn't happen to persistent devices, bug introduced in 2.6.31).

This *effectively* tells the firmware to do whatever it wants to the WWAN and bluetooth state, and the effect is unknown on UWB.

Please test and report back what happens on STR and STD, reboot and shutdown, for all radios you happen to have (bluetooth, WWAN, UWB).

I will attach the patch for convenience.
Comment 2 Henrique de Moraes Holschuh 2009-12-09 16:45:35 UTC
Created attachment 24120 [details]
thinkpad-acpi: preserve rfkill state across suspend

Already submitted upstream (linux-acpi/acpi-test).
Comment 3 Josip Rodin 2009-12-09 20:46:47 UTC
Yes, that's it, that definitely makes it not force it to off across suspend-to-disk. WWAN and Bluetooth lights just keep working as they did before, and Windows seems unaffected. No idea what's UWB...?

I don't use suspend-to-RAM under Linux so I have no reference point for that.
(I tried it now and it hosed my system so that's even worse, but probably irrelevant :)
Comment 4 Zhang Rui 2009-12-15 02:19:28 UTC
henrique,
what's the status of this bug?
can we close it?
Comment 5 Len Brown 2009-12-22 02:40:46 UTC
commit 208b996b6c460285650d39b2330f8ef82c007d10
Author: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Date:   Wed Dec 9 01:36:22 2009 +0000

    thinkpad-acpi: preserve rfkill state across suspend/resume

shipped in 2.6.33-rc1
closed