mrv8k has commands that get called before and after the scan has been
done to save and restore hardware state. Add optional callbacks to
mac80211 to enable low-level drivers to know when the stack is about to
start scanning, and when it's done.
Signed-off-by: Dan Williams <[email protected]>
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 7ab4ff6..b84e8ac 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1139,6 +1139,10 @@ enum ieee80211_ampdu_mlme_action {
* ieee80211_ampdu_mlme_action. Starting sequence number (@ssn)
* is the first frame we expect to perform the action on. notice
* that TX/RX_STOP can pass NULL for this parameter.
+ *
+ * @prescan: Notifies low level driver that a software scan is about to happen.
+ *
+ * @postscan: Notifies low level driver that software scanning is done.
*/
struct ieee80211_ops {
int (*tx)(struct ieee80211_hw *hw, struct sk_buff *skb);
@@ -1190,6 +1194,8 @@ struct ieee80211_ops {
int (*ampdu_action)(struct ieee80211_hw *hw,
enum ieee80211_ampdu_mlme_action action,
const u8 *addr, u16 tid, u16 *ssn);
+ int (*prescan)(struct ieee80211_hw *hw);
+ int (*postscan)(struct ieee80211_hw *hw);
};
/**
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 55659a7..4bee2a7 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3850,6 +3850,10 @@ void ieee80211_scan_completed(struct ieee80211_hw *hw)
netif_tx_unlock_bh(local->mdev);
+ /* call postscan outside locks because drivers may need to sleep */
+ if (local->ops->postscan)
+ local->ops->postscan(local_to_hw(local));
+
rcu_read_lock();
list_for_each_entry_rcu(sdata, &local->interfaces, list) {
@@ -4045,6 +4048,10 @@ static int ieee80211_sta_start_scan(struct net_device *dev,
local->scan_band = IEEE80211_BAND_2GHZ;
local->scan_dev = dev;
+ /* call prescan outside locks because drivers may need to sleep */
+ if (local->ops->prescan)
+ local->ops->prescan(local_to_hw(local));
+
netif_tx_lock_bh(local->mdev);
local->filter_flags |= FIF_BCN_PRBRESP_PROMISC;
local->ops->configure_filter(local_to_hw(local),
On Tue, 2008-06-24 at 07:15 -0400, Dan Williams wrote:
> On Tue, 2008-06-24 at 10:55 +0200, Johannes Berg wrote:
> > On Sun, 2008-06-22 at 11:43 -0400, Dan Williams wrote:
> > > mrv8k has commands that get called before and after the scan has been
> > > done to save and restore hardware state. Add optional callbacks to
> > > mac80211 to enable low-level drivers to know when the stack is about to
> > > start scanning, and when it's done.
> >
> > I'm not entirely against this, but does it mean the driver will not work
> > with the userspace MLME that does scanning itself in userspace too?
>
> Probably not? Both TopDog (linville's marvell.git and your
> marvell.tar.bz2) both do this. It's too early to tell whether we can
> get along without it since the driver isn't functional enough yet.
Hm. Could we leave it out of mac80211 for now then until you know?
> BTW, where'd you get marvell.tar.bz2 from?
No idea, I don't remember, I could probably dig it up in my email but
didn't find it quickly right now.
johannes
> > > BTW, where'd you get marvell.tar.bz2 from?
> >
> > No idea, I don't remember, I could probably dig it up in my email but
> > didn't find it quickly right now.
>
> If it's not too much trouble, would be nice to know.
I dug a little deeper and realised that I posted to linux-wireless when
I found the code. It's from some router GPL code-drop tarball, possibly
linksys, but I don't really remember, sorry.
johannes
On Tue, 2008-06-24 at 10:55 +0200, Johannes Berg wrote:
> On Sun, 2008-06-22 at 11:43 -0400, Dan Williams wrote:
> > mrv8k has commands that get called before and after the scan has been
> > done to save and restore hardware state. Add optional callbacks to
> > mac80211 to enable low-level drivers to know when the stack is about to
> > start scanning, and when it's done.
>
> I'm not entirely against this, but does it mean the driver will not work
> with the userspace MLME that does scanning itself in userspace too?
Probably not? Both TopDog (linville's marvell.git and your
marvell.tar.bz2) both do this. It's too early to tell whether we can
get along without it since the driver isn't functional enough yet.
BTW, where'd you get marvell.tar.bz2 from?
Dan
On Tue, 2008-06-24 at 13:21 +0200, Johannes Berg wrote:
> On Tue, 2008-06-24 at 07:15 -0400, Dan Williams wrote:
> > On Tue, 2008-06-24 at 10:55 +0200, Johannes Berg wrote:
> > > On Sun, 2008-06-22 at 11:43 -0400, Dan Williams wrote:
> > > > mrv8k has commands that get called before and after the scan has been
> > > > done to save and restore hardware state. Add optional callbacks to
> > > > mac80211 to enable low-level drivers to know when the stack is about to
> > > > start scanning, and when it's done.
> > >
> > > I'm not entirely against this, but does it mean the driver will not work
> > > with the userspace MLME that does scanning itself in userspace too?
> >
> > Probably not? Both TopDog (linville's marvell.git and your
> > marvell.tar.bz2) both do this. It's too early to tell whether we can
> > get along without it since the driver isn't functional enough yet.
>
> Hm. Could we leave it out of mac80211 for now then until you know?
Fair enough.
> > BTW, where'd you get marvell.tar.bz2 from?
>
> No idea, I don't remember, I could probably dig it up in my email but
> didn't find it quickly right now.
If it's not too much trouble, would be nice to know.
Thanks!
Dan
On Sun, 2008-06-22 at 11:43 -0400, Dan Williams wrote:
> mrv8k has commands that get called before and after the scan has been
> done to save and restore hardware state. Add optional callbacks to
> mac80211 to enable low-level drivers to know when the stack is about to
> start scanning, and when it's done.
I'm not entirely against this, but does it mean the driver will not work
with the userspace MLME that does scanning itself in userspace too?
johannes
On Wed, 2008-09-10 at 09:51 +0200, Johannes Berg wrote:
> On Sun, 2008-06-22 at 11:43 -0400, Dan Williams wrote:
> > mrv8k has commands that get called before and after the scan has been
> > done to save and restore hardware state. Add optional callbacks to
> > mac80211 to enable low-level drivers to know when the stack is about to
> > start scanning, and when it's done.
>
> Was just talking to Sujith about something on IRC and realised that
> maybe this is required to turn off IBSS beaconing when leaving the
> channel for a scan?
Most cards to the beaconing in hardware/firmware with a given template,
right? If so this sounds quite plausible. Does beaconing not get
paused now?
Dan
On Sun, 2008-06-22 at 11:43 -0400, Dan Williams wrote:
> mrv8k has commands that get called before and after the scan has been
> done to save and restore hardware state. Add optional callbacks to
> mac80211 to enable low-level drivers to know when the stack is about to
> start scanning, and when it's done.
Was just talking to Sujith about something on IRC and realised that
maybe this is required to turn off IBSS beaconing when leaving the
channel for a scan?
johannes
On Wed, 2008-09-10 at 09:09 -0400, Dan Williams wrote:
> On Wed, 2008-09-10 at 09:51 +0200, Johannes Berg wrote:
> > On Sun, 2008-06-22 at 11:43 -0400, Dan Williams wrote:
> > > mrv8k has commands that get called before and after the scan has been
> > > done to save and restore hardware state. Add optional callbacks to
> > > mac80211 to enable low-level drivers to know when the stack is about to
> > > start scanning, and when it's done.
> >
> > Was just talking to Sujith about something on IRC and realised that
> > maybe this is required to turn off IBSS beaconing when leaving the
> > channel for a scan?
>
> Most cards to the beaconing in hardware/firmware with a given template,
> right?
Yes, many do.
> If so this sounds quite plausible. Does beaconing not get
> paused now?
I'd guess not, but I haven't actually tested.
johannes
On Wed, 2008-09-10 at 09:51 +0200, Johannes Berg wrote:
> On Sun, 2008-06-22 at 11:43 -0400, Dan Williams wrote:
> > mrv8k has commands that get called before and after the scan has been
> > done to save and restore hardware state. Add optional callbacks to
> > mac80211 to enable low-level drivers to know when the stack is about to
> > start scanning, and when it's done.
>
> Was just talking to Sujith about something on IRC and realised that
> maybe this is required to turn off IBSS beaconing when leaving the
> channel for a scan?
On the other hand, we should add API to turn off beaconing anyway, which
userspace might actually request. And when we do that, we can use it to
turn off IBSS beaconing.
The beaconing API in total is a bit strange, we tell the driver when the
beacon changes and it can then request one, but we never tell it when to
start/stop beaconing, which means that currently your driver has to
figure to start out beaconing on the first beacon change, and then
cannot possibly stop again... We can return NULL from the beacon get
function but that could be an error condition too...
I think we just need to add start/stop beacon bits, and then we can use
them around a scan too, thoughts?
johannes
Johannes Berg wrote:
> The beaconing API in total is a bit strange, we tell the driver when the
> beacon changes and it can then request one, but we never tell it when to
> start/stop beaconing, which means that currently your driver has to
> figure to start out beaconing on the first beacon change, and then
> cannot possibly stop again... We can return NULL from the beacon get
> function but that could be an error condition too...
The original design was for AP mode only and the assumption was that
Beacon transmission is enabled pretty much all the time. Returning NULL
was used if ever needed to stop Beacon transmission for some period of
time.
> I think we just need to add start/stop beacon bits, and then we can use
> them around a scan too, thoughts?
That sounds reasonable.
- Jouni
On Thu, 2008-09-11 at 23:35 +0300, Jouni Malinen wrote:
> Johannes Berg wrote:
> > The beaconing API in total is a bit strange, we tell the driver when the
> > beacon changes and it can then request one, but we never tell it when to
> > start/stop beaconing, which means that currently your driver has to
> > figure to start out beaconing on the first beacon change, and then
> > cannot possibly stop again... We can return NULL from the beacon get
> > function but that could be an error condition too...
>
> The original design was for AP mode only and the assumption was that
> Beacon transmission is enabled pretty much all the time. Returning NULL
> was used if ever needed to stop Beacon transmission for some period of
> time.
That can only work with some hardware though, if the hardware doesn't
beacon from a template.
> > I think we just need to add start/stop beacon bits, and then we can use
> > them around a scan too, thoughts?
>
> That sounds reasonable.
I'll take a look sometime.
johannes