|
From: Dmitry T. <dmi...@gm...> - 2007-05-21 14:03:27
|
Hi, On 5/21/07, Henrique de Moraes Holschuh <hm...@hm...> wrote: > On Mon, 21 May 2007, Richard Hughes wrote: > > Has there been any work on implementing rfkill for thinkpad_acpi? If > > there is nobody working on this I am offering to add support into > > thinkpad_acpi this week. > > Yes, I have been talking to the rfkill people, but we had some disagreements > on how to best to it. I let it rest for a week or so to think better about > some issues they raised, and also in order not to waste too much bandwidth > from either side of the issue. > > Basically, I want a "fetch data from the hardware to know what state it is > in for real" interface. They want a "find a way to make sure the hardware > is doing what we told it to do" interface. > > I might even find out that we are better off not using rfkill in > thinkpad-acpi itself, and letting the bluetooth and wwan drivers process it. > We shall see. The thinkpad ACPI interface does a lot more than just > radio-kill, it actually kills power to the *devices* themselves, AFAIK > (removes them from the USB bus, causing hotunplug events). Anyone with a > bluetooth and WWAN device, please speak up. > > So far, what I got is that rfkill is all about handling "please disable > radios" system-wide events, and not about providing drivers with a standard > sysfs interface to enable/disable radio functionality. At least for now. > RFkill is not only about "please disable radios", it _does_ provide the standard sysfs interface to control the radios as well. You know I got curious and looked at thinkpad_acpi driver and adding rfkill support for bluetooth to it turned out to be pretty easy. What was missing is export on rfkill_toggle_radio to accomodate needs of thinkpad_acpi legacy sysfs and procfs interfaces otherwise the patch is really tiny. Sorry for attachment. -- Dmitry |
