On Fri, Sep 26, 2008 at 12:10 AM, Ivo van Doorn <ivdoorn@xxxxxxxxx> wrote: > Hi, > >> Currently mac80211 is not notified about rfill state of low level driver >> and doesn't now when it's disconnected and when to restart connection >> There also there is conflict or no synchronization between 'wext txpower >> disable' and rfkill events coming from rfkill subsystem >> >> This patch is just a sketch of possible solution, it probably even doesn't >> compile > > I am not sure if registring a notifier would be the best solution, > persionally I was thinking of implementing the rfkill structure into ieee80211_local > and make it listen to events directly. > > Through a small callback function drivers can easily report their rfkill events > to mac80211 which in turn will call rfkill_force_state(). > On the other hand, perhaps notifications might work better, depends on what > the drivers like better. That's definitely other option we wanted to suggest that mac80211 would register itself to rfkill subsystem and will provide to driver appropriate callbacks. The question is how drivers vary in the rfkil implementation and whether it wouldn't be more complex, in that case the notification is quite clean solution. > As mentioned in a discussion on the list a few days ago, SOFT_BLOCKED > is not for 'iwconfig txpower off' commands or any other commands coming > from userspace. Those are not HW triggered rfkill events. > That means that the only change needed in ieee80211_ioctl_siwtxpower() is > only allowing the enabling of the radio when RFKILL is not set to BLOCKED. That's just complicates everything and moving the policy decisions to the driver after all even form txpower off you implement it as soft rfkill. I would suggest just remove the support for txpower off in mac80211 now when appropriate or sync it with soft block after all it coming from user space as a software event. Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
