On Mon, 2009-03-30 at 17:48 -0300, Henrique de Moraes Holschuh wrote: > Yes, thinkpad-acpi wants it. It uses that to make sure the bluethooth > and wwan rfkill _global_ state is kept across machine shutdown and > reboots (I can't do that for UWB because Lenovo didn't add persistence > for UWB for some reason). Yeah, I've added it back already :) > 1. thinkpad-acpi loads > 1a. reads radio states from firmware, and stores to rfkill core > default state for the specific radio type > 1b. registers the rfkill switch. The core will cause the just > registered rfkill switch state to be changed to match the > current global state for that switch type... which probably > is what thinkpad-acpi tried to set in 1a. Yeah -- I need to add back 1b; I removed it for now because it goes like this: driver - rfkill_register rfkill - rfkill_register rfkill - set radio driver - set radio <--- deadlock if this needs lock This I need to schedule that away. > > state should be set for the devices it applies to, but it seems that if > > the master rfkill switch is set to "transmitter off" then one needs to > > set the default state (for all USB transmitters etc) to off, correct? > > Well, the default is applied to a _type_, so it is valid for all > switches of that type. Right. > It is probably a good idea to have the rfkill core sanitize the > attempt to set the default state, and force it to "block" if EPO is > active (I don't recall if I checked for this failure mode in the old > code). No, but it rejects any calls to set the default state when any rfkill struct has been registered already. So this isn't a concern. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
