Hi Johannes, æ äï2011-03-23 æ 13:17 +0100ïJohannes Berg æåï > [remove Alan, his email address no longer works] > > Hi, > > > Sorry for I didn't really capture what your mean. Please then me > > introduce the issue's background: > > > > For the beginning, I added this patch to acer-wmi driver: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=466449cfe797b8a5d82d25d0e0e08426d8dfba19 > > > > Because Acer notebook's BIOS can keep the devices state when system > > reboot, so, the above patch add the logic when acer-wmi driver initial > > to query the devices state by wmi method then set soft-block to > > acer-wmi's killswitch, including wlan, bluetooth and wwan. > > > > The acer-wmi used rfkill_init_sw_state to set the initial state before > > rfkill register. > > Yeah that seems reasonable. > Yes, use rfill_init_sw_state to set the initial state from BIOS to killswitch is make sense. But, it looks like have tricky effect when rfkill-input enabled. > > There have source code in rfkill_init_sw_state to set rfkill to > > persistent, then rfkill/core.c replicate acer-wmi's bluetooth state to > > the same type's rfkill. > > > > if (!rfkill->persistent || rfkill_epo_lock_active) { > > schedule_work(&rfkill->sync_work); > > } else { > > #ifdef CONFIG_RFKILL_INPUT > > bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW); > > > > if (!atomic_read(&rfkill_input_disabled)) //when rfkill-input enable > > __rfkill_switch_all(rfkill->type, soft_blocked); //set sw block state to the same type > > #endif > > } > > But that's also required to actually make the persistent state have any > impact at all. > Yes, per Alan's patch, there have another issue need to workaround by set the block state to global, and those code might need removed in the future: commit b3fa1329eaf2a7b97124dacf5b663fd51346ac19 Author: Alan Jenkins <alan-jenkins@xxxxxxxxxxxxxx> Date: Mon Jun 8 13:27:27 2009 +0100 .... Drivers with persistent state will affect the global state only if rfkill-input is enabled. This is required, otherwise booting with wireless soft-blocked and pressing the wireless-toggle key once would have no apparent effect. This special case will be removed in future along with rfkill-input, in favour of a more flexible userspace daemon (see Documentation/feature-removal-schedule.txt). But, the above code replicate acer-wmi's initial state to global, then set to hci0's BT initial state. > > No, BIOS only emit acpi notify when user press function key, acer-wmi > > driver emit KEY_WLAN to userland after receive the acpi notify. Of > > course at this moment, acer-wmi driver need to maintain rfkill state to > > sync with real device state. > > So, I'm confused. Why does the driver not use the acer_wmi_notify > function to update the rfkill status too, but polls it every second? > I already have a patch to use acer-wmi_notify to set device state: http://www.spinics.net/lists/platform-driver-x86/msg01645.html It didn't accept, yet. But, even have this patch, there still have some old acer machine need use polling way because those machines have no wmi event notify. > > > It seems that what happens is roughly this: > > > 1) at boot, all BT is set to soft-killed due to the way the BIOS > > > started up > > > > Yes, acer BIOS's default value is bluetooth disabled. So, when system > > boot, there only have acer-wmi's bluetooth killswitch: > > > > 0: acer-wireless: Wireless LAN > > Soft blocked: no > > Hard blocked: no > > 1: acer-bluetooth: Bluetooth > > Soft blocked: yes # default is sw block > > Hard blocked: no > > 2: acer-threeg: Wireless WAN > > Soft blocked: no > > Hard blocked: no > > 4: phy0: Wireless LAN > > Soft blocked: no > > Hard blocked: no > > > > There have no hci0'> > when system cold boot. > > Right -- I missed that part. > > > > 2) when you press the button, it's a toggle, so rfkill-input toggles > > > all BT rfkill instances (acer and hci0) > > > > Per OldÅich's report, he press bluetooth hardware key then see like the > > following: > > > > 4: phy0: Wireless LAN > > Soft blocked: no > > Hard blocked: no > > 6: acer-wireless: Wireless LAN > > Soft blocked: no > > Hard blocked: no > > 7: acer-bluetooth: Bluetooth > > Soft blocked: no > > Hard blocked: no > > 8: acer-threeg: Wirele Hard blocked: no > > 9: hci0: Bluetooth > > Soft blocked: yes # create hci0 rfkill but default is soft blocked > > Hard blocked: no > > > > I didn't have bluetooth HW key on my Acer machine, but I can unblock acer-wmi bluetooth > > rfkill manually to reproduce this issue. > > Hmm, that I don't understand. Why would that reproduce the issue? Ah, > ok, that's because __rfkill_switch_all() will set global_states, and it > happens during init. So it gets registered with the global state, which > is still blocked since you just unblocked this single thing. > I have no Bluetooth HW key on my machine, but OldÅich can reproduce this issue by HW key. > So, it seems that the design here only works if The "the design" means call rfkill_init_sw_state before rfkill register? > a) the bios stores the last state This issue happen when "Bluetooth's initial state is disabled before system boot.", maybe user choice disable bluetooth at last time reboot, then BIOS keep BT disable. > b) the driver only reports key inputs, no rfkill inputs > > > If only use bluetooth HW key to control the rfkill, then it should be > > fine. But, OldÅich report still have problem cann't enable bluetooth > > after he press HW key because hci0's bluetooth default set to soft > > blocked. > > Yeah that's because the BT hw key seems to generate the wrong event? > No, BT HW key doesn't emit KEY_BLUETOOTH, it emit wmi event, then acer-wmi driver transfer to KEY_BLUETOOTH. Then I think rfkill-input (if enabled) also receive KEY_BLUETOOTH. I thought maybe it's a race condition the hci0 rfkill generated before rfkill-input key work for update the global state ? > > If we want to remove rfkill-input, then we need re-compiler kernel. Why > > don't add a option for enable/disable it ? > > Well I don't think we want to remove rfkill input, ever, because that > just leads to a mess where the user has to take action. I'd rather have > it work out of the box and be overridden by urfkill which should work > fine. > So, we should remove the following statement in Documentation/feature-removal-schedule.txt ? What: CONFIG_RFKILL_INPUT When: 2.6.33 Why: Should be implemented in userspace, policy daemon. Who: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > Of course, in this particular instance it _doesn't_ work out of the box, > but shouldn't we rather fix that? > Yes, if we want to keep the CONFIG_RFKILL_INPUT is !EXPERT, then I thought we should try to fix it. > > > But due the the behaviour you outlined earlier, I think your patch makes > sense... the BIOS doesn't actually seem to _store_ the rfkill state > anyway, since it's always off when you cold boot. So why bother using > that state as the default anyway? > It's tricky to me for use rfkill_init_sw_state. When rfkill-input disabled, everything works fine, but if rfkill-input enabled, then I need very careful to know it will change the global state and causes the global state replicate to any new rfkill. Honest, I don't know the rfkill_init_sw_state have the above condition before I read rfkill source code. > That will work around the problem at hand by making the acer wmi enable > BT whenever it is loaded, but that doesn't seem so bad either. > Yes, it's not good idea, BIOS can save device states when system reboot, I don't want erase the state. > As for the more generiI agreed your point or the urfkill daemon, does it possible we add urfkill daemon information to Kernel document? Thank's a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
