This reverts commit 2e48928d.

Those functions are needed and should not be removed, or
there is no way to set the rfkill led trigger name.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There's no need to carry around a return value
that is always NETDEV_TX_OK anyway.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

In multi-channel scenarios, the channel that we will
transmit a probe request on isn't always the current
channel (which will be NULL anyway) but will instead
be the channel that the AP is on. Pass the channel
to the ieee80211_send_probe_req() function so it can
be used in the different scenarios. The scan code
continues to pass the current channel, of course.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There's no need to BUG_ON when a driver registers
invalid operations, warn and return an error.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The optimisation of scanning only on the current
channel should check the operating channel. Also
modify it to compare channel pointer rather than
the frequency.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Even for single-channel devices it is possible that we
switch the channel temporarily (e.g. for scanning) but
while doing so process a received frame that was still
received on the old channel, so checking the current
band is racy. Use the band from status instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

With the move to multi-channel and away from
drv_config(), hw.conf.channel will not always
be set, only for devices using the current API
instead of the new channel context APIs. Check
the channel is set before adding its frequency
to the trace data.

Also break some overly long lines in the code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Using hw.conf.channel is wrong as it could be the
temporary channel if the station is added from the
workqueue while the device is already on another
channel. Use oper_channel instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

You can now get these values through iw, and
they conflict with multi-channel work.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

In ieee80211_beacon_get_tim() we can use the
txrc.sband instead of a separate local variable.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Using local->_oper_channel_type in the mesh code is
completely wrong as this value is the combination
of the various interface channel types and can be
a different value from the mesh interface in case
there are multiple virtual interfaces.

Use sdata->vif.bss_conf.channel_type instead as it
tracks the per-vif channel type.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There's no need to use a single scratch buffer and
calculate offsets into it, just use two separate
buffers for the separate variables.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Advertise support for P2P Device in hwsim
to be able to test it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Some devices like the current iwlwifi implementation
require that the P2P interface address match the P2P
Device address (only one P2P interface is supported.)
Add the HW flag IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF
that allows drivers to request that P2P Interfaces
added while a P2P Device is active get the same MAC
address by default.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

After cfg80211 got a P2P Device abstraction, add
support to mac80211. Whether it really is supported
or not will depend on whether or not the driver has
support for it, but mac80211 needs to change to be
able to support drivers that need a P2P Device.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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 <johannes.berg@intel.com>

There's no need to declare the function in the
header file since it's only used in a single
place, so make it static.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The channel switch IE has a fixed size, so we can
discard it in parsing if it's not the right size
and use the right struct pointer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The time until the channel switch is in TU,
not in milliseconds, so use TU_TO_EXP_TIME()
to correctly program the timer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Clean up the CSA handling code by moving some
of it out of the if and using a C99 initializer
for the struct passed to the driver method.

While at it, also add a comment that we should
wait for a beacon after switching the channel.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There's no need to copy the BSSID just to print
it, remove the unnecessary variable.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Support getting A-MPDU status information from the
drivers and reporting it to userspace via radiotap
in the standard fields.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Define the A-MPDU status field in radiotap, also
update the radiotap parser for it and the MCS field
that was apparently missed last time.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

In IBSS it is possible that the supported rates set for a station changes over
time (e.g. it gets first initialised as an empty set because of no available
information about rates and updated later). In this case the driver has to be
notified about the change in order to update its internal table accordingly (if
needed).

This behaviour is needed by all those drivers that handle rc internally but
leave stations management to mac80211
Reported-by: Gui Iribarren <gui@altermundi.net>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
[Johannes - add docs, validate IBSS mode only, fix compilation]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Use skb_queue_walk_safe instead, and fix a few issues:

	- didn't free old skbs on moving
	- didn't react to failed skb alloc
	- needlessly held a local pointer to the destination frame queue
	- didn't check destination queue length before adding skb
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Since all we really want is just to iterate over all skbs, do just that
and avoid (de)queueing to a clusmy tmpq.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This could take a while (100ms+) and may delay sending assoc resp
in AP mode with WPS or P2P GO (as setting the probe resp takes place
there). We've encountered situations where the delay was big enough
to cause connection problems with devices like Galaxy Nexus.
Switch to using call_rcu with a free handler.

[Arik - rework to use plain buffer and instead of skb]
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Although adding an IE is almost guaranteed to succeed since we already
accounted for its length while allocating the skb, we should still free
the skb in case of failure.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

It doesn't make a lot of sense to wait for an ack in response to a
peering close frame since either peer in this exchange could be going
down.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This function was only used by mesh, and not really needed since any
interface-specific cleanup already happens in the netdev handlers.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

It is not necessary to stop the mesh beacon in the mac80211 ndo_stop
handler, since cfg80211 has already left the mesh on NETDEV_GOING_DOWN
notification.

Also some improvements to ieee80211_stop_mesh():

 - flush mpath entries.
 - flush sta entries per-sdata so we don't remove entries belonging to
   other vifs on the same hw.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When associating anew, the old station MLME flags should
be cleared. The only exception is the 40 MHz disable
flag as it might have been set while the channel was set
in a previous authentication attempt so it needs to be
kept intact.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Instead of memset().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Enable the carrier on WDS type interfaces only
after having added the station entry for the
WDS peer so outgoing frames will find it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Instead of assuming the carrier is on all
the time in mesh manage it with joining
and leaving the mesh.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Since we only need the band, remove the channel
pointer from struct ieee80211_tx_data and also
assign it properly, depending on context, to the
correct operating or current channel.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When sending probe requests, e.g. during software scanning,
these will go out on the *current* channel, so their IEs
need to be built from the current channel. At other times,
e.g. for beacons or probe request templates, the IEs will
be used on the *operating* channel and using the current
channel instead might result in errors.

Add the appropriate parameters to respect the difference.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Using hw.conf.channel is wrong as it could be the
temporary channel if any function like the beacon
get function is called while scanning or during
other temporary out-of-channel activities.

Use oper_channel instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Using hw.conf.channel is wrong as it could be the
temporary channel if any function like the beacon
get function is called while scanning or during
other temporary out-of-channel activities.

Use oper_channel instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Using hw.conf.channel is wrong as it could be the
temporary channel if any function like the beacon
get function is called while scanning or during
other temporary out-of-channel activities.

Use oper_channel instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>