Re: rfkill v9: fixes and thinkpad-acpi conversion

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

On Thu, 2009-05-21 at 00:04 -0300, Henrique de Moraes Holschuh wrote:
> John,

I think you mean me ;)

> Here are two patches for the rfkill core rewrite, plus the thinkpad-acpi
> conversion.
> 
> Just fold them into your latest rfkill rewrite patch.

Done.

> HOWEVER, the thing doesn't work right.  Now, I am pretty sure I might have
> done something wrong somewhere in the thinkpad-acpi conversion (for
> example: the UWB switch never registers with its hw-block state right, but
> all others do), and I would appreciate if you could look it over and tell
> me what I am doing that upsets the core.

I don't see anything obviously wrong with the code. Can't say I
completely understand it though, and I don't seem to be able to decode
what it's doing with what feels like half an emulation layer for rfkill
inside the driver.

> The core might have some bugs left, too.  It seems to ignore set_sw_state
> changes, I can't see it reflected on rfkill/state, and it is _not_ because
> it is trying to set it back to whatever it wanted properly (or I'd get
> calls to the set_block hook).  Maybe it is something in my thinkpad-acpi
> conversion, though.

But you're not in hard block are you? The sysfs file works like this:
0  !hard, !soft
1  !hard, soft
2  hard, !soft AND hard, soft

> Anyway, the core needs proper coverage testing of its full functionality
> before it can be merged in mainline.  Just like you found that the old core
> never worked right for LEDs, the new rewrite was not processing any KEY_*
> input events, which is a quite important functionality...

Actually it was working for me for WLAN :) But that's because WLAN is
the first, as you found in input.c, thanks for that.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]