ibm-acpi Linux driver development

Kevin Locke | 5 Dec 2009 19:24

Re: bluetooth off state not remembered accross reboots?

On Tue, 2009-12-01 at 18:29 -0200, Henrique de Moraes Holschuh wrote:
> Ok, so it is the rfkill-input stuff (that is now part of the rfkill core)
> that is showing the problem (the bug might be elsewhere).  We need to track
> the state of the rfkill input device to know what's broken, then.

OK.  I think I have a pretty good understanding of what is going on
now.

Rfkill pretends that the master switch was set in its current position
at startup by using an EV_SW event on devices that support them.  So
when master_switch_mode=0 everything gets set to blocked, when
master_switch_mode=2 everything gets set to unblocked.  This is by
design (and 2 is the default).  The problem is that
master_switch_mode=1 does not behave well at all and default_state is
ignored.

The reason that master_switch_mode=1 is broken is that when a new
input device is registered, the rfkill_handler specifies rfkill_start
to be called for the new handle, which schedules an
rfkill_restore_states to be called before rfkill_eop is ever called.
So the 0-initialized (unblocked) save state is loaded for all devices.

default_state can be fixed by initializing the saved state to the
default state in rfkill_init (currently only the current state is
initialized).  However, this doesn't provide a way for thinkpad_acpi
to inform rfkill what the default state of each type should really be.
So, unless I am overlooking something, I think rfkill needs a new API
call to set the default state for each type of radio that tpacpi could
use before this bug can be fixed.

(Continue reading)

headers

Henrique de Moraes Holschuh | 5 Dec 2009 21:12

Re: bluetooth off state not remembered accross reboots?

On Sat, 05 Dec 2009, Kevin Locke wrote:
> Rfkill pretends that the master switch was set in its current position
> at startup by using an EV_SW event on devices that support them.  So

Actually, no, rfkill doesn't pretend anything.

The *drivers* that implement that EV_SW SW_RFKILL_ALL (like thinkpad-acpi)
*push* EV_SW events to rfkill with the current state.  The input layer does
level-to-edge conversion, but that cannot be done at driver load (we don't
know the previous state), so in practice, you will tell the rfkill core that
the rfkill switch has just been enabled/disabled when any such module loads.

This is why you see rfkill EV_SW SW_RFKILL_ALL-related activity when you
rmmod and then modprobe thinkpad-acpi back again.

Fixing this is possible, but quite troublesome (we need to register an input
device signature permanently in the rfkill core, and remember it across
input device attach/detach, and do the right thing if it attaches twice
because there are two such devices in the system, etc).

In the most common use case (modules are loaded at boot and left alone after
that) it causes no problem, so I don't think it will get fixed anytime soon.

But if it is pestering you enough to write the code, you could ask the
rfkill maintainer if he would accept such a patch (feel free to have me in
the Cc).

> when master_switch_mode=0 everything gets set to blocked, when
> master_switch_mode=2 everything gets set to unblocked.  This is by
> design (and 2 is the default).  The problem is that

(Continue reading)

headers

Kevin Locke | 5 Dec 2009 23:11

Re: bluetooth off state not remembered accross reboots?

On Sat, 2009-12-05 at 18:12 -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 05 Dec 2009, Kevin Locke wrote:
>> Rfkill pretends that the master switch was set in its current position
>> at startup by using an EV_SW event on devices that support them.  So
> 
> Actually, no, rfkill doesn't pretend anything.
> 
> The *drivers* that implement that EV_SW SW_RFKILL_ALL (like thinkpad-acpi)
> *push* EV_SW events to rfkill with the current state.

Except that it is also sent internally in rfkill when the input device
is registered by rfkill_start at input.c:252 (without any request from
the individual driver afaict - other than support for EV_SW), which is
where the problem is happening.

> Fixing this is possible, but quite troublesome (we need to register an input
> device signature permanently in the rfkill core, and remember it across
> input device attach/detach, and do the right thing if it attaches twice
> because there are two such devices in the system, etc).
> 
> In the most common use case (modules are loaded at boot and left alone after
> that) it causes no problem, so I don't think it will get fixed anytime soon.

So states being preserved across reboots is not considered part of the
common use case?  I can live with that, although it is frustrating.

>> The reason that master_switch_mode=1 is broken is that when a new
>> input device is registered, the rfkill_handler specifies rfkill_start
>> to be called for the new handle, which schedules an
>> rfkill_restore_states to be called before rfkill_eop is ever called.

(Continue reading)

headers

Henrique de Moraes Holschuh | 7 Dec 2009 12:36

Re: bluetooth off state not remembered accross reboots?

On Sat, 05 Dec 2009, Kevin Locke wrote:
> On Sat, 2009-12-05 at 18:12 -0200, Henrique de Moraes Holschuh wrote:
> > On Sat, 05 Dec 2009, Kevin Locke wrote:
> >> Rfkill pretends that the master switch was set in its current position
> >> at startup by using an EV_SW event on devices that support them.  So
> > 
> > Actually, no, rfkill doesn't pretend anything.
> > 
> > The *drivers* that implement that EV_SW SW_RFKILL_ALL (like thinkpad-acpi)
> > *push* EV_SW events to rfkill with the current state.
> 
> Except that it is also sent internally in rfkill when the input device
> is registered by rfkill_start at input.c:252 (without any request from
> the individual driver afaict - other than support for EV_SW), which is
> where the problem is happening.

Well, thinking about it, it is clear rfkill has no choice but to do that, as
it has to handle hotplugging.

I have fixed thinkpad-acpi to not issue initial events, and sync the
inputdev "sw" bitmap directly.  I have also a patch to add an API to do it
properly to the input layer, which I will submit after the quick-and-dirty
fix hits mainline (otherwise experience tells me it will cause headaches).

I will post the changes here, for your testing.  Maybe they won't fix
everything, but they should help.

> > Fixing this is possible, but quite troublesome (we need to register an input
> > device signature permanently in the rfkill core, and remember it across
> > input device attach/detach, and do the right thing if it attaches twice

(Continue reading)