Implement the new cfg80211 capability to enable mac80211-based drivers
to support for dynamic channel bandwidth changes (e.g., HT 20/40 MHz
changes).
Signed-off-by: Jouni Malinen <[email protected]>
---
net/mac80211/cfg.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index aaa59d7..1ce407a 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -3949,6 +3949,21 @@ static int ieee80211_set_qos_map(struct wiphy *wiphy,
return 0;
}
+static int ieee80211_set_ap_channel(struct wiphy *wiphy,
+ struct net_device *dev,
+ struct cfg80211_chan_def *chandef)
+{
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ int ret;
+ u32 changed = 0;
+
+ ret = ieee80211_vif_change_bandwidth(sdata, chandef, &changed);
+ if (ret == 0)
+ ieee80211_bss_info_change_notify(sdata, changed);
+
+ return ret;
+}
+
const struct cfg80211_ops mac80211_config_ops = {
.add_virtual_intf = ieee80211_add_iface,
.del_virtual_intf = ieee80211_del_iface,
@@ -4029,4 +4044,5 @@ const struct cfg80211_ops mac80211_config_ops = {
.start_radar_detection = ieee80211_start_radar_detection,
.channel_switch = ieee80211_channel_switch,
.set_qos_map = ieee80211_set_qos_map,
+ .set_ap_channel = ieee80211_set_ap_channel,
};
--
1.7.9.5
--
Jouni Malinen PGP id EFC895FA
On Mon, 2014-04-28 at 10:57 +0200, Michal Kazior wrote:
> > +static int ieee80211_set_ap_channel(struct wiphy *wiphy,
> > + struct net_device *dev,
> > + struct cfg80211_chan_def *chandef)
> > +{
> > + struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> > + int ret;
> > + u32 changed = 0;
> > +
>
> Shouldn't interface combinations be verified here? What if there was a
> bandwidth upgrade (after a downgrade) but in the meantime a vif with a
> to-be incompatible chandef was brought up?
Yeah that seems like a potential issue.
> I think the existing usage
> of ieee80211_vif_change_bandwidth() in ieee80211_config_bw() already
> suffers from this problem or am I missing something?
That sounds like you're arguing it should be fixed in a separate patch
to ieee80211_vif_change_bandwidth()? :)
johannes
On Mon, 2014-04-28 at 17:46 +0200, Johannes Berg wrote:
> > Shouldn't interface combinations be verified here? What if there was a
> > bandwidth upgrade (after a downgrade) but in the meantime a vif with a
> > to-be incompatible chandef was brought up?
>
> Yeah that seems like a potential issue.
Hm, wait, isn't this addressed by this code in
ieee80211_vif_change_bandwidth():
ctx = container_of(conf, struct ieee80211_chanctx, conf);
if (!cfg80211_chandef_compatible(&conf->def, chandef)) {
ret = -EINVAL;
goto out;
}
johannes
On 28 April 2014 17:47, Johannes Berg <[email protected]> wrote:
> On Mon, 2014-04-28 at 17:46 +0200, Johannes Berg wrote:
>
>> > Shouldn't interface combinations be verified here? What if there was a
>> > bandwidth upgrade (after a downgrade) but in the meantime a vif with a
>> > to-be incompatible chandef was brought up?
>>
>> Yeah that seems like a potential issue.
>
> Hm, wait, isn't this addressed by this code in
> ieee80211_vif_change_bandwidth():
>
> ctx = container_of(conf, struct ieee80211_chanctx, conf);
> if (!cfg80211_chandef_compatible(&conf->def, chandef)) {
> ret = -EINVAL;
> goto out;
> }
Yeah, you're right.
Michał
On 28 April 2014 10:22, Jouni Malinen <[email protected]> wrote:
> Implement the new cfg80211 capability to enable mac80211-based drivers
> to support for dynamic channel bandwidth changes (e.g., HT 20/40 MHz
> changes).
>
> Signed-off-by: Jouni Malinen <[email protected]>
> ---
> net/mac80211/cfg.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index aaa59d7..1ce407a 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -3949,6 +3949,21 @@ static int ieee80211_set_qos_map(struct wiphy *wiphy,
> return 0;
> }
>
> +static int ieee80211_set_ap_channel(struct wiphy *wiphy,
> + struct net_device *dev,
> + struct cfg80211_chan_def *chandef)
> +{
> + struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> + int ret;
> + u32 changed = 0;
> +
Shouldn't interface combinations be verified here? What if there was a
bandwidth upgrade (after a downgrade) but in the meantime a vif with a
to-be incompatible chandef was brought up? I think the existing usage
of ieee80211_vif_change_bandwidth() in ieee80211_config_bw() already
suffers from this problem or am I missing something?
> + ret = ieee80211_vif_change_bandwidth(sdata, chandef, &changed);
> + if (ret == 0)
> + ieee80211_bss_info_change_notify(sdata, changed);
> +
> + return ret;
> +}
Michał