<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/net/mac80211.h, branch v3.4.23</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.4.23</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.4.23'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2012-04-09T19:54:48+00:00</updated>
<entry>
<title>mac80211: Convert WARN_ON to WARN_ON_ONCE</title>
<updated>2012-04-09T19:54:48+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2012-04-06T21:35:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aa331df0e5e6ebac086ed80b4fbbfd912fe6b32a'/>
<id>urn:sha1:aa331df0e5e6ebac086ed80b4fbbfd912fe6b32a</id>
<content type='text'>
When the control-rate tables are not set up correctly, it makes
little sense to spam the logs, thus change the WARN_ON to WARN_ON_ONCE.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux</title>
<updated>2012-03-24T17:41:37+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-03-24T17:41:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=250f6715a4112d6686670c5a62ceb9305da94616'/>
<id>urn:sha1:250f6715a4112d6686670c5a62ceb9305da94616</id>
<content type='text'>
Pull &lt;linux/device.h&gt; avoidance patches from Paul Gortmaker:
 "Nearly every subsystem has some kind of header with a proto like:

	void foo(struct device *dev);

  and yet there is no reason for most of these guys to care about the
  sub fields within the device struct.  This allows us to significantly
  reduce the scope of headers including headers.  For this instance, a
  reduction of about 40% is achieved by replacing the include with the
  simple fact that the device is some kind of a struct.

  Unlike the much larger module.h cleanup, this one is simply two
  commits.  One to fix the implicit &lt;linux/device.h&gt; users, and then one
  to delete the device.h includes from the linux/include/ dir wherever
  possible."

* tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
  device.h: audit and cleanup users in main include dir
  device.h: cleanup users outside of linux/include (C files)
</content>
</entry>
<entry>
<title>Merge tag 'bug-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux</title>
<updated>2012-03-24T17:08:39+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-03-24T17:08:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ed2d265d1266736bd294332d7f649003943ae36e'/>
<id>urn:sha1:ed2d265d1266736bd294332d7f649003943ae36e</id>
<content type='text'>
Pull &lt;linux/bug.h&gt; cleanup from Paul Gortmaker:
 "The changes shown here are to unify linux's BUG support under the one
  &lt;linux/bug.h&gt; file.  Due to historical reasons, we have some BUG code
  in bug.h and some in kernel.h -- i.e.  the support for BUILD_BUG in
  linux/kernel.h predates the addition of linux/bug.h, but old code in
  kernel.h wasn't moved to bug.h at that time.  As a band-aid, kernel.h
  was including &lt;asm/bug.h&gt; to pseudo link them.

  This has caused confusion[1] and general yuck/WTF[2] reactions.  Here
  is an example that violates the principle of least surprise:

      CC      lib/string.o
      lib/string.c: In function 'strlcat':
      lib/string.c:225:2: error: implicit declaration of function 'BUILD_BUG_ON'
      make[2]: *** [lib/string.o] Error 1
      $
      $ grep linux/bug.h lib/string.c
      #include &lt;linux/bug.h&gt;
      $

  We've included &lt;linux/bug.h&gt; for the BUG infrastructure and yet we
  still get a compile fail! [We've not kernel.h for BUILD_BUG_ON.] Ugh -
  very confusing for someone who is new to kernel development.

  With the above in mind, the goals of this changeset are:

  1) find and fix any include/*.h files that were relying on the
     implicit presence of BUG code.
  2) find and fix any C files that were consuming kernel.h and hence
     relying on implicitly getting some/all BUG code.
  3) Move the BUG related code living in kernel.h to &lt;linux/bug.h&gt;
  4) remove the asm/bug.h from kernel.h to finally break the chain.

  During development, the order was more like 3-4, build-test, 1-2.  But
  to ensure that git history for bisect doesn't get needless build
  failures introduced, the commits have been reorderd to fix the problem
  areas in advance.

	[1]  https://lkml.org/lkml/2012/1/3/90
	[2]  https://lkml.org/lkml/2012/1/17/414"

Fix up conflicts (new radeon file, reiserfs header cleanups) as per Paul
and linux-next.

* tag 'bug-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
  kernel.h: doesn't explicitly use bug.h, so don't include it.
  bug: consolidate BUILD_BUG_ON with other bug code
  BUG: headers with BUG/BUG_ON etc. need linux/bug.h
  bug.h: add include of it to various implicit C users
  lib: fix implicit users of kernel.h for TAINT_WARN
  spinlock: macroize assert_spin_locked to avoid bug.h dependency
  x86: relocate get/set debugreg fcns to include/asm/debugreg.
</content>
</entry>
<entry>
<title>device.h: audit and cleanup users in main include dir</title>
<updated>2012-03-16T14:38:24+00:00</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2012-01-30T16:46:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=313162d0b83836e2f57e51b9b8650fb4b9c396ea'/>
<id>urn:sha1:313162d0b83836e2f57e51b9b8650fb4b9c396ea</id>
<content type='text'>
The &lt;linux/device.h&gt; header includes a lot of stuff, and
it in turn gets a lot of use just for the basic "struct device"
which appears so often.

Clean up the users as follows:

1) For those headers only needing "struct device" as a pointer
in fcn args, replace the include with exactly that.

2) For headers not really using anything from device.h, simply
delete the include altogether.

3) For headers relying on getting device.h implicitly before
being included themselves, now explicitly include device.h

4) For files in which doing #1 or #2 uncovers an implicit
dependency on some other header, fix by explicitly adding
the required header(s).

Any C files that were implicitly relying on device.h to be
present have already been dealt with in advance.

Total removals from #1 and #2: 51.  Total additions coming
from #3: 9.  Total other implicit dependencies from #4: 7.

As of 3.3-rc1, there were 110, so a net removal of 42 gives
about a 38% reduction in device.h presence in include/*

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
</entry>
<entry>
<title>mac80211: rename bss_conf timestamp to last_tsf</title>
<updated>2012-03-13T18:54:20+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-03-13T13:29:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e9ac0745c734d39cb55ce45f1fb03a85c972b35a'/>
<id>urn:sha1:e9ac0745c734d39cb55ce45f1fb03a85c972b35a</id>
<content type='text'>
This value is not really very useful by itself,
yet some drivers (including iwlwifi until I can
figure out what it should do) use it. At least
rename it to "last_tsf" to indicate the meaning
and add a note that it may be really old.

I suspect the value may become useful combined
with the rx_status-&gt;mactime, but we don't (yet)
store that value and pass it to the driver.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
<entry>
<title>mac80211: remove tx_sync</title>
<updated>2012-03-12T18:19:38+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-03-09T11:49:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=177958e9679c23537411066cc41b205635dacb14'/>
<id>urn:sha1:177958e9679c23537411066cc41b205635dacb14</id>
<content type='text'>
When the station state callback was added, this
was no longer needed in theory. With the iwlwifi
changes to remove use of it landing, we can kill
the entire tx-sync framework again, RIP.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
<entry>
<title>mac80211: update ieee80211_tx_rate_control kerneldoc</title>
<updated>2012-03-08T19:05:07+00:00</updated>
<author>
<name>Simon Wunderlich</name>
<email>simon.wunderlich@s2003.tu-chemnitz.de</email>
</author>
<published>2012-03-07T20:31:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f44d4eb54432a0109ff15b2669c91f061428ff39'/>
<id>urn:sha1:f44d4eb54432a0109ff15b2669c91f061428ff39</id>
<content type='text'>
 * add entry for rate_idx_mcs_mask
 * fix order of entries to represent the structs' order

Signed-off-by: Simon Wunderlich &lt;siwu@hrz.tu-chemnitz.de&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
<entry>
<title>mac80211: add an rx flag for ignoring a packet's signal strength</title>
<updated>2012-03-05T20:38:32+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2012-03-01T17:00:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fe8431f89e25de722610ee5beb2892bd019d1fed'/>
<id>urn:sha1:fe8431f89e25de722610ee5beb2892bd019d1fed</id>
<content type='text'>
For A-MPDU rx it makes sense to only process the signal strength once per
aggregate instead of once per subframe. Additonally, some hardware (e.g.
Atheros) only provides valid signal strength information for the last
subframe.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
<entry>
<title>BUG: headers with BUG/BUG_ON etc. need linux/bug.h</title>
<updated>2012-03-04T22:54:34+00:00</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-11-24T01:12:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=187f1882b5b0748b3c4c22274663fdb372ac0452'/>
<id>urn:sha1:187f1882b5b0748b3c4c22274663fdb372ac0452</id>
<content type='text'>
If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
other BUG variant in a static inline (i.e. not in a #define) then
that header really should be including &lt;linux/bug.h&gt; and not just
expecting it to be implicitly present.

We can make this change risk-free, since if the files using these
headers didn't have exposure to linux/bug.h already, they would have
been causing compile failures/warnings.

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
</entry>
<entry>
<title>mac80211: handle non-bufferable MMPDUs correctly</title>
<updated>2012-02-29T19:14:54+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-02-27T11:18:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=02f2f1a951f87644166926862ec32fb13511e2f3'/>
<id>urn:sha1:02f2f1a951f87644166926862ec32fb13511e2f3</id>
<content type='text'>
This renames the IEEE80211_TX_CTL_POLL_RESPONSE
TX flag to IEEE80211_TX_CTL_NO_PS_BUFFER and also
uses it for non-bufferable MMPDUs (all MMPDUs but
deauth, disassoc and action frames.)

Previously, mac80211 would let the MMPDU through
but not set the flag so drivers supporting some
hardware aids for avoiding the PS races would
then reject the frame.

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