Merge from head

Merge ^/head r288197 through r288456.

Merge from head

Sync up with head (up to r288341).

Perform some rather amusing layering violations to add mbuf tags to the
net80211 receive path. This allows drivers (notably USB right now, but
anything/everything!) to optionally defer bulk RX of 80

Perform some rather amusing layering violations to add mbuf tags to the
net80211 receive path. This allows drivers (notably USB right now, but
anything/everything!) to optionally defer bulk RX of 802.11 frames until
/outside/ of the driver lock(s), rather than doing:

UNLOCK(sc);
ieee80211_input*()
LOCK(sc);

.. which is really stupid.

The existing API is maintaned - if ieee80211_input() / ieee80211_input_all()
is called then the RSSI/NF values are used. If the MIMO versions are called
with a given rx status pointer then it's used. Else, it'll use whatever
is in the RX mbuf tag.

show more ...

Catch up with HEAD (r280229-r284686).

Merge from head

Merged ^/head r283871 through r284187.

Fix the build by hiding ieee80211_add_xmit_params and
ieee80211_get_xmit_params from userspace.

First pass of adding transmit parameters as an option for outbound
802.11 mbufs.

The raw transmit path currently doesn't make it easy to queue
these frames:

* there's no node reference stored in th

First pass of adding transmit parameters as an option for outbound
802.11 mbufs.

The raw transmit path currently doesn't make it easy to queue
these frames:

* there's no node reference stored in the mbuf, like for the normal
path, and
* the bpf supplied raw transmit parameters (rate, rts/cts, etc)
are passed in as an argument, not as an mbuf tag.

In order to support driver queuing of these frames, we need to
be able to put the above into the mbuf before the driver gets it,
so the driver /can/ put it into a queue if needed.

Use an mbuf tag and for now just verbatim copy the bpf parameters
into it. Later on it may grow to include more options but this
will do for now.

Why would you want to queue raw frames? Well, in the case of
iwn(4), we can't send the firmware frames to transmit before
we hear a beacon - the firmware will consider passive channels
as unavailable until it hears a beacon. The firmware "passive"
channel state is cleared upon each RXON command, which is sent to
update association status. So, when we attempt association and
authorisation, the RXON command causes the firmware to clear out
what it's already seen, and so we have to wait for a beacon before
we can transmit.

Before people get overly excited - this alone doesn't "fix" 5GHz
operation - it just makes it (more) possible.

The aim here is to convert all the drivers over to use a raw_xmit()
API that doesn't include the node and params - instead they'd get
those from the mbuf. Then raw_xmit() becomes just a side-channel
version of the normal transmit path for management traffic.

MFC after: 2 weeks
Sponsored by: Norse Corp, Inc.

show more ...

Merge ^/head r283596 through r283770.

MFH: r282615-r283655

Sponsored by: The FreeBSD Foundation

Move counter.h include into ieee80211_freebsd.h. Should fix build.

Submitted by: Zilvinas Valinskas <zilvinas.valinskas gmail.com>

Merge sync of head

Migrate the scan iterator lock typedefs out into ieee80211_freebsd.h.

This removes the final piece of freebsd-specific locking that snuck
into the tree - it's now all inside ieee80211_freebsd.h.

Migrate the 802.11s locks out into ieee80211_freebsd.h, so they can be
defined as platform specific bits.

This is to help make OS portability easier.

Cleanup compat shims for FreeBSD versions that predate 10.0-RELEASE.
There are no plans to merge anything save a trivial bugfix to stable/9.

Discussed with: adrian

Convert malloc/free back to #define's, as part of OS portability work.

DragonflyBSD uses the FreeBSD wireless stack and drivers. Their malloc()
API is named differently, so they don't have userland

Convert malloc/free back to #define's, as part of OS portability work.

DragonflyBSD uses the FreeBSD wireless stack and drivers. Their malloc()
API is named differently, so they don't have userland/kernel symbol
clashes like we do (think libuinet.)

So, to make it easier for them and to port to other BSDs/other operating
systems, start hiding the malloc specific bits behind defines in
ieee80211_freebsd.h.

DragonflyBSD can now put these portability defines in their local
ieee80211_dragonflybsd.h.

This should be a great big no-op for everyone running wifi.

TODO:

* kill M_WAITOK - some platforms just don't want you to use it
* .. and/or handle it returning NULL rather than waiting forever.
* MALLOC_DEFINE() ?
* Migrate the well-known malloc names (eg M_TEMP) to net80211
namespace defines.

show more ...

Merge from HEAD

MFH: r282315-r282534

Sponsored by: The FreeBSD Foundation

Fix string concatenation - "wlan_##name" -> "wlan_" #name

PR: kern/197623
Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>

Merge head r233826 through r256722.

IFC @256277

Approved by: ken (mentor)

IFC @ r255692

Comment out IA32_MISC_ENABLE MSR access - this doesn't exist on AMD.
Need to sort out how arch-specific MSRs will be handled.

Merge from head