Hi Johannes, Thanks for you thoughts on this. Especially the last remark was reason for me to verify several usage scenarios. I ran into a issue with unloading the driver module while it was in blocked rfkill state and polling was active. Turns out the call to ieee80211_unregister_hw takes a loooong time before it returns and dmesg shows message from unregister_netdevice which seems related about refcount not being zero. This is only observed in this scenario. Any suggestion on how to handle this? Gr. AvS |-----Original Message----- |From: Johannes Berg [mailto:johannes@xxxxxxxxxxxxxxxx] |Sent: Monday, January 10, 2011 8:45 PM |To: Arend Van Spriel |Cc: linux-wireless@xxxxxxxxxxxxxxx |Subject: Re: cfg80211 rfkill interface | |Hi Arend, | |> I am looking into implementing rfkill into our brcm80211 open-source |> driver. Our driver detects disable switch by an interrupt, but |> switching back does not give an interrupt. | |Interesting, but I guess it makes some sense. | |> For the latter I wanted to use the rfkill_poll callback and |> wiphy_rfkill_start_polling. | |Right, makes sense. | |> However, I tried a wiphy_rfkill_stop_polling in the rfkill_poll |> callback when rf is unblocked, and this resulted in a system hang. | |Yeah, I'm not surprised. start_polling will work from anywhere, but |stop_polling needs to actually completely sync the poll stop so it can't |be done from within the poll or from within any rfkill callbacks. | |> So I moved the wiphy_rfkill_stop_polling to the start callback. Does |> that make sense or is there another way you would recommend? | |I think that makes sense. | |However, where do you start polling? You have to poll even if the device |is not start()ed, I guess? | |johannes | -- 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
