Bug 43007

Summary: 461e74377cfcfc2c0d6bbdfa8fc5fbc21b052c2a that supposedly fixes phantom rfkill on ideapad breaks it on mine
Product: Platform Specific/Hardware Reporter: Andras Korn (korn-kernel.org)
Component: i386Assignee: platform_i386
Status: NEW ---    
Severity: normal CC: colin.newell, florian, ikepanhc, ivo, jlee
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.3 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: output of rfkill list with lobotomised acer-wmi fix
dmesg with 3.2.0-1-grml-amd64 kernel
dmesg with 3.3, lobotomised acer-wmi fix
rfkill with 3.3 vanilla
Effects of blacklisting acer-wmi in 3.0.2, soft and hard switches, then loading acer-wmi and toggling switches again.
0001-acer-wmi-support-Lenovo-ideapad-S205-Brazos-wifi-sw.patch
for ideapad s205 (Inagua)
Patch by Ike Panhc to read EC register 0xA on Ideapad 10382JG during initialisation
Patch by Ike Panhc to read EC register 0xA on Ideapad 10382JG during initialisation
acpidump output
dmidecode output
0001-acer-wmi-support-Lenovo-ideapad-S205-10382JG-wifi-sw.patch
0001-acer-wmi-support-Lenovo-ideapad-S205-1038DPG-wifi-s.patch

Description Andras Korn 2012-03-28 18:22:06 UTC
Hi,

I have a Lenovo IdeaPad s205.

If I boot recent kernels, wifi is disabled; rfkill shows it as "hardware blocked" whether I load the acer-wmi module or not.

On earlier kernels (grml's flavour of 3.2.0 verified), loading the acer-wmi module unblocks the phantom rfkill switch (it doesn't actually exist).

I tried lobotomising the acer-wmi patch (https://lkml.org/lkml/2012/3/16/601) in 3.3 by making acpi_device_id norfkill_ids empty, and voila, wifi works again on my ideapad. So apparently this patch, the one that fixes this same issue for many others, is the one that breaks wifi for me.

Hardware info (from dmesg):

DMI: LENOVO 1038D3G/Inagua, BIOS 4BCN21WW 05/23/2011

(dmidecode doesn't work, likely due to UEFI.)

Interesting-looking entries from /sys/bus/acpi/devices:

ACPI0003:00@
LNXCPU:00@
LNXCPU:01@
LNXCPU:02@
LNXCPU:03@
LNXPWRBN:00@
LNXSYSTM:00@
LNXTHERM:00@
LNXTHERM:01@
LNXVIDEO:00@
LNXVIDEO:01@
SYN0321:00@
VPC2004:00@

Andras
Comment 1 Andras Korn 2012-03-28 18:22:56 UTC
(I run an amd64 kernel; I just assume the issue manifests on i386 as well.)
Comment 2 Ike Panhc 2012-03-30 08:04:56 UTC
Could you please attach the output of `rfkill list` and `dmesg`?

Thanks a lot
Comment 3 Andras Korn 2012-03-30 08:27:27 UTC
Created attachment 72749 [details]
output of rfkill list with lobotomised acer-wmi fix

Bluetooth is really soft blocked (I turned it off in Gnome).

acer-wireless is likely a phantom device.

phy0 is what ends up bogus "hard blocked" if I don't lobotomise the patch.
Comment 4 Andras Korn 2012-03-30 08:28:56 UTC
Created attachment 72750 [details]
dmesg with 3.2.0-1-grml-amd64 kernel

This kernel doesn't have the acer-wmi fix yet. Wifi works with it.
Comment 5 Andras Korn 2012-03-30 08:32:16 UTC
Created attachment 72751 [details]
dmesg with 3.3, lobotomised acer-wmi fix

Wifi works with this kernel after acer-wmi is loaded.
Comment 6 Andras Korn 2012-03-30 08:33:15 UTC
I'll collect rfkill list and dmesg output from non-working setups later today.
Comment 7 Andras Korn 2012-03-30 14:07:16 UTC
Created attachment 72763 [details]
rfkill with 3.3 vanilla

This is what happens with the 3.3 "fixed" acer-wmi module.

In the last experiment, I load my lobotomised acer-wmi module instead of the vanilla one into the same kernel, and wifi immediately starts working.

I suppose the exception list needs to be made more specific somehow...?
Comment 8 Andras Korn 2012-03-30 14:12:25 UTC
For the sake of clarity, this is how I modified the acer-wmi module in 3.3 to make it work:

--- 3.3/drivers/platform/x86/acer-wmi.c  2012-03-19 00:15:34.000000000 +0100
+++ 3.3/drivers/platform/x86/acer-wmi.c.mine     2012-03-30 16:11:05.037741000 +0200
@@ -689,9 +689,6 @@
 }
 
 static const struct acpi_device_id norfkill_ids[] = {
-       { "VPC2004", 0},
-       { "IBM0068", 0},
-       { "LEN0068", 0},
        { "", 0},
 };
Comment 9 Ike Panhc 2012-04-11 08:50:53 UTC
The attachment in comment #7 is interested. Looks like register acer-wireless rfkill unblock phy0's hard block.

Can you help with two test?

1) With 3.3 vanilla kernel, please try to switch the physical wireless switch and see how `rfkill list` output change.
2) With 3.2 based kernel, please try to blacklist acer-wmi and see if the wireless works or not.

Thanks a lot.
Comment 10 Andras Korn 2012-04-11 08:55:54 UTC
(In reply to comment #9)

> 1) With 3.3 vanilla kernel, please try to switch the physical wireless switch
> and see how `rfkill list` output change.

It lists bluetooth as hard blocked, otherwise no change.

> 2) With 3.2 based kernel, please try to blacklist acer-wmi and see if the
> wireless works or not.

I think it doesn't, but I'll try.
Comment 11 Ike Panhc 2012-04-18 03:42:00 UTC
Hi, lets fall back to the traditional way.

Please download the acer_ec.pl[1] and run command with 3.3 vanilla kernel:

    sudo watch -n 1 perl acer_ec.pl regs

and push the Fn+F5 several times, try to find out which register tells us the *real* rfkill status.

[1] http://code.google.com/p/aceracpi/wiki/EmbeddedController

and please let me know the output of `cat /sys/class/dmi/id/board_vendor` and `cat /sys/class/dmi/id/product_name`

I will try to have an exception.

Thanks a lot.
Comment 12 Andras Korn 2012-04-18 09:28:50 UTC
(In reply to comment #11)

Hi,

> Please download the acer_ec.pl[1] and run command with 3.3 vanilla kernel:
> 
>     sudo watch -n 1 perl acer_ec.pl regs
> 
> and push the Fn+F5 several times, try to find out which register tells us the
> *real* rfkill status.

I'll do this. Meanwhile, I'm attaching the results of the experiment with 3.0.2. Summary: wifi doesn't work (appears hard blocked) until acer-wmi is loaded. After loading acer-wmi, both the hard and soft switches appear to function properly.

> and please let me know the output of `cat /sys/class/dmi/id/board_vendor` and
> `cat /sys/class/dmi/id/product_name`

/sys/class/dmi/id/bios_date:05/23/2011
/sys/class/dmi/id/bios_vendor:LENOVO
/sys/class/dmi/id/bios_version:4BCN21WW
/sys/class/dmi/id/board_asset_tag:Base Board Asset Tag Unknown
/sys/class/dmi/id/board_name:Inagua
/sys/class/dmi/id/board_serial:<redacted>
/sys/class/dmi/id/board_vendor:LENOVO
/sys/class/dmi/id/board_version:109-B78210-00A
/sys/class/dmi/id/chassis_asset_tag:Chassis Asset Tag Unknown
/sys/class/dmi/id/chassis_serial:Chassis Serial Number Unknown
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:LENOVO
/sys/class/dmi/id/chassis_version:Chassis Version Unknown
/sys/class/dmi/id/modalias:dmi:bvnLENOVO:bvr4BCN21WW:bd05/23/2011:svnLENOVO:pn1038D3G:pvrIdeapadS205:rvnLENOVO:rnInagua:rvr109-B7821 -00A:cvnLENOVO:ct10:cvrChassisVersionUnknown:
/sys/class/dmi/id/product_name:1038D3G
/sys/class/dmi/id/product_serial:<redacted>
/sys/class/dmi/id/product_uuid:B4B9ACE0-B2F1-11E0-AD9F-F2204BB03A53
/sys/class/dmi/id/product_version:Ideapad S205
/sys/class/dmi/id/sys_vendor:LENOVO
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnLENOVO:bvr4BCN21WW:bd05/23/2011:svnLENOVO:pn1038D3G:pvrIdeapadS205:rvnLENOVO:rnInagua:rvr10 -B78210-00A:cvnLENOVO:ct10:cvrChassisVersionUnknown:
Comment 13 Andras Korn 2012-04-18 09:30:08 UTC
Created attachment 72952 [details]
Effects of blacklisting acer-wmi in 3.0.2, soft and hard switches, then loading acer-wmi and toggling switches again.
Comment 14 Ike Panhc 2012-04-18 09:57:00 UTC
It appears that ec_read() also trigger something in ec firmware to unblock.

Please test with acer_ec.pl and in the mean time, I will generate the patch.
Comment 15 Andras Korn 2012-04-18 12:16:52 UTC
(In reply to comment #11)
> Hi, lets fall back to the traditional way.
> 
> Please download the acer_ec.pl[1] and run command with 3.3 vanilla kernel:
> 
>     sudo watch -n 1 perl acer_ec.pl regs
> 
> and push the Fn+F5 several times, try to find out which register tells us the
> *real* rfkill status.

I ran "watch -d -n 1 acer_ec.pl regs \; rfkill list" and this is what I found:

When wireless in unblocked, register 0x71's value is 131.

When I press fn+f5, the value changes to 130. Additionally, first phy0's "soft blocked" changes from "no" to "yes", then 2-3 seconds later "hard blocked" also changes from "no" to "yes".

Pressing fn+f5 again causes register 0x71 to revert to 131; "soft blocked" immediately changes to "no", and a few seconds later "hard blocked" also changes to "no".

Unfortunately, there are quite a few registers that keep changing frequently, which makes determining which ones change due to fn+f5 difficult.

Frequently changing registers are 0x72, 0x83, 0x8b, 0x94, 0x95, 0xa8, 0xa9 0xaa, 0xb8, 0xe0, 0xe4, 0xe6, 0xe8, 0xec, 0xed, possibly others.

The "soft blocked" state of "acer-wireless" sometimes changes seemingly at random (apparently it changes from "yes" to "no" once every few minutes, and then changes back to "yes" 1-2 seconds later).
Comment 16 Andras Korn 2012-04-18 14:00:45 UTC
With some further experimentation and scripting I came up with this:

Register 113 when soft blocked: no is 131
Register 113 when soft blocked: yes is 130
Register 149 when hard blocked: no is 132
Register 149 when hard blocked: yes is 127
Register 149 when hard blocked: yes is 128
Register 149 when hard blocked: yes is 130
Register 149 when soft blocked: no is 130
Register 149 when soft blocked: no is 132
Register 149 when soft blocked: yes is 127
Register 149 when soft blocked: yes is 128
Register 168 when hard blocked: no is 59
Register 168 when hard blocked: yes is 60
Register 224 when hard blocked: no is 54
Register 224 when hard blocked: no is 57
Register 224 when hard blocked: yes is 58
Register 224 when hard blocked: yes is 59
Register 224 when hard blocked: yes is 61
Register 224 when hard blocked: yes is 63
Register 224 when hard blocked: yes is 71
Register 224 when soft blocked: no is 54
Register 224 when soft blocked: no is 58
Register 224 when soft blocked: no is 61
Register 224 when soft blocked: no is 71
Register 224 when soft blocked: yes is 57
Register 224 when soft blocked: yes is 59
Register 224 when soft blocked: yes is 63
Register 230 when hard blocked: no is 117
Register 230 when hard blocked: no is 125
Register 230 when hard blocked: yes is 102
Register 230 when hard blocked: yes is 104
Register 230 when hard blocked: yes is 106
Register 230 when hard blocked: yes is 108
Register 230 when hard blocked: yes is 113
Register 230 when soft blocked: no is 102
Register 230 when soft blocked: no is 106
Register 230 when soft blocked: no is 113
Register 230 when soft blocked: no is 125
Register 230 when soft blocked: yes is 104
Register 230 when soft blocked: yes is 108
Register 230 when soft blocked: yes is 117
Register 232 when hard blocked: no is 247
Register 232 when hard blocked: yes is 228
Register 232 when hard blocked: yes is 24
Register 232 when hard blocked: yes is 245
Register 232 when hard blocked: yes is 30
Register 232 when soft blocked: no is 24
Register 232 when soft blocked: no is 245
Register 232 when soft blocked: no is 247
Register 232 when soft blocked: no is 30
Register 232 when soft blocked: yes is 228
Register 232 when soft blocked: yes is 29
Register 236 when hard blocked: no is 119
Register 236 when hard blocked: no is 91
Register 236 when hard blocked: yes is 104
Register 236 when hard blocked: yes is 136
Register 236 when hard blocked: yes is 139
Register 236 when hard blocked: yes is 142
Register 236 when hard blocked: yes is 87
Register 236 when soft blocked: no is 119
Register 236 when soft blocked: no is 136
Register 236 when soft blocked: no is 139
Register 236 when soft blocked: no is 87
Register 236 when soft blocked: yes is 104
Register 236 when soft blocked: yes is 142
Register 236 when soft blocked: yes is 91

Explanation: I wrote a script that recorded the value of all registers along with the state of the hard and soft blocking state of phy0. I toggled the blocks a few times, logging the register values. I then removed values that occurred in both blocked and unblocked states (because these apparently can't be used to differentiate between blocked and unblocked states). Finally, I removed values where a register now only had a single recorded value (i.e. there was a specific value that only occurred in the blocked or unblocked state, but no specific value that only occurred in the other state).

There was an anomaly with register 148 in that an empty value was recorded for it at least once, I don't know why. Its only remaining entry in the above list would read "Register 148 when hard blocked: yes is 127" (apparently this value did not occur with "hard blocked: no").

I hope this helps.
Comment 17 Lee, Chun-Yi 2012-04-19 04:19:17 UTC
Created attachment 72963 [details]
0001-acer-wmi-support-Lenovo-ideapad-S205-Brazos-wifi-sw.patch

Does this patch in 3.4-rc1 works to you?
Comment 18 Ike Panhc 2012-04-19 06:00:56 UTC
Created attachment 72970 [details]
for ideapad s205 (Inagua)

Hi Joey,

There are many SKUs all named ideapad s205. I believe this is not the one we heard.

I revised the patch and we need Andras to verify which one works, or neither.
Comment 19 Andras Korn 2012-04-19 13:42:37 UTC
(I will do that, but it takes time, sorry.)
Comment 20 Andras Korn 2012-04-28 05:22:42 UTC
(Progress: currently building 3.4-rc4 with Ike's patch. Will keep you posted.)
Comment 21 Andras Korn 2012-05-03 15:06:25 UTC
I tried both patches. Neither helped (rfkill listed phy0 as hard blocked with both).
Comment 22 Ivo Anjo 2012-05-03 20:43:18 UTC
I was the one that posted on launchpad
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/875659/comments/85
and was directed here.

A thing that I'm still confused about is why the focus is on fn+f5.
My S205 has two ways to control the wireless: a switch on the side, which supposedly would be the real hard killswitch, and only works for bluetooth -- but it does work (the hard block is toggled), and the fn+f5 which also correctly toggles the wlan soft block.

Both of these things I can see working with rfkill list.

Ok, as for the testing. I performed it using the latest mainline kernel from the kernel-ppa, 3.4-rc5-precise.

I looked at the output of acer_ec.pl while toggling fn+f5 and had no luck at all. There are some registers which change spuriously, but there is no register which clearly changes between two states when pressing the combo.

With the switch on the side, I had more luck: both 0x52 and 0x78 clearly change between toggles, 0 for "killswitch on (wifi off)", 1 for "killswitch off".
Comment 23 Ivo Anjo 2012-05-03 21:01:11 UTC
I forgot to include:

bios_date:08/10/2011
bios_vendor:LENOVO
bios_version:4BCN24WW
board_name:Inagua
board_vendor:LENOVO
board_version:109-B78210-00A
chassis_type:10
chassis_vendor:LENOVO
product_name:10382JG
product_version:Ideapad S205
sys_vendor:LENOVO

Andra's machine still seems to be using an older BIOS, but mine is not the "normal" 4BCN24WW bios, I had to replace it with a hacked version that removed the wireless card whitelist, so I could switch the internal card to an Intel Centrino Ultimate-N 6300.

Also I was checking rfkill with kernel 3.0, and the side killswitch correctly controls both the bluetooth and wifi hard blocks (and works correctly). This is after loading and rmmoding acer_wmi. With acer_wmi loaded I have another entry in the rfkill list, which seems to always be in this state:
4: acer-wireless: Wireless LAN
        Soft blocked: yes
        Hard blocked: no
Comment 24 Ike Panhc 2012-06-21 11:36:33 UTC
@Andras

Sorry for late. Could you try a patch please?
Comment 25 Ike Panhc 2012-06-21 11:41:53 UTC
Obviously I do not know how to attach a patch.

So I put it at http://people.canonical.com/~ikepanhc/lp/bugzilla.kernel/43007/
Comment 26 Andras Korn 2012-06-21 13:57:42 UTC
Created attachment 73911 [details]
Patch by Ike Panhc to read EC register 0xA on Ideapad 10382JG during initialisation
Comment 27 Andras Korn 2012-06-21 13:58:55 UTC
Created attachment 73921 [details]
Patch by Ike Panhc to read EC register 0xA on Ideapad 10382JG during initialisation
Comment 28 Andras Korn 2012-06-21 14:01:13 UTC
(In reply to comment #24)
> @Andras
> 
> Sorry for late. Could you try a patch please?

Yes, thank you, will do (but will take some days).

I attached the patch for you. :)
Comment 29 Andras Korn 2012-06-24 21:41:15 UTC
(In reply to comment #25)
> Obviously I do not know how to attach a patch.
> 
> So I put it at
> http://people.canonical.com/~ikepanhc/lp/bugzilla.kernel/43007/

Sorry, this patch doesn't help either. I applied it to 3.4.4; my phy0 is still "hard blocked".

My earlier workaround (mucking with acpi_device_id norfkill_ids) still resolves the problem for me (but would likey break wifi for others).
Comment 30 Ivo Anjo 2012-06-25 00:33:08 UTC
Same here, I applied the patch to ubuntu's 3.2 kernel tree, and the issue is still present.
Comment 31 Ivo Anjo 2012-07-08 13:47:29 UTC
Are there any news?
Is there some more testing that can be done?

Thanks.
Comment 32 Lee, Chun-Yi 2012-08-24 22:56:45 UTC
Hi Ivo, 

Obviously the 0xA EC register not work on your machine, we need try to grab which EC register works with you.

Please run this acer_ec.pl from Carlos:
http://code.google.com/p/aceracpi/wiki/EmbeddedController
http://aceracpi.googlecode.com/svn/trunk/acer_ec/acer_ec.pl

Simple use:
        watch -n 1 perl acer_ec.pl regs

Then press your wireless Fn key to monitor which register changed when
you press Fn key:

e.g. the register at row B0 and column 0A is register 0xBA (0x is used
to indicate this is a hexadecimal number).

There maybe have other EC register changing when you press key, please
do a couple of times and make sure you find out the right one.

If we are lucky, we can find out one EC register mapping to your
wireless state.
Comment 33 Ivo Anjo 2012-08-25 02:43:13 UTC
(In reply to comment #32)
> Hi Ivo, 
> 
> Obviously the 0xA EC register not work on your machine, we need try to grab
> which EC register works with you.
> 
> Please run this acer_ec.pl from Carlos:
> http://code.google.com/p/aceracpi/wiki/EmbeddedController
> http://aceracpi.googlecode.com/svn/trunk/acer_ec/acer_ec.pl
> 
> Simple use:
>         watch -n 1 perl acer_ec.pl regs
> 
> Then press your wireless Fn key to monitor which register changed when
> you press Fn key:
> 
> e.g. the register at row B0 and column 0A is register 0xBA (0x is used
> to indicate this is a hexadecimal number).
> 
> There maybe have other EC register changing when you press key, please
> do a couple of times and make sure you find out the right one.
> 
> If we are lucky, we can find out one EC register mapping to your
> wireless state.

As I've said before: I don't understand the focus on the fn key. The fn key works fine, it triggers the soft block, and it works (and I can't see it with acer_ec.pl). The issue is that current kernels ignore the hard killswitch key, which is on the side of the laptop, and read it as being always OFF.

For the side hard killswitch key, the EC registers 0x52 and 0x78 change whenever I toggle it, 0 for "killswitch on (wifi off)", 1 for "killswitch off".
Comment 34 Lee, Chun-Yi 2012-08-27 05:58:42 UTC
(In reply to comment #33)
> (In reply to comment #32)
...
> 
> As I've said before: I don't understand the focus on the fn key. The fn key
> works fine, it triggers the soft block, and it works (and I can't see it with
> acer_ec.pl). The issue is that current kernels ignore the hard killswitch
> key,
> which is on the side of the laptop, and read it as being always OFF.
> 
> For the side hard killswitch key, the EC registers 0x52 and 0x78 change
> whenever I toggle it, 0 for "killswitch on (wifi off)", 1 for "killswitch
> off".

Hi Ivo, 

Thanks for your information.

Due to there have 2 EC registers changed when you toggle the hardware switch. Please also help to attach the acpidump and dmidecode, I want to check the OperationRegion of EmbeddedControl. And, the dmidecode is for indicate this machine.

Thanks a lot!
Comment 35 Ivo Anjo 2012-08-27 18:47:20 UTC
Created attachment 78591 [details]
acpidump output
Comment 36 Ivo Anjo 2012-08-27 18:47:52 UTC
Created attachment 78601 [details]
dmidecode output
Comment 37 Ivo Anjo 2012-08-27 18:51:17 UTC
(In reply to comment #34)
> Hi Ivo, 
> 
> Thanks for your information.
> 
> Due to there have 2 EC registers changed when you toggle the hardware switch.
> Please also help to attach the acpidump and dmidecode, I want to check the
> OperationRegion of EmbeddedControl. And, the dmidecode is for indicate this
> machine.
> 
> Thanks a lot!

I've just attached my acpidump and dmidecode. I don't believe it makes a difference, but I'm using a bios hacked to remove the wifi card whitelist.

Thanks a lot for looking into this (I'm still stuck on 3.0 so I can still have wifi, but I have problems with usb and microphone that supposedly are fixed in newer kernel versions).
Comment 38 Lee, Chun-Yi 2012-08-28 05:01:07 UTC
(In reply to comment #37)
> (In reply to comment #34)
> > Hi Ivo, 
> > 
> > Thanks for your information.
> > 
> > Due to there have 2 EC registers changed when you toggle the hardware
> switch.
> > Please also help to attach the acpidump and dmidecode, I want to check the
> > OperationRegion of EmbeddedControl. And, the dmidecode is for indicate this
> > machine.
> > 
> > Thanks a lot!
> 
> I've just attached my acpidump and dmidecode. I don't believe it makes a
> difference, but I'm using a bios hacked to remove the wifi card whitelist.
> 

Thanks for your DSDT, I checked the region of embedded controller, there have 0x72 register that included BTEN and WLEN reflect to the RF status of wireless and bluetooth.

The _Q2B method access WLEN and BTEN, this method should called by Fn+F? key.

But, I didn't see 0x78 register marked on region of embedded controller.

> Thanks a lot for looking into this (I'm still stuck on 3.0 so I can still
> have
> wifi, but I have problems with usb and microphone that supposedly are fixed
> in
> newer kernel versions).

Let's focus on hardware switch (hard block of killswitch) first, please try the following acer-wmi patch for add your machine to type 3 quirk.
Comment 39 Lee, Chun-Yi 2012-08-28 05:02:37 UTC
Created attachment 78621 [details]
0001-acer-wmi-support-Lenovo-ideapad-S205-10382JG-wifi-sw.patch

acer-wmi: support Lenovo ideapad S205 10382JG wifi switch

This patch is for v3.2 kernel, I will port to newest kernel after tested.
Comment 40 Ivo Anjo 2012-08-29 08:17:17 UTC
(In reply to comment #39)
> Created an attachment (id=78621) [details]
> 0001-acer-wmi-support-Lenovo-ideapad-S205-10382JG-wifi-sw.patch
> 
> acer-wmi: support Lenovo ideapad S205 10382JG wifi switch
> 
> This patch is for v3.2 kernel, I will port to newest kernel after tested.

I've applied the patch on top of Ubuntu's 3.2 kernel tree (3.2.0-30-generic), and it works nicely. I get three entries on rfkill list:
0: ideapad_bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: no
1: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: acer-wireless: Wireless LAN
        Soft blocked: no
        Hard blocked: no
and both the side hardkill button and fn+f5 work correctly!

Thanks a lot! I can finally run a more recent kernel!
Comment 41 Lee, Chun-Yi 2012-08-30 02:45:16 UTC
Great!

I just sent out patch to upstream for review:
  [PATCH] acer-wmi: support Lenovo ideapad S205 10382JG wifi switch
Comment 42 Colin Newell 2012-10-20 14:20:26 UTC
Can you add the Lenovo S205-1038DPG to the list of quirks please?  It also uses the 0x78 register that the s205 quirk checks for it's hardware wifi switch.  

I verified this by modifying my acer-wmi.ko file and changing the string that currently refers to the 10382JG and changed it to say 1038DPG before rebooting.  With that modification the quirk kicked in, and the hardware wifi switch is correctly reported.
Comment 43 Lee, Chun-Yi 2012-10-23 02:53:39 UTC
(In reply to comment #42)
> Can you add the Lenovo S205-1038DPG to the list of quirks please?  It also
> uses
> the 0x78 register that the s205 quirk checks for it's hardware wifi switch.  
> 
> I verified this by modifying my acer-wmi.ko file and changing the string that
> currently refers to the 10382JG and changed it to say 1038DPG before
> rebooting.
>  With that modification the quirk kicked in, and the hardware wifi switch is
> correctly reported.

Thanks for your report, I sent patch to platform mail for review and waiting merge.

Thanks
Comment 44 Lee, Chun-Yi 2012-10-23 02:55:44 UTC
Created attachment 84411 [details]
0001-acer-wmi-support-Lenovo-ideapad-S205-1038DPG-wifi-s.patch

Sent to upstream for review
Comment 45 Ivo Anjo 2012-12-06 18:50:09 UTC
It seems that none of the patches (10382JG/1038DPG) has been accepted upstream...
Is there anything else we can do to help speed it up?
Comment 46 Andras Korn 2013-02-14 09:36:51 UTC
FWIW, the issue is still present in 3.7.6, and the same lobotomy in acer-wmi.c still "fixes" it for me.
Comment 47 Florian Mickler 2013-03-04 21:21:38 UTC
A patch referencing this bug report has been merged in Linux v3.9-rc1:

commit e6c33f1fe797355f1aed53b01230bd13ef52deff
Author: Lee, Chun-Yi <joeyli.kernel@gmail.com>
Date:   Fri Dec 14 16:14:25 2012 +0800

    acer-wmi: support Lenovo ideapad S205 10382JG wifi switch
Comment 48 Florian Mickler 2013-03-04 21:25:05 UTC
A patch referencing this bug report has been merged in Linux v3.9-rc1:

commit 5f3511d2a61e7874730d3ccc1a32d418259133be
Author: Lee, Chun-Yi <joeyli.kernel@gmail.com>
Date:   Fri Dec 14 16:14:28 2012 +0800

    acer-wmi: support Lenovo ideapad S205 1038DPG wifi switch
Comment 49 Andras Korn 2013-08-13 22:03:17 UTC
Issue still present in 3.10.5.
Comment 50 Andras Korn 2013-08-14 16:14:40 UTC
Also, emptying static const struct acpi_device_id norfkill_ids[] in acer-wmi.c still mostly "fixes" the problem in 3.10.5.

Strangely, the phantom rfkill is still re-engaged after a suspend-resume cycle, but toggling the two hardware switches(*) seems to help (maybe only one of the two needs to be toggled, I don't know yet).

(*) fn-f5 (soft lock) and the small switch on the side of the netbook (hard lock).