Hi Luiz, > > adapter_up() is more of a callback that's responsible for doing the > > necessary initializations *after* adapter has just gone up, so it's not > > the right function to call when you want to bring it up (i.e. call the > > ioctl). I believe all code paths for bringing the adapter up call set_mode > > in src/adapter.c which in turn calls adapter_ops->set_powered (which calls > > the ioctl in the case of hciops). > > > > So having a btd_adapter_set_powered exported to plugins (which is what > > Bastien's patch seems to do) makes sense to me in this case. I might > > actually need something similar for maemo in order to handle our offline > > mode better (maemo specific plugin to catch the MCE offline mode signal > > and then call btd_adapter_set_powered). > > Yep, sounds good to me too, plugins can have references to adapters so > I guess this is perfectly fine. Also I don't think there is much to be > protected here since powered property is readwrite and can be changed > by any dbus client. This also makes me wonder what is the purpose of > rfkill when we can anyone can set powered directly? if it is rfkilled, then hciconfig hci0 up will return -ERFKILL. We fixed this for the 2.6.31 kernel. WiFi behaves the same now. So you can't just go ahead and bring it up again, you do have to unblock it. And you can only unblock softkilled devices. If it is hardkilled via a hardware switch for example, there is nothing you can do to bring it back up except flipping the hardware switch. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
