<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net/wireless/nl80211.h, branch v4.9.33</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>cfg80211: always notify userspace of new wireless netdevs</title>
<updated>2016-08-11T14:51:41+00:00</updated>
<author>
<name>Denis Kenzior</name>
<email>denkenz@gmail.com</email>
</author>
<published>2016-08-03T21:58:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=896ff0635a312022c91e2bef30c80abc27af62e8'/>
<id>896ff0635a312022c91e2bef30c80abc27af62e8</id>
<content type='text'>
This change alters the semantics of NL80211_CMD_NEW_INTERFACE events
by always sending this event whenever a new net_device object
associated with a wdev is registered.  Prior to this change, this event
was only sent as a result of NL80211_CMD_NEW_INTERFACE command sent
from userspace.  This allows userspace to reliably detect new wireless
interfaces (e.g. due to hardware hot-plug events, etc).

For wdevs created without an associated net_device object (e.g.
NL80211_IFTYPE_P2P_DEVICE), the NL80211_CMD_NEW_INTERFACE event is
still generated inside the relevant nl80211 command handler.

Signed-off-by: Denis Kenzior &lt;denkenz@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This change alters the semantics of NL80211_CMD_NEW_INTERFACE events
by always sending this event whenever a new net_device object
associated with a wdev is registered.  Prior to this change, this event
was only sent as a result of NL80211_CMD_NEW_INTERFACE command sent
from userspace.  This allows userspace to reliably detect new wireless
interfaces (e.g. due to hardware hot-plug events, etc).

For wdevs created without an associated net_device object (e.g.
NL80211_IFTYPE_P2P_DEVICE), the NL80211_CMD_NEW_INTERFACE event is
still generated inside the relevant nl80211 command handler.

Signed-off-by: Denis Kenzior &lt;denkenz@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: Allow cfg80211_connect_result() errors to be distinguished</title>
<updated>2016-05-31T13:22:15+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni@qca.qualcomm.com</email>
</author>
<published>2016-05-30T21:16:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bf1ecd210541ef5f3a110e88e8ca5d33b4aa5c23'/>
<id>bf1ecd210541ef5f3a110e88e8ca5d33b4aa5c23</id>
<content type='text'>
Previously, the status parameter to cfg80211_connect_result() was
documented as using WLAN_STATUS_UNSPECIFIED_FAILURE (1) when the real
status code for the failure is not known. This value can be used by an
AP (and often is) and as such, user space cannot distinguish between
explicitly rejected authentication/association and not being able to
even try to associate or not receiving a response from the AP.

Add a new inline function, cfg80211_connect_timeout(), to be used when
the driver knows that the connection attempt failed due to a reason
where connection could not be attempt or no response was received from
the AP. The internal functions now allow a negative status value (-1) to
be used as an indication of this special case. This results in the
NL80211_ATTR_TIMED_OUT to be added to the NL80211_CMD_CONNECT event to
allow user space to determine this case was hit. For backwards
compatibility, NL80211_STATUS_CODE with the value
WLAN_STATUS_UNSPECIFIED_FAILURE is still indicated in the event in such
a case.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
[johannes: fix cfg80211_connect_bss() prototype to use int for status,
 add cfg80211_connect_timeout() to docbook, fix docbook]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, the status parameter to cfg80211_connect_result() was
documented as using WLAN_STATUS_UNSPECIFIED_FAILURE (1) when the real
status code for the failure is not known. This value can be used by an
AP (and often is) and as such, user space cannot distinguish between
explicitly rejected authentication/association and not being able to
even try to associate or not receiving a response from the AP.

Add a new inline function, cfg80211_connect_timeout(), to be used when
the driver knows that the connection attempt failed due to a reason
where connection could not be attempt or no response was received from
the AP. The internal functions now allow a negative status value (-1) to
be used as an indication of this special case. This results in the
NL80211_ATTR_TIMED_OUT to be added to the NL80211_CMD_CONNECT event to
allow user space to determine this case was hit. For backwards
compatibility, NL80211_STATUS_CODE with the value
WLAN_STATUS_UNSPECIFIED_FAILURE is still indicated in the event in such
a case.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
[johannes: fix cfg80211_connect_bss() prototype to use int for status,
 add cfg80211_connect_timeout() to docbook, fix docbook]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: allow wiphy specific regdomain management</title>
<updated>2014-12-17T10:49:55+00:00</updated>
<author>
<name>Jonathan Doron</name>
<email>jond@wizery.com</email>
</author>
<published>2014-12-15T17:26:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b0d7aa59592b4270531de5ce65dcf18338a2d98c'/>
<id>b0d7aa59592b4270531de5ce65dcf18338a2d98c</id>
<content type='text'>
Add a new regulatory flag that allows a driver to manage regdomain
changes/updates for its own wiphy.
A self-managed wiphys only employs regulatory information obtained from
the FW and driver and does not use other cfg80211 sources like
beacon-hints, country-code IEs and hints from other devices on the same
system. Conversely, a self-managed wiphy does not share its regulatory
hints with other devices in the system. If a system contains several
devices, one or more of which are self-managed, there might be
contradictory regulatory settings between them. Usage of flag is
generally discouraged. Only use it if the FW/driver is incompatible
with non-locally originated hints.

A new API lets the driver send a complete regdomain, to be applied on
its wiphy only.

After a wiphy-specific regdomain change takes place, usermode will get
a new type of change notification. The regulatory core also takes care
enforce regulatory restrictions, in case some interfaces are on
forbidden channels.

Signed-off-by: Jonathan Doron &lt;jonathanx.doron@intel.com&gt;
Signed-off-by: Arik Nemtsov &lt;arikx.nemtsov@intel.com&gt;
Reviewed-by: Luis R. Rodriguez &lt;mcgrof@suse.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a new regulatory flag that allows a driver to manage regdomain
changes/updates for its own wiphy.
A self-managed wiphys only employs regulatory information obtained from
the FW and driver and does not use other cfg80211 sources like
beacon-hints, country-code IEs and hints from other devices on the same
system. Conversely, a self-managed wiphy does not share its regulatory
hints with other devices in the system. If a system contains several
devices, one or more of which are self-managed, there might be
contradictory regulatory settings between them. Usage of flag is
generally discouraged. Only use it if the FW/driver is incompatible
with non-locally originated hints.

A new API lets the driver send a complete regdomain, to be applied on
its wiphy only.

After a wiphy-specific regdomain change takes place, usermode will get
a new type of change notification. The regulatory core also takes care
enforce regulatory restrictions, in case some interfaces are on
forbidden channels.

Signed-off-by: Jonathan Doron &lt;jonathanx.doron@intel.com&gt;
Signed-off-by: Arik Nemtsov &lt;arikx.nemtsov@intel.com&gt;
Reviewed-by: Luis R. Rodriguez &lt;mcgrof@suse.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211/mac80211: add wmm info to assoc event</title>
<updated>2014-09-11T10:24:39+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2014-09-09T14:09:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b0b6aa2c8e0d0e34f7658d5cc1e4fbb59f701c42'/>
<id>b0b6aa2c8e0d0e34f7658d5cc1e4fbb59f701c42</id>
<content type='text'>
Userspace might need to know what queues are configured
for uapsd (e.g. for setting proper default values in tspecs).

Add this bitmap to the association event (inside wmm
nested attribute)

Add additional parameter to cfg80211_rx_assoc_resp,
and update its callers.

Signed-off-by: Eliad Peller &lt;eliadx.peller@intel.com&gt;
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Userspace might need to know what queues are configured
for uapsd (e.g. for setting proper default values in tspecs).

Add this bitmap to the association event (inside wmm
nested attribute)

Add additional parameter to cfg80211_rx_assoc_resp,
and update its callers.

Signed-off-by: Eliad Peller &lt;eliadx.peller@intel.com&gt;
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: send events when devices are added/removed</title>
<updated>2014-05-26T11:52:25+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2014-05-26T11:52:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3bb20556726702a27166e49ef513bd8d8432d9c4'/>
<id>3bb20556726702a27166e49ef513bd8d8432d9c4</id>
<content type='text'>
We're currently sending NEW_WIPHY events for renames (which
is a bit odd, but now can't be changed), but also send them
for really new devices that register.

Also send DEL_WIPHY events when a device is removed, the
event ID for this was already reserved.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We're currently sending NEW_WIPHY events for renames (which
is a bit odd, but now can't be changed), but also send them
for really new devices that register.

Also send DEL_WIPHY events when a device is removed, the
event ID for this was already reserved.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless</title>
<updated>2014-02-13T19:43:02+00:00</updated>
<author>
<name>John W. Linville</name>
<email>linville@tuxdriver.com</email>
</author>
<published>2014-02-13T19:43:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0e028ab0fb2da47fd235dafd4159859892e73d08'/>
<id>0e028ab0fb2da47fd235dafd4159859892e73d08</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: send scan results from work queue</title>
<updated>2014-02-06T08:55:19+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2014-01-22T09:14:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f9d15d162b3acf28f85b3ac05c4883e5ed588d28'/>
<id>f9d15d162b3acf28f85b3ac05c4883e5ed588d28</id>
<content type='text'>
Due to the previous commit, when a scan finishes, it is in theory
possible to hit the following sequence:
 1. interface starts being removed
 2. scan is cancelled by driver and cfg80211 is notified
 3. scan done work is scheduled
 4. interface is removed completely, rdev-&gt;scan_req is freed,
    event sent to userspace but scan done work remains pending
 5. new scan is requested on another virtual interface
 6. scan done work runs, freeing the still-running scan

To fix this situation, hang on to the scan done message and block
new scans while that is the case, and only send the message from
the work function, regardless of whether the scan_req is already
freed from interface removal. This makes step 5 above impossible
and changes step 6 to be
 5. scan done work runs, sending the scan done message

As this can't work for wext, so we send the message immediately,
but this shouldn't be an issue since we still return -EBUSY.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Due to the previous commit, when a scan finishes, it is in theory
possible to hit the following sequence:
 1. interface starts being removed
 2. scan is cancelled by driver and cfg80211 is notified
 3. scan done work is scheduled
 4. interface is removed completely, rdev-&gt;scan_req is freed,
    event sent to userspace but scan done work remains pending
 5. new scan is requested on another virtual interface
 6. scan done work runs, freeing the still-running scan

To fix this situation, hang on to the scan done message and block
new scans while that is the case, and only send the message from
the work function, regardless of whether the scan_req is already
freed from interface removal. This makes step 5 above impossible
and changes step 6 to be
 5. scan done work runs, sending the scan done message

As this can't work for wext, so we send the message immediately,
but this shouldn't be an issue since we still return -EBUSY.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nl80211: send event when AP operation is stopped</title>
<updated>2014-02-04T20:58:08+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2014-01-24T13:06:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=348baf0eac3391c62d441ec29b4c5da62ed91e74'/>
<id>348baf0eac3391c62d441ec29b4c5da62ed91e74</id>
<content type='text'>
There are a few cases, e.g. suspend, where an AP interface is
stopped by the kernel rather than by userspace request, most
commonly when suspending. To let userspace know about this,
send the NL80211_CMD_STOP_AP command as an event every time
an AP interface is stopped. This also happens when userspace
did in fact request the AP stop, but that's not a problem.

For full-MAC drivers this may need to be extended to also
cover cases where the device stopped the AP operation for
some reason, this a bit more complicated because then all
cfg80211 state also needs to be reset; such API is not part
of this patch.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are a few cases, e.g. suspend, where an AP interface is
stopped by the kernel rather than by userspace request, most
commonly when suspending. To let userspace know about this,
send the NL80211_CMD_STOP_AP command as an event every time
an AP interface is stopped. This also happens when userspace
did in fact request the AP stop, but that's not a problem.

For full-MAC drivers this may need to be extended to also
cover cases where the device stopped the AP operation for
some reason, this a bit more complicated because then all
cfg80211 state also needs to be reset; such API is not part
of this patch.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211/mac80211: DFS setup chandef for cac event</title>
<updated>2013-11-25T19:50:46+00:00</updated>
<author>
<name>Janusz Dziedzic</name>
<email>janusz.dziedzic@tieto.com</email>
</author>
<published>2013-11-06T12:55:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d2859df5e7f00469011482d850fba652517a2eab'/>
<id>d2859df5e7f00469011482d850fba652517a2eab</id>
<content type='text'>
To report channel width correctly we have
to send correct channel parameters from
mac80211 when calling cfg80211_cac_event().

This is required in case of using channel width
higher than 20MHz and we have to set correct
dfs channel state after CAC (NL80211_DFS_AVAILABLE).

Signed-off-by: Janusz Dziedzic &lt;janusz.dziedzic@tieto.com&gt;
Reviewed-by: Luis R. Rodriguez &lt;mcgrof@do-not-panic.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To report channel width correctly we have
to send correct channel parameters from
mac80211 when calling cfg80211_cac_event().

This is required in case of using channel width
higher than 20MHz and we have to set correct
dfs channel state after CAC (NL80211_DFS_AVAILABLE).

Signed-off-by: Janusz Dziedzic &lt;janusz.dziedzic@tieto.com&gt;
Reviewed-by: Luis R. Rodriguez &lt;mcgrof@do-not-panic.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: add flags to cfg80211_rx_mgmt()</title>
<updated>2013-08-23T14:06:03+00:00</updated>
<author>
<name>Vladimir Kondratiev</name>
<email>qca_vkondrat@qca.qualcomm.com</email>
</author>
<published>2013-08-15T11:51:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=19504cf5f35fbe85db811fce9f4392a0cbdada2f'/>
<id>19504cf5f35fbe85db811fce9f4392a0cbdada2f</id>
<content type='text'>
Add flags intended to report various auxiliary information
and introduce the NL80211_RXMGMT_FLAG_ANSWERED flag to report
that the frame was already answered by the device.

Signed-off-by: Vladimir Kondratiev &lt;qca_vkondrat@qca.qualcomm.com&gt;
[REPLIED-&gt;ANSWERED, reword commit message]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add flags intended to report various auxiliary information
and introduce the NL80211_RXMGMT_FLAG_ANSWERED flag to report
that the frame was already answered by the device.

Signed-off-by: Vladimir Kondratiev &lt;qca_vkondrat@qca.qualcomm.com&gt;
[REPLIED-&gt;ANSWERED, reword commit message]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
