On Thu, 2008-12-04 at 13:25 -0800, Reinette Chatre wrote: > ieee80211_hw_config can return an error when the hardware > has rfkill enabled. A WARN_ON() is too harsh for this > failure as it is a valid scenario. Only comment this warning > as we would like to have it back when rfkill is integrated into > mac80211. > > Also reintroduce number of printks that will happen in this case. > > This patch essentially reverts patch: > 5f0387fc3337ca26f0745f945f550f0c3734960f > "mac80211: clean up ieee80211_hw_config errors" > > Things not reverted is the reintroduction of a comment > and debug statement. > > Signed-off-by: Reinette Chatre <reinette.chatre@xxxxxxxxx> > --- > There are several places where ieee80211_hw_config's return code is not > checked. I did not change those as it appears to be intended considering > that the patch being reverted had nothing to do with them not using the > return code. > > It may also be that in this patch only the second hunk be necessary. Please > provide feedback in this regard. I suppose the probability of the beacon interval changing is rather low, but should we propagate the error in that case rather than just using -EINVAL? The scanning hunks I don't really care about, though it does seem a little pointless to print something when changing channel fails, that must be one of the most obvious failure modes and also rather unlikely. Also, that might actually trigger with iwlwifi too in which case every scan would log it, and there can be lots of scans with NM over time. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
