linux-toradex.git/net/wireless/chan.c, branch v3.9.7

cfg80211: allow drivers to selectively disable 80/160 MHz

2013-02-15T08:41:38+00:00

Some drivers might support 80 or 160 MHz only on some
channels for whatever reason, so allow them to disable
these channel widths. Also maintain the new flags when
regulatory bandwidth limitations would disable these
wide channels.

Reviewed-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg

nl80211/cfg80211: add radar detection command/event

2013-02-15T08:40:18+00:00

Add new NL80211_CMD_RADAR_DETECT, which starts the Channel
Availability Check (CAC). This command will also notify the
usermode about events (CAC finished, CAC aborted, radar
detected, NOP finished).
Once radar detection has started it should continuously
monitor for radars as long as the channel is active.

This patch enables DFS for AP mode in nl80211/cfg80211.

Based on original patch by Victor Goldenshtein 

Signed-off-by: Simon Wunderlich 
[remove WIPHY_FLAG_HAS_RADAR_DETECT again -- my mistake]
Signed-off-by: Johannes Berg

cfg80211: adjacent 80+80 MHz channel segments are invalid

2013-01-03T12:01:32+00:00

In that case, it's really a 160 MHz channel, so disallow
this configuration.

Signed-off-by: Johannes Berg

cfg80211: check no-OFDM flag for channels wider than 20 MHz

2012-12-04T19:51:27+00:00

For channels wider than 20 MHz OFDM will be used, so when
checking whether or not a channel is usable, check for the
no-OFDM flag if the channel is wider than 20 MHz.

Signed-off-by: Johannes Berg

cfg80211: rework chandef checking and export it

2012-11-27T08:18:25+00:00

Some of the chandef checking that we do in cfg80211
to check if a channel is supported or not is also
needed in mac80211, so rework that a bit and export
the functions that are needed.

Signed-off-by: Johannes Berg

nl80211/cfg80211: support VHT channel configuration

2012-11-26T11:42:59+00:00

Change nl80211 to support specifying a VHT (or HT)
using the control channel frequency (as before) and
new attributes for the channel width and first and
second center frequency. The old channel type is of
course still supported for HT.

Also change the cfg80211 channel definition struct
to support these by adding the relevant fields to
it (and removing the _type field.)

This also adds new helper functions:
 - cfg80211_chandef_create to create a channel def
   struct given the control channel and channel type,
 - cfg80211_chandef_identical to check if two channel
   definitions are identical
 - cfg80211_chandef_compatible to check if the given
   channel definitions are compatible, and return the
   wider of the two

This isn't entirely complete, but that doesn't matter
until we have a driver using it. In particular, it's
missing
 - regulatory checks on the usable bandwidth (if that
   even makes sense)
 - regulatory TX power (database can't deal with it)
 - a proper channel compatibility calculation for the
   new channel types

Signed-off-by: Johannes Berg

cfg80211: pass a channel definition struct

2012-11-26T11:42:58+00:00

Instead of passing a channel pointer and channel type
to all functions and driver methods, pass a new channel
definition struct. Right now, this struct contains just
the control channel and channel type, but for VHT this
will change.

Also, add a small inline cfg80211_get_chandef_type() so
that drivers don't need to use the _type field of the
new structure all the time, which will change.

Signed-off-by: Johannes Berg

cfg80211: add cfg80211 exported function tracing

2012-10-18T08:53:38+00:00

Also add tracing to the API functions that drivers
(and mac80211) can call in cfg80211.

Signed-off-by: Beni Lev 
Reviewed-by: Emmanuel Grumbach 
Reviewed-by: Johannes Berg 
Signed-off-by: Johannes Berg

cfg80211: add wrappers for registered_device_ops

2012-10-18T08:53:37+00:00

This will allow adding central tracing like in mac80211.

Signed-off-by: Hila Gonen 
Reviewed-by: Emmanuel Grumbach 
Reviewed-by: Johannes Berg 
Signed-off-by: Johannes Berg

cfg80211: add P2P Device abstraction

2012-08-20T11:58:21+00:00

In order to support using a different MAC address
for the P2P Device address we must first have a
P2P Device abstraction that can be assigned a MAC
address.

This abstraction will also be useful to support
offloading P2P operations to the device, e.g.
periodic listen for discoverability.

Currently, the driver is responsible for assigning
a MAC address to the P2P Device, but this could be
changed by allowing a MAC address to be given to
the NEW_INTERFACE command.

As it has no associated netdev, a P2P Device can
only be identified by its wdev identifier but the
previous patches allowed using the wdev identifier
in various APIs, e.g. remain-on-channel.

Signed-off-by: Johannes Berg