When submitting a patch, please state what drivers you are really
changing,
your mail subject suggested a change to the dscape stack itself.
Since I look at those patches at an irregular basis, while I am always
checking for rt2x00 related patches I could have missed this one.
Especially when you don't CC the driver maintainers about the patch
for their drivers.
Also I think most people would prefer if you split up patches when it
affects multiple drivers,
in this case rt2x00 and adm8211.
what I meant with this title is this patch is for all d80211-based
current drivers of Linville's wireless-dev,
but I see your point...
diff --git a/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
b/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
index 946cf86..1d45851 100644
--- a/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
@@ -1877,7 +1877,9 @@ rt2400pci_config_interface(struct net_de
if (rt2x00pci->type == IEEE80211_IF_TYPE_MNTR)
return 0;
- rt2400pci_config_bssid(rt2x00pci, conf->bssid);
+ if (conf->type == IEEE80211_IF_TYPE_STA ||
+ conf->type == IEEE80211_IF_TYPE_IBSS)
+ rt2400pci_config_bssid(rt2x00pci, conf->bssid);
Should rt2400pci_config_bssid not simply run a check to see if the
bssid argument is valid?
This would prevent the risk of having a similar problem when the
function is called from somewhere else as well.
I was thinking a function named xxx_config_bssid() assumes a valid bssid
pointer,
- I would even add BUG_ON(conf->bssid==NULL) in xxx_config_bssid().
And hw->interface already already some tests with conf->type.
And net/d80211 uses same kind of test before setting conf->bssid.
anyway I don't mind you make the patch the other way.
Same comment applies for rt2500pci and rt61pci.
Any particular reason why you applied this change to PCI drivers in
rt2x00 only and not to the USB drivers?
likely because I have only a pci card :-)
USB drivers needs same change too.
Thanks,
Jean-Mickael
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
