Bug 31002

For acer-wmi driver want to sync the Acer BIOS's default devices state to killswitch that were generated by acer-wmi. So, acer-wmi call rfkill_init_sw_state api to set initial state to killswitch.
By the default, Acer BIOS set bluetooth device to disable, so acer-wmi will sync BT disable state to acer-wmi bluetooth killswitch.

The original issue causes by acer-wmi ste the bluetooth killswitch to block when system cold boot, but rfkill-input replicate this block state to any other new bluetooth killswitch, even those new killswitch no maintain by acer-wmi.

This issue causes by enable rfkill-input that the following patch introduce driver with persistent state will affect the global state only if rfkill-input is enabled:

commit b3fa1329eaf2a7b97124dacf5b663fd51346ac19
Author: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date:   Mon Jun 8 13:27:27 2009 +0100

    rfkill: remove set_global_sw_state
    
    rfkill_set_global_sw_state() (previously rfkill_set_default()) will no
    longer be exported by the rewritten rfkill core.
    
    Instead, platform drivers which can provide persistent soft-rfkill state
    across power-down/reboot should indicate their initial state by calling
    rfkill_set_sw_state() before registration.  Otherwise, they will be
    initialized to a default value during registration by a set_block call.
    
    We remove existing calls to rfkill_set_sw_state() which happen before
    registration, since these had no effect in the old model.  If these
    drivers do have persistent state, the calls can be put back (subject
    to testing :-).  This affects hp-wmi and acer-wmi.
    
    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).
    
    Now rfkill_global_states[n].def is only used to preserve global states
    over EPO, it is renamed to ".sav".
    
    Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
    Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

I don't understand your comment. The way I see it, that commit just missed setting the acer-wmi's BT state to soft-blocked at init.

The commit even says so:

    We remove existing calls to rfkill_set_sw_state() which happen before
    registration, since these had no effect in the old model.  If these
    drivers do have persistent state, the calls can be put back (subject
    to testing :-).  This affects hp-wmi and acer-wmi.

Hi Johannes, 

Thank's for your response. Please current me if I miss anything.

(In reply to comment #2)
> I don't understand your comment. The way I see it, that commit just missed
> setting the acer-wmi's BT state to soft-blocked at init.

Current acer-wmi driver use rfkill_init_sw_state to set BT's killswitch to
soft-blocked when system boot:

static struct rfkill *acer_rfkill_register(struct device *dev,
                                           enum rfkill_type type,
                                           char *name, u32 cap)
{
        int err;
        struct rfkill *rfkill_dev;
        u32 state;
        acpi_status status;

        rfkill_dev = rfkill_alloc(name, dev, type,
                                  &acer_rfkill_ops,
                                  (void *)(unsigned long)cap);
        if (!rfkill_dev)
                return ERR_PTR(-ENOMEM);

        status = get_device_status(&state, cap);
        if (ACPI_SUCCESS(status))
                rfkill_init_sw_state(rfkill_dev, !state);    //here set to sw
block

Because, acer's BIOS define the BT initial state to disable, so I use
rfkill_init_sw_state to set BT killswitch to sw block.

Did I use wrong api ? but I didn't see any other way can set initial state to
killswitch.

And, this issue only happen when rfkill-input enabled. Please kindly reference
this mail loop:
http://marc.info/?l=linux-acpi&m=129978235612140&w=2

I checked the source code.

rfkill_init_sw_state will set rfkill to persistent, then rfkill driver was replicate the state to other new BT killswitch when rfkill-input enable,

Let's discuss in your email thread and update this bug with the result.

Just add remind Oldřich's acer machine is:
ACER TravelMate 5730G

Created attachment 51582 [details]
0001-acer-wmi-remove-rfkill_init_sw_state-to-workaround.patch

A workaround patch to acer-wmi driver, it removed the rfkill_init_sw_state function call and stop to update the block state in acer_rfkill_set before rfkill initial finished.

(In reply to comment #8)
> Created an attachment (id=51582) [details]
> 0001-acer-wmi-remove-rfkill_init_sw_state-to-workaround.patch

Did anyone review or test this patch?

Sorry, not yet, I will send patch to platform driver group for review.

This patch provide a better work in acer-wmi for maintain the initial state, but for this issue, the root cause maybe is in input subsystem. Still discussing and double check with Dmitry.

Maybe will open another bug to input subsystem.

Created attachment 52292 [details]
0001-acer-wmi-does-not-set-persistence-state-by-rfkill_i.patch

Sand to platform driver group for review.

For this issue, have another cause is input handler register have race condition with udev keymap, the following is email discussion with Dmitry:

> 
> Hi Joey,
> 
> If you look in /proc/bus/input/devices do you see rfkill-input as
> actually bound to the device that has KEY_BLUETOOTH?
> 

Like you said, we fell into the trap:

Fail case:

linux-uy92:/proc/bus/input # vi devices

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input0
U: Uniq=
H: Handlers=sysrq kbd event0
B: PROP=0
B: EV=120013
B: KEY=10000 c0200 0 0 0 0 0 700f 2000003 3803078 f830f401 febfffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7


Success case:

linux-uy92:/proc/bus/input # vi devices 

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input0
U: Uniq=
H: Handlers=sysrq kbd event0 rfkill
B: PROP=0
B: EV=120013
B: KEY=10000 c0200 0 0 0 0 0 700f 2000003 3803078 f830f401 febfffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7


In fail case, rfkill didn't register to keyboard's Handlers. And, I also
checked the rfkill-input's .connect didn't call by input when system
boot:

Fail case:

[    7.144252] rfkill: rfkill_handler_init
[    7.144277] rfkill: rfkill_handler_init, start input_register_handler


Success case:

[    7.580683] rfkill: rfkill_handler_init
[    7.580714] rfkill: rfkill_handler_init, start input_register_handler
[    7.580737] rfkill: doing input_register_handle

> Since it is atkbd that is emitting KEY_BLUETOOTH and this key is not in
> the default keymap I think you must be loading Acer-specific keymap via
> udev or some other mechanism, and I guess stumbling upon a deficiency in
> input layer: we do not re-match devices after changing keymap. So if
> rfkill-input was loaded before keymap was altered, then it will not bind
> to the keyboard even if you add KE_BLUETOOTH at a later time. Fixing
> this is something that was on my TODO list for a while now...
> 
> Thaks.
> 

Yes,
this a race condition for rfkill-input register before udev set
Acer-specific keymap. 

We didn't find it just because old acer-wmi driver hide the BIOS default
devices states and always set bluetooth state to enabled when system
boot.


Thank's
Joey Lee

A patch referencing this bug report has been merged in v2.6.38-9043-gc585015:

commit 8215af019040ce9182728afee9642d8fdeb17f59
Author: Lee, Chun-Yi <joeyli.kernel@gmail.com>
Date:   Mon Mar 28 16:52:02 2011 +0800

    acer-wmi: does not set persistence state by rfkill_init_sw_state

I've tested current vanilla git master and I confirm that the patch fixes the problem. Bluetooth comes up after boot.

There were other problems identified during testing (see mailing list), but this bug can be closed I think - the reported problem has been fixed for me.

Nice. Thanks for the update, closing.

ok looks like i found the discussion (http://marc.info/?l=linux-acpi&m=129978235612140&w=4) for the issue that this patch creates: resume from suspend to ram becomes broken. i've filed my situation as bug 34862, i guess it could be duped and this one reopened?

without this patch my bluetooth is in a similar limbo as described in the discussion url above, this is on acer travelmate 8172, with no bluetooth key. i think one of the developers had a 8572, so that's good at least.

i'm not sure how to handle this in a clean way. if bluetooth is soft-blocked, does this save energy? that's the only reason i'd have it off at all. i'm guessing that acer doesn't think bluetooth switch has significant energy savings, or why else do they not provide a hotkey like wifi?

i will take a look urfkill now.

typo: bug 34682 is correct