All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Cc: linux-wireless@vger.kernel.org, victorg@ti.com,
	linville@tuxdriver.com, kgiori@qca.qualcomm.com,
	zefir.kurtisi@neratec.com, adrian@freebsd.org, j@w1.fi,
	coelho@ti.com, igalc@ti.com, nbd@nbd.name,
	mathias.kretschmer@fokus.fraunhofer.de,
	Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Subject: Re: [PATCHv8 2/3] mac80211: add radar detection command/event
Date: Wed, 06 Feb 2013 18:33:35 +0100	[thread overview]
Message-ID: <1360172015.7910.51.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <1359982200-2321-3-git-send-email-siwu@hrz.tu-chemnitz.de>

On Mon, 2013-02-04 at 13:49 +0100, Simon Wunderlich wrote:

>   *
>   * @channel: the channel to tune to
>   * @channel_type: the channel (HT) type
> + * @radar_enabled: whether radar detection is enabled on this channel

There's only one channel for ieee80211_conf ;-)

>  /**
> + * ieee80211_radar_detected - inform a configured connection that
> + * radar was detected on the current channel
> + *
> + * @vif: &struct ieee80211_vif pointer from the add_interface callback.
> + * @gfp: context flags.
> + */
> +void ieee80211_radar_detected(struct ieee80211_vif *vif, gfp_t gfp);

Given the way this works in cfg80211 and my comment there, it seems
pointless to report per vif, but rather should be per HW?

> +	res = ieee80211_vif_use_channel(sdata, chandef,
> +					IEEE80211_CHANCTX_SHARED);
> +	if (res)
> +		return -EBUSY;

return res? This really can't fail here (except for memory allocation
etc.) so -EBUSY is a bit odd.

> @@ -753,6 +753,9 @@ struct ieee80211_sub_if_data {
>  	int user_power_level; /* in dBm */
>  	int ap_power_level; /* in dBm */
>  
> +	bool radar_required;
> +	struct delayed_work dfs_cac_timer_work;

Does the work struct make sense here? It seems like an inherently global
operation, so should that be in ieee80211_local? We should check anyway
if radar detection is requested when it's already running, I guess.

> +++ b/net/mac80211/iface.c
> @@ -817,6 +817,15 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
>  
>  	cancel_work_sync(&sdata->recalc_smps);
>  
> +	cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);

OTOH, I guess if the interface is going away then you'd want to stop
radar detection if it was done for that interface, so in that sense it
makes sense per interface.

> @@ -1583,6 +1592,9 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
>  	spin_lock_init(&sdata->cleanup_stations_lock);
>  	INIT_LIST_HEAD(&sdata->cleanup_stations);
>  	INIT_WORK(&sdata->cleanup_stations_wk, ieee80211_cleanup_sdata_stas_wk);
> +	INIT_DELAYED_WORK(&sdata->dfs_cac_timer_work,
> +			  ieee80211_dfs_cac_timer_work);
> +

unneeded blank line

> +void ieee80211_dfs_cac_timer_work(struct work_struct *work)
> +{
> +	struct delayed_work *delayed_work =
> +		container_of(work, struct delayed_work, work);
> +	struct ieee80211_sub_if_data *sdata =
> +		container_of(delayed_work, struct ieee80211_sub_if_data,
> +			     dfs_cac_timer_work);
> +
> +	rtnl_lock();
> +	ieee80211_vif_release_channel(sdata);
> +	cfg80211_radar_event(sdata->dev, &sdata->vif.bss_conf.chandef,
> +			     NL80211_RADAR_CAC_FINISHED, GFP_KERNEL);
> +	rtnl_unlock();
> +}

Did you test your code with lockdep enabled? I'm almost certain using
rtnl_lock() isn't allowed on mac80211's workqueue.

> +void ieee80211_radar_detected(struct ieee80211_vif *vif, gfp_t gfp)

That "gfp" argument is misleading, ...

> +{
> +	struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
> +
> +	trace_api_radar_detected(sdata);
> +
> +	/* may happen to devices which have currently no BSS configured */
> +	if (!cfg80211_chandef_valid(&sdata->vif.bss_conf.chandef))
> +		return;
> +
> +	cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);

... since you do something that requires being able to sleep, hence the
only useful argument you could pass as gfp is GFP_KERNEL. However, not
being able to calls this from softirq or so is probably not desirable
for many drivers?

johannes


  reply	other threads:[~2013-02-06 17:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-04 12:49 [PATCHv8 0/3] Add DFS master ability Simon Wunderlich
2013-02-04 12:49 ` [PATCHv8 1/3] nl80211/cfg80211: add radar detection command/event Simon Wunderlich
2013-02-06 17:24   ` Johannes Berg
2013-02-07 11:00     ` Simon Wunderlich
2013-02-07 11:07       ` Johannes Berg
2013-02-04 12:49 ` [PATCHv8 2/3] mac80211: " Simon Wunderlich
2013-02-06 17:33   ` Johannes Berg [this message]
2013-02-07 11:08     ` Simon Wunderlich
2013-02-06 17:36   ` Johannes Berg
2013-02-07 11:10     ` Simon Wunderlich
2013-02-04 12:49 ` [PATCHv8 3/3] nl80211: allow DFS in start_ap Simon Wunderlich
2013-02-06 17:36   ` Johannes Berg
2013-02-07 11:11     ` Simon Wunderlich
2013-02-04 12:49 ` [PATCH 1/2] iw: add radar detect widths to phy info Simon Wunderlich
2013-02-04 12:50 ` [PATCH 2/2] iw: print DFS states for channels if available Simon Wunderlich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1360172015.7910.51.camel@jlt4.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=adrian@freebsd.org \
    --cc=coelho@ti.com \
    --cc=igalc@ti.com \
    --cc=j@w1.fi \
    --cc=kgiori@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mathias.kretschmer@fokus.fraunhofer.de \
    --cc=nbd@nbd.name \
    --cc=simon.wunderlich@s2003.tu-chemnitz.de \
    --cc=siwu@hrz.tu-chemnitz.de \
    --cc=victorg@ti.com \
    --cc=zefir.kurtisi@neratec.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.