Hi Joey Lee, On Monday 21 March 2011 18:52:58 Joey Lee wrote: > Hi OldÅich, > > æ äï2011-03-21 æ 05:26 -0600ïJoey Lee æåï > > > Add Cc. to experts: Johannes Berg, David S. Miller, Marcel Holtmann and > > Gary Lin > > > > Hi OldÅich, > > > > æ æï2011-03-20 æ 21:09 +0100ïOldÅich JedliÄka æåï > > > > > Hi Joey Lee, > > > > > > Finally I've got little time to expriment. > > > > Thank's for you also reserve time to trace it. And, I also add comment > > on bugzilla: > > https://bugzilla.kernel.org/show_bug.cgi?id=31002 > > > > > On Wednesday 16 March 2011 09:59:16 Joey Lee wrote: > > > > Hi OldÅich, > > > > > > > > æ äï2011-03-16 æ 07:32 +0100ïOldÅich JedliÄka æåï > > > > > > > > > > After trace rfkill-input stuff, I thought this is rfkill-input's > > > > > > normal behavior but not a bug. > > > > > > > > > > > > Unfortunately, I didn't find any workaround way when a driver > > > > > > need to call rfkill_init_sw_state, e.g. acer-wmi driver. > > > > > > > > > > > > The rfkill-input will sync the rfkill state to all killswitchs > > > > > > that have the same type. For example, acer-wmi set the initial > > > > > > software switch to _BLOCK_ when driver initial, then > > > > > > rfkill-input will also set any new bluetooth killswitch state to > > > > > > _BLOCK_ . > > > > > > > > > > The rfkill_sync_work syncs with rfkill_global_states, which is set > > > > > during intitialization or by rfkill_switch_all, if I read it > > > > > correctly. This should be independent to acer-bluetooth state. The > > > > > rfkill_global_states[BLUETOOTH] should be unblocked initially, I > > > > > need to verify it. > > > > > > > > Yes! > > > > Ideally, killswitch state should be independent to different driver, > > > > even the killswitch type is the same. > > > > > > > > But, > > > > If you enabled CONFIG_RFKILL_INPUT, then rfkill_register will > > > > replicate state for each killswitch that have the same type: > > > > > > > > vi net/rfkill/core.c > > > > > > > > int __must_check rfkill_register(struct rfkill *rfkill) > > > > { > > > > ... > > > > > > > > if (!rfkill->persistent || rfkill_epo_lock_active) { > > > > > > > > schedule_work(&rfkill->sync_work); > > > > > > > > } else { /* if rfkill->persistent then set the state to all > > > > > > the > > > > > > > same type */ #ifdef CONFIG_RFKILL_INPUT /* when CONFIG_RFKILL_INPUT = > > > > Y */ > > > > > > > > bool soft_blocked = !!(rfkill->state & > > > > RFKILL_BLOCK_SW); > > > > > > > > if (!atomic_read(&rfkill_input_disabled)) > > > > > > > > __rfkill_switch_all(rfkill->type, > > > > soft_blocked); /* > > > > > > > > here call switch all to sync state */ #endif > > > > > > > > } > > > > > > > > When any driver call rfkill_init_sw_state for set the initial state > > > > to killswitch, this rfkill->persistent will set to true: > > > > > > > > void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked) /* > > > > acer- > > > > > > wmi > > > > > > > driver used it to set inital killswitch state */ { > > > > .... > > > > > > > > spin_lock_irqsave(&rfkill->lock, flags); > > > > __rfkill_set_sw_state(rfkill, blocked); > > > > rfkill->persistent = true /* persistent set to true */ > > > > > > > > That's why acer-wmi bluetooth killswitch's state was been replicate > > > > to hci_core's killswitch state. > > > > > > > > When CONFIG_RFKILL_INPUT set to Y, and any driver call > > > > rfkill_init_sw_state before register rfkill, then rfkill_register > > > > will try to sync state to the same killswitch type like the above. > > > > > > > > It's make sense, > > > > because rfkill-input only can block/unblock the same killswitch type > > > > at the same time, before rfkill-input active, it want all the same > > > > type's state is full the same. > > > > > > > > And, > > > > rfkill-input also suppose user only can use keycode (maybe Fn key) to > > > > control killswitch state, so, direct use rkill tool or echo state to > > > > killswitch for change the state will cause killswitchs' state lost > > > > link. It like we do. > > > > > > > > > There is some magic in rfkill/input.c that plays with global > > > > > states, but I don't know if or how that one is used in my case. > > > > > > > > Suggest you can disable CONFIG_RFKILL_INPUT or markup the following > > > > code. You will see the new bluetooth killswitch will be unblock when > > > > it created. > > > > > > > > diff --git a/net/rfkill/core.c b/net/rfkill/core.c > > > > index 0198191..0dec078 100644 > > > > --- a/net/rfkill/core.c > > > > +++ b/net/rfkill/core.c > > > > @@ -950,14 +950,14 @@ int __must_check rfkill_register(struct rfkill > > > > *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)) > > > > - __rfkill_switch_all(rfkill->type, > > > > soft_blocked); -#endif > > > > - } > > > > + } //else { > > > > +//#ifdef CONFIG_RFKILL_INPUT > > > > +// bool soft_blocked = !!(rfkill->state & > > > > RFKILL_BLOCK_SW); +// > > > > +// if (!atomic_read(&rfkill_input_disabled)) > > > > +// __rfkill_switch_all(rfkill->type, > > > > soft_blocked); +//#endif > > > > +// } > > > > > > > > rfkill_send_events(rfkill, RFKILL_OP_ADD); > > > > > > Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've > > > tried to enable CONFIG_RFKILL_INPUT, but remove the mentioned block of > > > code. The result is working bluetooth HW switch. > > > > Yes, that because the following patch introduce > > driver with persistent state will affect the global state only if > > rfkill-input is enabled: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit > > ;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19 > > > > It maybe workaround another rfkill-input issue, but causes it replicate > > acer-wmi's bluetooth killswitch initial state (or any driver that used > > rfkill_init_sw_state) to any new bluetooth killswitch. > > > > It's not make sense. > > > > > > > > Acer's BIOS default setup bluetooth's state is disable when > > > > > > system cold boot, and BIOS also can save the connection devices' > > > > > > state when system reboot. Currently, acer-wmi driver have right > > > > > > behavior to sync the state with BIOS. > > > > > > > > > > > > Face to your situation, my suggestion is: > > > > > > > > > > > > - Use userland application to correct killswitch state. > > > > > > > > > > > > highly suggest You can try urfkill daemon: > > > > > > http://www.freedesktop.org/wiki/Software/urfkill or > > > > > > > > > > > > write a startup script to enable bluetooth when system boot. > > > > > > > > > > > > - Disable rfkill-input module if you didn't real use it. > > > > > > > > > > > > The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN, > > > > > > but doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't > > > > > > help you enable bluetooth killswitch. > > > > > > > > > > I didn't have time to look at the problem more deeply to identify > > > > > who is setting the global state to "blocked" or what really > > > > > happens. Anyway, I did some testing with pressing the HW bluetooth > > > > > switch and I saw the following immediately _after_ pressing the HW > > > > > switch to enable bluetooth: > > > > > > > > > > oldium ~ # rfkill list > > > > > 0: acer-wireless: Wireless LAN > > > > > > > > > > Soft blocked: no > > > > > Hard blocked: no > > > > > > > > > > 1: acer-bluetooth: Bluetooth > > > > > > > > > > Soft blocked: no > > > > > Hard blocked: no > > > > > > > > > > 2: acer-threeg: Wireless WAN > > > > > > > > > > Soft blocked: yes > > > > > Hard blocked: no > > > > > > > > > > 3: phy0: Wireless LAN > > > > > > > > > > Soft blocked: no > > > > > Hard blocked: no > > > > > > > > > > I had this output 3 times immediately after each other. I'm using > > > > > keyboard "up" and "enter" to repeat the last shell command, so this > > > > > is a relatively slow operation. So the state when the > > > > > acer-bluetooth was unbloc> > > > > > > > > oldium ~ # rfkill list > > > > > 0: acer-wireless: Wireless LAN > > > > > > > > > > Soft blocked: no > > > > > Hard blocked: no > > > > > > > > > > 1: acer-bluetooth: Bluetooth > > > > > > > > > > Soft blocked: no > > > > > Hard blocked: no > > > > > > > > > > 2: acer-threeg: Wireless WAN > > > > > > > > > > Soft blocked: yes > > > > > Hard blocked> > > > > > > > > > > > > 5: hci0: Bluetooth > > > > > > > > > > Soft blocked: yes > > > > > Hard blocked: no > > > > > > > > My Acer machine have no HW bluetooth key but only have one HW WLAN > > > > key that emit KEY_WLAN. > > > > Please use lshal to monitor your HW bluetooth key and make sure it > > > > emit KEY_BLUETOOTH. > > > > > > `lshal -m` outputs this: > > > > > > <bluetooth key pressed> > > > 20:45:53.694: platform_i8042_i8042_KBD_port_logicaldev_input condition > > > ButtonPressed = bluetooth > > > 20:45:54.666: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth > > > property killswitch.state = 1 (0x1) > > > 20:45:54.678: usb_device_a5c_2101_noserial added > > > ... > > > <bluetooth key pressed again> > > > 20:46:02.435: platform_i8042_i8042_KBD_port_logicaldev_input condition > > > ButtonPressed = brightness-up > > > 20:46:02.668: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth > > > property killswitch.state = 0 (0x0) > > > 20:46:02.919: usb_device_a5c_2101_noserial_if1 removed > > > ... > > > > > > Strange is "brightness-up" key, somebody is wrong here. > > > > Yes, brightness-up key is another story, maybe you can enable acpi debug > > to look at montior which acpi method or _Q event method used: > > > > echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer > > echo 0xF >/sys/module/acpi/parameters/debug_level > > > > But, this is not related to our current killswitch issue, let us skip > > it. > > > > > > > So it looks like the hci0 went blocked even when the acer-bluetooth > > > > > switch was unblocked. So it looks like the hci0 state is > > > > > independent on the initial acer- bluetooth state. > > > > > > > > > > Hopefully I have some time this evening (CET timezone) to add some > > > > > stack traces and logs to see what really happens on my system. > > > > > > > > > > Cheers, > > > > > OldÅich. > > > > > > > > Still suggest you can disable CONFIG_RFKILL_INPUT then use rfkill > > > > tool to set acer-wmi bluetooth killswitch for test, must have > > > > different result. > > > > > > Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at > > > Kconfig in net/rfkill and there is a line "default y if !EXPERT" which > > > means (I think) that it would be enabled by default for anybody not > > > enabling expert options. So other non-expert users would have the same > > > troubles as I have. > > > > I agreed your point, and I don't think rfkill-input need enable for all > > non-Expert user because it sometimes have conflict with EC or userland > > behavior. > > > > I still suggest you can disable rfkill-input then please try Gary Lin's > > urfkill daemon, it can do what does rfkill-input do and more > > flexibility. > > > > > I've tried `rfkill unblock <acer-bluetooth number>` with my second test > > > (enabled CONFIG_RFKILL_INPUT plus patched core.c) - it works perfectly. > > > > > > Anyway, it looks like using CONFIG_RFKILL_INPUT is broken to some > > > degree, because enabling the config switch changes bluetooth HW/SW > > > switch from working to not-fully-working. > > > > > > Cheers, > > > OldÅich. > > > > The root cause is what I said in the above, it's hard to fix in kernel > > module because user only can choice enable/disable rfkill-input in > > Kconfig and even cann't choice it when system boot. > > > > I thought we need: > > - set rfkill-input to EXPERT, remove !EXPERT > > - add a kernel option to rfkill for user can choice enable it or not > > > > when system boot. > > > > - Add comment in Documentation/rfkill.txt for remind user can use > > > > urfkill daemon (or any other userland daemon) to replace rfkill-input. > > > > Of course need rfkill experts' more professional comments for this > > topic. > > I will try to gener> Thank's a lot! > > Joey Lee > > Finally, I removed rfkill_init_sw_state and maintain a rfkill_inited > flag to workaround issue, please kindly help to test the following > acer-wmi patch, it works fine to me on my acer travelmate 8572 machine. > > Maybe it will be our backup solution after you tested: The patch works more than well - the bluetooth starts-up automatically during boot. I don't know who does it, because it looks like the last action done before any service gets started. ... [ 4.434293] acer-wmi: Acer Laptop ACPI-WMI Extras ... [ 4.559937] acer-wmi: Brightness must be controlled by generic video driver ... [ 6.024186] usb 8-2: new full speed USB device using uhci_hcd and address 2 [ 6.183561] usb 8-2: New USB device found, idVendor=0a5c, idProduct=2101 ... [ 9.763265] udev[1947]: starting version 164 It looks like the sync work synchronizes the state to "unblocked". I don't have more time to investigate the difference today, so maybe in following days - if it is important. Regards, OldÅich. > >From dd3d9208aa63d9670d24409b4aaaeb619f3137d6 Mon Sep 17 00:00:00 2001 > > From: Lee, Chun-Yi <jlee@xxxxxxxxxx> > Date: Tue, 22 Mar 2011 01:43:11 +0800 > Subject: [PATCH] acer-wmi: remove rfkill_init_sw_state to workaround > rfkill-input issue > > acer-wmi: remove rfkill_init_sw_state to workaround issue for bko#31002 > > Signed-off-by: Lee, Chun-Yi <jlee@xxxxxxxxxx> > --- > drivers/platform/x86/acer-wmi.c | 19 ++++++++++++++----- > 1 files changed, 14 insertions(+), 5 deletions(-) > > diff --git a/drivers/platform/x86/acer-wmi.c > b/drivers/platform/x86/acer-wmi.c index 38b34a7..3d3cb46 100644 > --- a/drivers/platform/x86/acer-wmi.c > +++ b/drivers/platform/x86/acer-wmi.c > @@ -222,6 +222,7 @@ struct acer_debug { > static struct rfkill *wireless_rfkill; > static struct rfkill *bluetooth_rfkill; > static struct rfkill *threeg_rfkill; > +static int rfkill_inited; > > /* Each low-level interface must define at least some of the following */ > struct wmi_interface { > @@ -1161,9 +1162,13 @@ static int acer_rfkill_set(void *data, bool blocked) > { > acpi_status status; > u32 cap = (unsigned long)data; > - status = set_u32(!blocked, cap); > - if (ACPI_FAILURE(status)) > - return -ENODEV; > + > + if (rfkill_inited) { > + status = set_u32(!blocked, cap); > + if (ACPI_FAILURE(status)) > + return -ENODEV; > + } > + > return 0; > } > > @@ -1187,14 +1192,16 @@ static struct rfkill *acer_rfkill_register(struct > device *dev, return ERR_PTR(-ENOMEM); > > status = get_device_status(&state, cap); > - if (ACPI_SUCCESS(status)) > - rfkill_init_sw_state(rfkill_dev, !state); > > err = rfkill_register(rfkill_dev); > if (err) { > rfkill_destroy(rfkill_dev); > return ERR_PTR(err); > } > + > + if (ACPI_SUCCESS(status)) > + rfkill_set_sw_state(rfkill_dev, !state); > + > return rfkill_dev; > } > > @@ -1229,6 +1236,8 @@ static int acer_rfkill_init(struct device *dev) > } > } > > + rfkill_inited = 1; > + > schedule_delayed_work(&acer_rfkill_work, round_jiffies_relative(HZ)); > > return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
