On Tue, 2009-12-01 at 18:29 -0200, Henrique de Moraes Holschuh wrote: > Well, if you pull from here: > git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git release/2.6.31 All testing now being done from this branch. > Please check and report what thinkpad-acpi reports for the content of > /sys/bus/platform/devices/thinkpad-acpi/hotkey_radio_sw > > It has to be zero if the rfkill *physical* switch is on the "radios disabled" > position, and 1 if it is in the "radios enabled" position. I can confirm that it is. > When the switch is in the "radios disabled" position, *every* rfkill device > based on thinkpad-acpi *must* report that the state is "2" > (hardware-blocked). > > When the switch is in the "radios enabled" position, the rfkill devices must > report either state "0" (software blocked) or "1" (unblocked). I can confirm this is true as well. Note that with master_switch_mode=1 or master_switch_mode=2 all devices will report 1 after switching off and back on, regardless of previous state. With master_switch_mode=0 all devices report 0 after switching off and back on, regardless of previous state. > The rfkill core keeps "global" state for each type of rfkill switch, and > something weird might be happening related to that. It could be interesting > to check it, but you will need something to interface to /dev/rfkill. Using that utility in list mode, it reports states which match those from sysfs. In event mode, some of the output may be more useful. Note that I think phy0 lags behind tpacpi, which confuses the output a little. In the output below, master_switch_mode=1 and idx 0 is phy0, 1 is tpacpi_bluetooth_sw, 2 is tpacpi_wwan_sw. The testing was started with bluetooth soft blocked and everything else unblocked, at the end of the test everything is unblocked. # Initial state RFKILL event: idx 0 type 1 op 0 soft 0 hard 0 RFKILL event: idx 1 type 2 op 0 soft 1 hard 0 RFKILL event: idx 2 type 5 op 0 soft 0 hard 0 # Switch toggled to off RFKILL event: idx 1 type 2 op 2 soft 1 hard 1 RFKILL event: idx 2 type 5 op 2 soft 0 hard 1 RFKILL event: idx 0 type 1 op 2 soft 1 hard 0 RFKILL event: idx 1 type 2 op 2 soft 1 hard 1 RFKILL event: idx 2 type 5 op 2 soft 1 hard 1 RFKILL event: idx 0 type 1 op 2 soft 1 hard 1 # Switch toggled to on RFKILL event: idx 1 type 2 op 2 soft 1 hard 0 RFKILL event: idx 2 type 5 op 2 soft 1 hard 0 RFKILL event: idx 0 type 1 op 2 soft 0 hard 1 RFKILL event: idx 1 type 2 op 2 soft 0 hard 0 RFKILL event: idx 2 type 5 op 2 soft 0 hard 0 RFKILL event: idx 0 type 1 op 2 soft 0 hard 0 RFKILL event: idx 4 type 2 op 0 soft 0 hard 0 RFKILL event: idx 4 type 2 op 2 soft 0 hard 0 > But it appears, from your description, that we are disturbing the kernel at > module load. One of the things that thinkpad-acpi will do at module load, > is to issue a EV_SW SW_RFKILL_ALL event with the current state of the rfkill > switch. If that is not working right, it might be the reason for the > problem. That would make sense with how the master switch behaves when toggled. If this same effect is simulated with the EV_SW, that would explain what is happening. > On Tue, 01 Dec 2009, Kevin Locke wrote: >> If this is expected behavior, could it be documented somewhere (or am >> I overlooking somewhere that it is documented already)? > > No, there is something wrong, and I'd really like to know what :P I really appreciate you looking into it. If there is anything else I can do to help/test, please let me know. Kevin ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
