Hi Johaness, On Wednesday 23 March 2011 12:58:08 Johannes Berg wrote: > On Mon, 2011-03-21 at 20:27 +0100, OldÅich JedliÄka wrote: > > hci0 doesn't exist when the BT switch is off. The hci0 device and rfkill > > switch appears when you unblock SW rfkill or by pressing the HW switch. > > It disappears when you block the switch again. hci0 is set to "blocked" > > when it appears, because the acer-wmi driver have registered > > acpi-bluetooth rfkill switch during boot, which was set to "blocked" > > initially with a call to rfkill_init_sw_state. So what happens actually > > is this: > > > > 1) at boot, BIOS says the bluetooth is disabled, so the not-registered > > state of acer-bluetooth rfkill is set to "blocked" > > (rfkill_init_sw_state, sets the "persistent" bit). The acer-bluetooth is > > then registered, which forces the global bluetooth state to go > > "blocked". No hci0 exists at this time. > > > > 2) when you press the button, hci0 appears and the rfkill is set to the > > global bluetooth state (in rfkill_sync_work), which is "blocked". > > > > From my understanding acer-wmi reports the change via acer_rfkill_update > > work (executed every second). It just calls rfkill_set_sw_state, but > > that doesn't update the global state. I don't know at which time that > > happens, but generally I didn't find anything that could eventually > > enable hci0 state or global state to "unblocked". > > Ah. So I guess when hci0 gets registered, the acer rfkill state hasn't > been updated yet, hence registering hci0 as blocked. No, that is not the case. I can play with `rfkill list` immediately after I press the HW bluetooth switch and show that hci0 is not there (still unregistered) while acer-bluetooth is already "unblocked" - I've tried to run `rfkill list` repeatedly manually from console immediately after I pressed the HW BT switch and acer-bluetooth was "unblocked" several runs while the hci0 wasn't there. When hci0 appeared, it was "blocked". As I wrote, I didn't find anything changing the global state, which is actually used to "block" the newly appearing hci0 (in the rfkill_sync_work method). It looks like the global state is just "blocked" forever - and it is "blocked" as a side-effect of the call to rfkill_init_sw_state (changes permanent=true) and then call to rfkill_register from the acer-wmi driver. I can verify this in the following days (that the global state stays the same all the time). Cheers, OldÅich. > > johannes > > -- > 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 -- 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
