<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/net/mac80211/cfg.c, branch dev</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2015-06-10T14:05:36+00:00</updated>
<entry>
<title>mac80211: convert HW flags to unsigned long bitmap</title>
<updated>2015-06-10T14:05:36+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-06-02T19:39:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=30686bf7f5b3c30831761e188a6e3cb33580fa48'/>
<id>urn:sha1:30686bf7f5b3c30831761e188a6e3cb33580fa48</id>
<content type='text'>
As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.

This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code.

The occurrences of an explicit __clear_bit() are intentional, the
drivers were never supposed to change their supported bits on the
fly. We should investigate changing this to be a per-frame flag.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge remote-tracking branch 'net-next/master' into mac80211-next</title>
<updated>2015-06-10T10:45:09+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-06-10T10:44:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=206c59d1d7d42bcafc1d7f1e476e87e4427e2345'/>
<id>urn:sha1:206c59d1d7d42bcafc1d7f1e476e87e4427e2345</id>
<content type='text'>
Merge back net-next to get wireless driver changes (from Kalle)
to be able to create the API change across all trees properly.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: fix the beacon csa counter for mesh and ibss</title>
<updated>2015-06-09T20:04:25+00:00</updated>
<author>
<name>Chun-Yeow Yeoh</name>
<email>yeohchunyeow@gmail.com</email>
</author>
<published>2015-06-09T05:35:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=8df734e865b74d9f273216482a45a38269dc767a'/>
<id>urn:sha1:8df734e865b74d9f273216482a45a38269dc767a</id>
<content type='text'>
The csa counter has moved from sdata to beacon/presp but
it is not updated accordingly for mesh and ibss. Fix this.

Fixes: af296bdb8da4 ("mac80211: move csa counters from sdata to beacon/presp")
Signed-off-by: Chun-Yeow Yeoh &lt;yeohchunyeow@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: stop using pointers as userspace cookies</title>
<updated>2015-06-02T11:07:59+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-06-01T21:14:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3b79af973cf42de059d0e90e20fd145d7ed8c5c1'/>
<id>urn:sha1:3b79af973cf42de059d0e90e20fd145d7ed8c5c1</id>
<content type='text'>
Even if the pointers are really only accessible to root and used
pretty much only by wpa_supplicant, this is still not great; even
for debugging it'd be easier to have something that's easier to
read and guaranteed to never get reused.

With the recent change to make mac80211 create an ack_skb for the
mgmt-tx path this becomes possible, only the client probe method
needs to also allocate an ack_skb, and we can store the cookie in
that skb.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: copy nl80211 mgmt TX SKB for status</title>
<updated>2015-06-02T11:07:55+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-06-01T20:54:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b2eb0ee6d0220b47a1f901e4f1c56dd594509d8e'/>
<id>urn:sha1:b2eb0ee6d0220b47a1f901e4f1c56dd594509d8e</id>
<content type='text'>
When we return the TX status for an nl80211 mgmt TX SKB, we
should also return the original frame with the status to
allow userspace to match up the submission (it could also
use the cookie but both ways are permissible.)

As TX SKBs could be encrypted, at least in the case of ANQP
while associated with the AP, copy the original SKB, store
it with an ACK frame ID and restructure the status path to
use that to return status with the original SKB. Otherwise,
userspace (in particular wpa_supplicant) will get confused.

Reported-by: Matti Gottlieb &lt;matti.gottlieb@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: move TX PN to public part of key struct</title>
<updated>2015-06-02T09:16:35+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-06-01T13:36:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=db388a567ff9600debc2433c1fddf79a8fc38b21'/>
<id>urn:sha1:db388a567ff9600debc2433c1fddf79a8fc38b21</id>
<content type='text'>
For drivers supporting TSO or similar features, but that still have
PN assignment in software, there's a need to have some memory to
store the current PN value. As mac80211 already stores this and it's
somewhat complicated to add a per-driver area to the key struct (due
to the dynamic sizing thereof) it makes sense to just move the TX PN
to the keyconf, i.e. the public part of the key struct.

As TKIP is more complicated and we won't able to offload it in this
way right now (fast-xmit is skipped for TKIP unless the HW does it
all, and our hardware needs MMIC calculation in software) I've not
moved that for now - it's possible but requires exposing a lot of
the internal TKIP state.

As an bonus side effect, we can remove a lot of code by assuming the
keyseq struct has a certain layout - with BUILD_BUG_ON to verify it.

This might also improve performance, since now TX and RX no longer
share a cacheline.

Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2015-06-02T05:51:30+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-06-02T05:33:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=dda922c831d1661c11a3ae1051b7160236f6ffb0'/>
<id>urn:sha1:dda922c831d1661c11a3ae1051b7160236f6ffb0</id>
<content type='text'>
Conflicts:
	drivers/net/phy/amd-xgbe-phy.c
	drivers/net/wireless/iwlwifi/Kconfig
	include/net/mac80211.h

iwlwifi/Kconfig and mac80211.h were both trivial overlapping
changes.

The drivers/net/phy/amd-xgbe-phy.c file got removed in 'net-next' and
the bug fix that happened on the 'net' side is already integrated
into the rest of the amd-xgbe driver.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>mac80211: don't split remain-on-channel for coalescing</title>
<updated>2015-05-20T13:09:22+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-05-19T11:36:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=252ec2b3aa6f6a9ac29c6539027db600c11bf45e'/>
<id>urn:sha1:252ec2b3aa6f6a9ac29c6539027db600c11bf45e</id>
<content type='text'>
Due to remain-on-channel scheduling delays, when we split an ROC
while coalescing, we'll usually get a picture like this:

existing ROC:  |------------------|
current time:              ^
new ROC:                   |------|              |-------|

If the expected response frames are then transmitted by the peer
in the hole between the two fragments of the new ROC, we miss
them and the process (e.g. ANQP query) fails.

mac80211 expects that the window to miss something is small:

existing ROC:  |------------------|
new ROC:                   |------||-------|

but that's normally not the case.

To avoid this problem, coalesce only if the new ROC's duration
is &lt;= the remaining time on the existing one:

existing ROC:  |------------------|
new ROC:                   |-----|

and never split a new one but schedule it afterwards instead:

existing ROC:  |------------------|
new ROC:                                       |-------------|

type=bugfix
bug=not-tracked
fixes=unknown

Reported-by: Matti Gottlieb &lt;matti.gottlieb@intel.com&gt;
Reviewed-by: EliadX Peller &lt;eliad@wizery.com&gt;
Reviewed-by: Matti Gottlieb &lt;matti.gottlieb@intel.com&gt;
Tested-by: Matti Gottlieb &lt;matti.gottlieb@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: check fast-xmit on station change</title>
<updated>2015-05-20T13:08:36+00:00</updated>
<author>
<name>Michal Kazior</name>
<email>michal.kazior@tieto.com</email>
</author>
<published>2015-05-19T12:13:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=464daaf04cb633ae1530652fd23cdea0f0d21dd5'/>
<id>urn:sha1:464daaf04cb633ae1530652fd23cdea0f0d21dd5</id>
<content type='text'>
Drivers with fast-xmit (e.g. ath10k) running in
AP_VLAN setups would fail to communicate with
connected 4addr stations.

The reason was when new station associates it
first goes into master AP interface. It is not
until later that a dedicated AP_VLAN is created
for it and the station itself is moved there.
After that Tx directed at the station should use
4addr header. However fast-xmit wasn't
recalculated and 3addr header remained to be used.
This in turn caused the connected 4addr stations
to drop packets coming from the AP until some
other event would cause fast-xmit to recalculate
for that station (which could never come).

Signed-off-by: Michal Kazior &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: extend get_key() to return PN for all ciphers</title>
<updated>2015-05-06T11:30:00+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-04-20T16:21:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a31cf1c69e89e0c2d5515b04aca313f1014a714d'/>
<id>urn:sha1:a31cf1c69e89e0c2d5515b04aca313f1014a714d</id>
<content type='text'>
For ciphers not supported by mac80211, the function currently
doesn't return any PN data. Fix this by extending the driver's
get_key_seq() a little more to allow moving arbitrary PN data.

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