Hi Helmut, On Thu, 2009-03-26 at 13:58 -0700, Helmut Schaa wrote: > Am Donnerstag, 26. März 2009 schrieb reinette chatre: > > On Thu, 2009-03-26 at 12:49 -0700, Helmut Schaa wrote: > > > Am Donnerstag, 26. März 2009 schrieb reinette chatre: > > > > On Thu, 2009-03-26 at 12:11 -0700, Helmut Schaa wrote: > > > > > Am Donnerstag, 26. März 2009 schrieb reinette chatre: > > > > > > On Thu, 2009-03-26 at 10:50 -0700, Helmut Schaa wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Am Donnerstag, 26. März 2009 schrieb Reinette Chatre: > > > > > > > > From: Wey-Yi Guy <wey-yi.w.guy@xxxxxxxxx> > > > > > > > > > > > > > > > > Remove STATUS_ALIVE checking when HW RF KILL disabled, the bit get > > > > > > > > clear in __iwl_down() function; the additional checking will fail and > > > > > > > > cause RF can not be turn back on. > > > > > > > > > > > > > > Are you sure this is needed? I'd argue we should only restart the adapter > > > > > > > if it was alive when it got rf_killed. In case the adapter was rf_killed > > > > > > > while the interface was down I don't think we want to restart the adapter > > > > > > > immediately but first when the interface is taken up again. > > > > > > > > > > > > We also need to consider if a suspend/resume happens in the middle. > > > > > > Without the patch, if you enable rfkill, suspend, resume, disable > > > > > > rfkill, then your interface cannot be brought up. > > > > > > > > > > I guess you refer to the situation where the interface is up, right? > > > > > Something like: > > > > > > > > > > - ifconfig wlan0 up > > > > > - press killswitch (kill wireless) > > > > > - suspend > > > > > - resume > > > > > - press killswitch (enable wireless) > > > > > - here the interface should still be up > > > > > > > > > > As the interface is/was up, mac80211's resume handler should restart the > > > > > adapter and thus we wouldn't need to restart the adapter in the > > > > > rfkill-handler, or did I miss anything? > > > > > > > > Yes, the resume handler will start the adapter (call "start"), but the > > > > actions done by it will exit early because of rfkill being enabled. The > > > > STATUS_ALIVE bit will thus not be set after this is completed. Later, > > > > when user disables rfkill, we want to restart the adapter to get all > > > > this corrected, but this call currently fails because of this check. > > > > > > Got it, thanks for the explanation. > > > > > > Nevertheless, removing the check will result in restarting the adapter even > > > if the interface is down. So, I agree that we have a problem here but I do > > > not agree with the solution ;) > > > > I agree that it is not efficient ... but it seems harmless. > > Assume the following situation: > > You only have one killswitch for both, wireless and bluetooth. The wireless > interface is down because it is unused and the user wants to use bluetooth > and enables it via the killswitch which also means that wireless gets > unkilled. Now restarting the adapter needs more power then keeping the > adapter down. In short: if the interface is down the user (space) does not > want to use the interface and probably wants to save power as well. Your measurements are very fine grained :) Will this be measureable? Right now things do not work and this patch fixes it. > > > Maybe taking the interface up (not only pseudo-up, as done currently) should > > > be allowed even if wireless is killed? We already allow the interface to > > > stay up when the adapter gets rfkilled. > > > > Knowing that rfkill is enabled enables us to save power by not bringing > > everything up. > > Yes, but user (space) knows that the wireless card consumes more power if the > interface is up. And if you use NM for example it will just take the interface > down when the killswitch gets activated. > Another solution would be to > 1) not allow the interface to go up when it is rfkilled, and We currently do this. > 2) take the interface down when it gets rfkilled > > However, I'm not sure if 2 is possible without help of mac80211 and if it > makes sense to change an interface state from within the driver. Like you say ... probably not the driver's place to do this. Reinette -- 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
