Johannes Berg wrote:
On Tue, 2010-06-01 at 21:28 +0300, Maxim Levitsky wrote:
wireless: allow to retrieve the channel set on monitor interface
This will allow to preserve compatibility with userspace
Signed-off-by: Maxim Levitsky <maximlevitsky@xxxxxxxxx>
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index b01a6f6..09d979b 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -49,9 +49,12 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
{
struct ieee80211_channel *chan;
int result;
+ struct wireless_dev *mon_dev = NULL;
- if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR)
+ if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR) {
+ mon_dev = wdev;
wdev = NULL;
+ }
if (wdev) {
ASSERT_WDEV_LOCK(wdev);
@@ -76,5 +79,8 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
if (wdev)
wdev->channel = chan;
+ if (mon_dev)
+ mon_dev->channel = chan;
+
This won't quite work. monitor interfaces are always slaves in the sense
that their channel setting never takes precedence over anything, so if
you add another interface and do something there, the hardware will
happily channel switch away from the monitor channel, but it will still
report the old channel here that you set.
I have no idea how to _properly_ fix this though, since eventually we'll
have a situation where you can have multiple interfaces active on
different channels, so that monitors don't have a fixed channel anyway.
Maybe this patch is sufficient since it works in the case people care
about when they _only_ have a monitor interface, but I think it'd be
nicer if it wouldn't report anything in the other cases.
Is this a NACK or a "I wish there was a better way to do this but I'll
allow it until a better way if found"?
-Rick
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
