On Fri, Oct 19, 2012 at 3:47 PM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> From: Johannes Berg <johannes.berg@xxxxxxxxx>
>
> Depending on the driver, a lot of setup may be
> necessary to start operating as an AP, some of
> which may fail. To make it easier to handle,
> add explicit AP start/stop operations.
>
> ...
>
> This would make the code in iwlwifi a lot simpler
> as having bss_info_change do everything depending
> on whether the beacon was enabled/disabled etc.
> is tricky to get right, the explicit operations
> make it easier.
>
is it really different from acting upon BSS_CHANGED_BEACON_ENABLED
(when vif == ap)?
> ieee80211_bss_info_change_notify(sdata, changed);
>
> + err = drv_start_ap(sdata->local, sdata);
> + if (err) {
> + old = rtnl_dereference(sdata->u.ap.beacon);
> + if (old)
> + kfree_rcu(old, rcu_head);
> + RCU_INIT_POINTER(sdata->u.ap.beacon, NULL);
> + return err;
they'll probably be mutually exclusive, but i think you should still
notify BSS_CHANGED_BEACON_ENABLED after removing the beacon (or more
easily, call ieee80211_bss_info_change_notify only after this block).
>
> +DEFINE_EVENT(local_sdata_evt, drv_start_ap,
> + TP_PROTO(struct ieee80211_local *local,
> + struct ieee80211_sub_if_data *sdata),
> + TP_ARGS(local, sdata)
> +);
adding traces for ssid and beacon_int might be nice :)
what about other direct notification of BSS_CHANGED_BEACON_ENABLED
(like in offchannel and ieee80211_do_stop)? should we call
start_ap/stop_ap there as well?
Eliad.
--
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
