<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net/mac80211/trace.h, branch v3.9</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>mac80211: Fix incorrect use of STA_PR_FMT in trace points</title>
<updated>2013-02-15T19:25:11+00:00</updated>
<author>
<name>Seth Forshee</name>
<email>seth.forshee@canonical.com</email>
</author>
<published>2013-02-15T19:15:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=15ac7c478fd227257e4be94519c6f965a9e6159d'/>
<id>15ac7c478fd227257e4be94519c6f965a9e6159d</id>
<content type='text'>
Several tracepoints are using STA_PR_FMT where STA_PR_ARG should be
used, resulting in messages like "phy0 sta:ARG TYPE NOT FIELD BUT 1".
Change these to STA_PR_ARG.

Signed-off-by: Seth Forshee &lt;seth.forshee@canonical.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>
Several tracepoints are using STA_PR_FMT where STA_PR_ARG should be
used, resulting in messages like "phy0 sta:ARG TYPE NOT FIELD BUT 1".
Change these to STA_PR_ARG.

Signed-off-by: Seth Forshee &lt;seth.forshee@canonical.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: add radar detection command/event</title>
<updated>2013-02-15T08:41:04+00:00</updated>
<author>
<name>Simon Wunderlich</name>
<email>simon.wunderlich@s2003.tu-chemnitz.de</email>
</author>
<published>2013-02-08T17:16:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=164eb02d070af987890e1db1c12b8ae0394b19f7'/>
<id>164eb02d070af987890e1db1c12b8ae0394b19f7</id>
<content type='text'>
Add command to trigger radar detection in the driver/FW.
Once radar detection is started it should continuously
monitor for radars as long as the channel active.
If radar is detected usermode notified with 'radar
detected' event.

Scanning and remain on channel functionality must be disabled
while doing radar detection/scanning, and vice versa.

Based on original patch by Victor Goldenshtein &lt;victorg@ti.com&gt;

Signed-off-by: Simon Wunderlich &lt;siwu@hrz.tu-chemnitz.de&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 command to trigger radar detection in the driver/FW.
Once radar detection is started it should continuously
monitor for radars as long as the channel active.
If radar is detected usermode notified with 'radar
detected' event.

Scanning and remain on channel functionality must be disabled
while doing radar detection/scanning, and vice versa.

Based on original patch by Victor Goldenshtein &lt;victorg@ti.com&gt;

Signed-off-by: Simon Wunderlich &lt;siwu@hrz.tu-chemnitz.de&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: introduce beacon-only timing data</title>
<updated>2013-02-11T17:45:00+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2013-02-05T16:48:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ef429dadf33feeb150098dbe84ccaa877e3261f6'/>
<id>ef429dadf33feeb150098dbe84ccaa877e3261f6</id>
<content type='text'>
In order to be able to predict the next DTIM TBTT
in the driver, add the ability to use timing data
from beacons only with the new hardware flag
IEEE80211_HW_TIMING_BEACON_ONLY and the BSS info
value sync_dtim_count which is only valid if the
timing data came from a beacon. The data can only
come from a beacon, and if no beacon was received
before association it is updated later together
with the DTIM count notification.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In order to be able to predict the next DTIM TBTT
in the driver, add the ability to use timing data
from beacons only with the new hardware flag
IEEE80211_HW_TIMING_BEACON_ONLY and the BSS info
value sync_dtim_count which is only valid if the
timing data came from a beacon. The data can only
come from a beacon, and if no beacon was received
before association it is updated later together
with the DTIM count notification.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix chandef tracing bug</title>
<updated>2013-02-11T17:44:56+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2013-02-08T20:29:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=757af6fefd53628bcfe75f7fbd302c5d4c02eba5'/>
<id>757af6fefd53628bcfe75f7fbd302c5d4c02eba5</id>
<content type='text'>
The chandef tracing writes center_freq1 twice, so
that it is always 0 (no driver supports 80+80 yet)
and leaves center_freq2 unset. Fix this mistake.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The chandef tracing writes center_freq1 twice, so
that it is always 0 (no driver supports 80+80 yet)
and leaves center_freq2 unset. Fix this mistake.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: provide the vif in rssi_callback</title>
<updated>2013-01-24T14:41:29+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2013-01-20T15:32:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=887da9176e011a044b12ec0deff62df5faadd67c'/>
<id>887da9176e011a044b12ec0deff62df5faadd67c</id>
<content type='text'>
Since drivers can support several BSS / P2P Client
interfaces, the rssi callback needs to inform the driver
about the interface teh rssi event relates to.

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>
Since drivers can support several BSS / P2P Client
interfaces, the rssi callback needs to inform the driver
about the interface teh rssi event relates to.

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>mac80211: allow drivers to access IPv6 information</title>
<updated>2013-01-18T20:55:38+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2013-01-14T14:14:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a65240c1013222dbf41166c8b2c5ed2720c807c3'/>
<id>a65240c1013222dbf41166c8b2c5ed2720c807c3</id>
<content type='text'>
To be able to implement NS response offloading (in
regular operation or while in WoWLAN) drivers need
to know the IPv6 addresses assigned to interfaces.
Implement an IPv6 notifier in mac80211 to call the
driver when addresses change.

Unlike for IPv4, implement it as a callback rather
than as a list in the BSS configuration, that is
more flexible.

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 be able to implement NS response offloading (in
regular operation or while in WoWLAN) drivers need
to know the IPv6 addresses assigned to interfaces.
Implement an IPv6 notifier in mac80211 to call the
driver when addresses change.

Unlike for IPv4, implement it as a callback rather
than as a list in the BSS configuration, that is
more flexible.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: remove ARP filter enable/disable logic</title>
<updated>2013-01-18T20:20:34+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2013-01-14T15:39:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0f19b41e223d787251c59137e61fc5145c13d1c4'/>
<id>0f19b41e223d787251c59137e61fc5145c13d1c4</id>
<content type='text'>
Depending on the driver, having ARP filtering for
some addresses may be possible. Remove the logic
that tracks whether ARP filter is enabled or not
and give the driver the total number of addresses
instead of the length of the list so it can make
its own decision.

Reviewed-by: Luciano Coelho &lt;coelho@ti.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>
Depending on the driver, having ARP filtering for
some addresses may be possible. Remove the logic
that tracks whether ARP filter is enabled or not
and give the driver the total number of addresses
instead of the length of the list so it can make
its own decision.

Reviewed-by: Luciano Coelho &lt;coelho@ti.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: add op to configure default key id</title>
<updated>2013-01-18T12:30:21+00:00</updated>
<author>
<name>Yoni Divinsky</name>
<email>yoni.divinsky@ti.com</email>
</author>
<published>2012-05-30T08:36:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=de5fad815703b5b24bc4726cd71422929537d259'/>
<id>de5fad815703b5b24bc4726cd71422929537d259</id>
<content type='text'>
There are hardwares which support offload of data packets
for example when auto ARP is enabled the hw will send
the ARP response. In such cases if WEP encryption is
configured the hw must know the default WEP key in order
to encrypt the packets correctly.

When hw_accel is enabled and encryption type is set to WEP,
the driver should get the default key index from mac80211.

Signed-off-by: Yoni Divinsky &lt;yoni.divinsky@ti.com&gt;
[cleanups, fixes, documentation]
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 hardwares which support offload of data packets
for example when auto ARP is enabled the hw will send
the ARP response. In such cases if WEP encryption is
configured the hw must know the default WEP key in order
to encrypt the packets correctly.

When hw_accel is enabled and encryption type is set to WEP,
the driver should get the default key index from mac80211.

Signed-off-by: Yoni Divinsky &lt;yoni.divinsky@ti.com&gt;
[cleanups, fixes, documentation]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: split out chandef tracing macros</title>
<updated>2013-01-16T22:57:51+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-12-21T11:36:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5a32aff37a02ebc959837f08d09ac8ba65d4f1b0'/>
<id>5a32aff37a02ebc959837f08d09ac8ba65d4f1b0</id>
<content type='text'>
Some new APIs will require tracing a chandef without
it being part of a channel context, so separate out
the tracing macros for that.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some new APIs will require tracing a chandef without
it being part of a channel context, so separate out
the tracing macros for that.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: convert to channel definition struct</title>
<updated>2012-11-26T11:42:59+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-11-09T10:39:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4bf88530be971bf95a7830ca61b4120980bf4347'/>
<id>4bf88530be971bf95a7830ca61b4120980bf4347</id>
<content type='text'>
Convert mac80211 (and where necessary, some drivers a
little bit) to the new channel definition struct.

This will allow extending mac80211 for VHT, which is
currently restricted to channel contexts since there
are no drivers using that which makes it easier. As
I also don't care about VHT for drivers not using the
channel context API, I won't convert the previous API
to VHT support.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Convert mac80211 (and where necessary, some drivers a
little bit) to the new channel definition struct.

This will allow extending mac80211 for VHT, which is
currently restricted to channel contexts since there
are no drivers using that which makes it easier. As
I also don't care about VHT for drivers not using the
channel context API, I won't convert the previous API
to VHT support.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
