<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net/wireless, branch v2.6.38.8</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>nl80211: Fix set_key regression with some drivers</title>
<updated>2011-06-03T01:33:49+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni.malinen@atheros.com</email>
</author>
<published>2011-05-04T05:45:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8a2b75b1bc777133e2d70e560e5e49bc1b536b36'/>
<id>8a2b75b1bc777133e2d70e560e5e49bc1b536b36</id>
<content type='text'>
commit 0e579d6a8f4aea346da818f13ee71401c125e639 upstream.

Commit dbd2fd656f2060abfd3a16257f8b51ec60f6d2ed added a mechanism for
user space to indicate whether a default key is being configured for
only unicast or only multicast frames instead of all frames. This
commit added a driver capability flag for indicating whether separate
default keys are supported and validation of the set_key command based
on that capability.

However, this single capability flag is not enough to cover possible
difference based on mode (AP/IBSS/STA) and the way this change was
introduced resulted in a regression with drivers that do not indicate
the new capability (i.e.., more or less any non-mac80211 driver using
cfg80211) when using a recent wpa_supplicant snapshot.

Fix the regression by removing the new check which is not strictly
speaking needed. The new separate default key functionality is needed
only for RSN IBSS which has a separate capability indication.

Signed-off-by: Jouni Malinen &lt;jouni.malinen@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0e579d6a8f4aea346da818f13ee71401c125e639 upstream.

Commit dbd2fd656f2060abfd3a16257f8b51ec60f6d2ed added a mechanism for
user space to indicate whether a default key is being configured for
only unicast or only multicast frames instead of all frames. This
commit added a driver capability flag for indicating whether separate
default keys are supported and validation of the set_key command based
on that capability.

However, this single capability flag is not enough to cover possible
difference based on mode (AP/IBSS/STA) and the way this change was
introduced resulted in a regression with drivers that do not indicate
the new capability (i.e.., more or less any non-mac80211 driver using
cfg80211) when using a recent wpa_supplicant snapshot.

Fix the regression by removing the new check which is not strictly
speaking needed. The new separate default key functionality is needed
only for RSN IBSS which has a separate capability indication.

Signed-off-by: Jouni Malinen &lt;jouni.malinen@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6</title>
<updated>2011-02-22T19:53:05+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2011-02-22T19:53:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d3bd1b4c89cceca42211cd5bd30508b903267229'/>
<id>d3bd1b4c89cceca42211cd5bd30508b903267229</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>fix cfg80211_wext_siwfreq lock ordering...</title>
<updated>2011-02-21T20:14:25+00:00</updated>
<author>
<name>Daniel J Blueman</name>
<email>daniel.blueman@gmail.com</email>
</author>
<published>2011-02-21T16:11:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4f919a3bc54da01db829c520ce4b1fabfde1c3f7'/>
<id>4f919a3bc54da01db829c520ce4b1fabfde1c3f7</id>
<content type='text'>
I previously managed to reproduce a hang while scanning wireless
channels (reproducible with airodump-ng hopping channels); subsequent
lockdep instrumentation revealed a lock ordering issue.

Without knowing the design intent, it looks like the locks should be
taken in reverse order; please comment.

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.38-rc5-341cd #4
-------------------------------------------------------
airodump-ng/15445 is trying to acquire lock:
 (&amp;rdev-&gt;devlist_mtx){+.+.+.}, at: [&lt;ffffffff816b1266&gt;]
cfg80211_wext_siwfreq+0xc6/0x100

but task is already holding lock:
 (&amp;wdev-&gt;mtx){+.+.+.}, at: [&lt;ffffffff816b125c&gt;] cfg80211_wext_siwfreq+0xbc/0x100

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;wdev-&gt;mtx){+.+.+.}:
       [&lt;ffffffff810a79d6&gt;] lock_acquire+0xc6/0x280
       [&lt;ffffffff816d6bce&gt;] mutex_lock_nested+0x6e/0x4b0
       [&lt;ffffffff81696080&gt;] cfg80211_netdev_notifier_call+0x430/0x5f0
       [&lt;ffffffff8109351b&gt;] notifier_call_chain+0x8b/0x100
       [&lt;ffffffff810935b1&gt;] raw_notifier_call_chain+0x11/0x20
       [&lt;ffffffff81576d92&gt;] call_netdevice_notifiers+0x32/0x60
       [&lt;ffffffff815771a4&gt;] __dev_notify_flags+0x34/0x80
       [&lt;ffffffff81577230&gt;] dev_change_flags+0x40/0x70
       [&lt;ffffffff8158587c&gt;] do_setlink+0x1fc/0x8d0
       [&lt;ffffffff81586042&gt;] rtnl_setlink+0xf2/0x140
       [&lt;ffffffff81586923&gt;] rtnetlink_rcv_msg+0x163/0x270
       [&lt;ffffffff8159d741&gt;] netlink_rcv_skb+0xa1/0xd0
       [&lt;ffffffff815867b0&gt;] rtnetlink_rcv+0x20/0x30
       [&lt;ffffffff8159d39a&gt;] netlink_unicast+0x2ba/0x300
       [&lt;ffffffff8159dd57&gt;] netlink_sendmsg+0x267/0x3e0
       [&lt;ffffffff8155e364&gt;] sock_sendmsg+0xe4/0x110
       [&lt;ffffffff8155f3a3&gt;] sys_sendmsg+0x253/0x3b0
       [&lt;ffffffff81003192&gt;] system_call_fastpath+0x16/0x1b

-&gt; #0 (&amp;rdev-&gt;devlist_mtx){+.+.+.}:
       [&lt;ffffffff810a7222&gt;] __lock_acquire+0x1622/0x1d10
       [&lt;ffffffff810a79d6&gt;] lock_acquire+0xc6/0x280
       [&lt;ffffffff816d6bce&gt;] mutex_lock_nested+0x6e/0x4b0
       [&lt;ffffffff816b1266&gt;] cfg80211_wext_siwfreq+0xc6/0x100
       [&lt;ffffffff816b2fad&gt;] ioctl_standard_call+0x5d/0xd0
       [&lt;ffffffff816b3223&gt;] T.808+0x163/0x170
       [&lt;ffffffff816b326a&gt;] wext_handle_ioctl+0x3a/0x90
       [&lt;ffffffff815798d2&gt;] dev_ioctl+0x6f2/0x830
       [&lt;ffffffff8155cf3d&gt;] sock_ioctl+0xfd/0x290
       [&lt;ffffffff8117dffd&gt;] do_vfs_ioctl+0x9d/0x590
       [&lt;ffffffff8117e53a&gt;] sys_ioctl+0x4a/0x80
       [&lt;ffffffff81003192&gt;] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

2 locks held by airodump-ng/15445:
 #0:  (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff81586782&gt;] rtnl_lock+0x12/0x20
 #1:  (&amp;wdev-&gt;mtx){+.+.+.}, at: [&lt;ffffffff816b125c&gt;]
cfg80211_wext_siwfreq+0xbc/0x100

stack backtrace:
Pid: 15445, comm: airodump-ng Not tainted 2.6.38-rc5-341cd #4
Call Trace:
 [&lt;ffffffff810a3f0a&gt;] ? print_circular_bug+0xfa/0x100
 [&lt;ffffffff810a7222&gt;] ? __lock_acquire+0x1622/0x1d10
 [&lt;ffffffff810a1f99&gt;] ? trace_hardirqs_off_caller+0x29/0xc0
 [&lt;ffffffff810a79d6&gt;] ? lock_acquire+0xc6/0x280
 [&lt;ffffffff816b1266&gt;] ? cfg80211_wext_siwfreq+0xc6/0x100
 [&lt;ffffffff810a31d7&gt;] ? mark_held_locks+0x67/0x90
 [&lt;ffffffff816d6bce&gt;] ? mutex_lock_nested+0x6e/0x4b0
 [&lt;ffffffff816b1266&gt;] ? cfg80211_wext_siwfreq+0xc6/0x100
 [&lt;ffffffff810a31d7&gt;] ? mark_held_locks+0x67/0x90
 [&lt;ffffffff816b1266&gt;] ? cfg80211_wext_siwfreq+0xc6/0x100
 [&lt;ffffffff816b1266&gt;] ? cfg80211_wext_siwfreq+0xc6/0x100
 [&lt;ffffffff816b2fad&gt;] ? ioctl_standard_call+0x5d/0xd0
 [&lt;ffffffff8157818b&gt;] ? __dev_get_by_name+0x9b/0xc0
 [&lt;ffffffff816b2f50&gt;] ? ioctl_standard_call+0x0/0xd0
 [&lt;ffffffff816b3223&gt;] ? T.808+0x163/0x170
 [&lt;ffffffff8112ddf2&gt;] ? might_fault+0x72/0xd0
 [&lt;ffffffff816b326a&gt;] ? wext_handle_ioctl+0x3a/0x90
 [&lt;ffffffff8112de3b&gt;] ? might_fault+0xbb/0xd0
 [&lt;ffffffff815798d2&gt;] ? dev_ioctl+0x6f2/0x830
 [&lt;ffffffff810a1bae&gt;] ? put_lock_stats+0xe/0x40
 [&lt;ffffffff810a1c8c&gt;] ? lock_release_holdtime+0xac/0x150
 [&lt;ffffffff8155cf3d&gt;] ? sock_ioctl+0xfd/0x290
 [&lt;ffffffff8117dffd&gt;] ? do_vfs_ioctl+0x9d/0x590
 [&lt;ffffffff8116c8ff&gt;] ? fget_light+0x1df/0x3c0
 [&lt;ffffffff8117e53a&gt;] ? sys_ioctl+0x4a/0x80
 [&lt;ffffffff81003192&gt;] ? system_call_fastpath+0x16/0x1b

Signed-off-by: Daniel J Blueman &lt;daniel.blueman@gmail.com&gt;
Acked-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I previously managed to reproduce a hang while scanning wireless
channels (reproducible with airodump-ng hopping channels); subsequent
lockdep instrumentation revealed a lock ordering issue.

Without knowing the design intent, it looks like the locks should be
taken in reverse order; please comment.

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.38-rc5-341cd #4
-------------------------------------------------------
airodump-ng/15445 is trying to acquire lock:
 (&amp;rdev-&gt;devlist_mtx){+.+.+.}, at: [&lt;ffffffff816b1266&gt;]
cfg80211_wext_siwfreq+0xc6/0x100

but task is already holding lock:
 (&amp;wdev-&gt;mtx){+.+.+.}, at: [&lt;ffffffff816b125c&gt;] cfg80211_wext_siwfreq+0xbc/0x100

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;wdev-&gt;mtx){+.+.+.}:
       [&lt;ffffffff810a79d6&gt;] lock_acquire+0xc6/0x280
       [&lt;ffffffff816d6bce&gt;] mutex_lock_nested+0x6e/0x4b0
       [&lt;ffffffff81696080&gt;] cfg80211_netdev_notifier_call+0x430/0x5f0
       [&lt;ffffffff8109351b&gt;] notifier_call_chain+0x8b/0x100
       [&lt;ffffffff810935b1&gt;] raw_notifier_call_chain+0x11/0x20
       [&lt;ffffffff81576d92&gt;] call_netdevice_notifiers+0x32/0x60
       [&lt;ffffffff815771a4&gt;] __dev_notify_flags+0x34/0x80
       [&lt;ffffffff81577230&gt;] dev_change_flags+0x40/0x70
       [&lt;ffffffff8158587c&gt;] do_setlink+0x1fc/0x8d0
       [&lt;ffffffff81586042&gt;] rtnl_setlink+0xf2/0x140
       [&lt;ffffffff81586923&gt;] rtnetlink_rcv_msg+0x163/0x270
       [&lt;ffffffff8159d741&gt;] netlink_rcv_skb+0xa1/0xd0
       [&lt;ffffffff815867b0&gt;] rtnetlink_rcv+0x20/0x30
       [&lt;ffffffff8159d39a&gt;] netlink_unicast+0x2ba/0x300
       [&lt;ffffffff8159dd57&gt;] netlink_sendmsg+0x267/0x3e0
       [&lt;ffffffff8155e364&gt;] sock_sendmsg+0xe4/0x110
       [&lt;ffffffff8155f3a3&gt;] sys_sendmsg+0x253/0x3b0
       [&lt;ffffffff81003192&gt;] system_call_fastpath+0x16/0x1b

-&gt; #0 (&amp;rdev-&gt;devlist_mtx){+.+.+.}:
       [&lt;ffffffff810a7222&gt;] __lock_acquire+0x1622/0x1d10
       [&lt;ffffffff810a79d6&gt;] lock_acquire+0xc6/0x280
       [&lt;ffffffff816d6bce&gt;] mutex_lock_nested+0x6e/0x4b0
       [&lt;ffffffff816b1266&gt;] cfg80211_wext_siwfreq+0xc6/0x100
       [&lt;ffffffff816b2fad&gt;] ioctl_standard_call+0x5d/0xd0
       [&lt;ffffffff816b3223&gt;] T.808+0x163/0x170
       [&lt;ffffffff816b326a&gt;] wext_handle_ioctl+0x3a/0x90
       [&lt;ffffffff815798d2&gt;] dev_ioctl+0x6f2/0x830
       [&lt;ffffffff8155cf3d&gt;] sock_ioctl+0xfd/0x290
       [&lt;ffffffff8117dffd&gt;] do_vfs_ioctl+0x9d/0x590
       [&lt;ffffffff8117e53a&gt;] sys_ioctl+0x4a/0x80
       [&lt;ffffffff81003192&gt;] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

2 locks held by airodump-ng/15445:
 #0:  (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff81586782&gt;] rtnl_lock+0x12/0x20
 #1:  (&amp;wdev-&gt;mtx){+.+.+.}, at: [&lt;ffffffff816b125c&gt;]
cfg80211_wext_siwfreq+0xbc/0x100

stack backtrace:
Pid: 15445, comm: airodump-ng Not tainted 2.6.38-rc5-341cd #4
Call Trace:
 [&lt;ffffffff810a3f0a&gt;] ? print_circular_bug+0xfa/0x100
 [&lt;ffffffff810a7222&gt;] ? __lock_acquire+0x1622/0x1d10
 [&lt;ffffffff810a1f99&gt;] ? trace_hardirqs_off_caller+0x29/0xc0
 [&lt;ffffffff810a79d6&gt;] ? lock_acquire+0xc6/0x280
 [&lt;ffffffff816b1266&gt;] ? cfg80211_wext_siwfreq+0xc6/0x100
 [&lt;ffffffff810a31d7&gt;] ? mark_held_locks+0x67/0x90
 [&lt;ffffffff816d6bce&gt;] ? mutex_lock_nested+0x6e/0x4b0
 [&lt;ffffffff816b1266&gt;] ? cfg80211_wext_siwfreq+0xc6/0x100
 [&lt;ffffffff810a31d7&gt;] ? mark_held_locks+0x67/0x90
 [&lt;ffffffff816b1266&gt;] ? cfg80211_wext_siwfreq+0xc6/0x100
 [&lt;ffffffff816b1266&gt;] ? cfg80211_wext_siwfreq+0xc6/0x100
 [&lt;ffffffff816b2fad&gt;] ? ioctl_standard_call+0x5d/0xd0
 [&lt;ffffffff8157818b&gt;] ? __dev_get_by_name+0x9b/0xc0
 [&lt;ffffffff816b2f50&gt;] ? ioctl_standard_call+0x0/0xd0
 [&lt;ffffffff816b3223&gt;] ? T.808+0x163/0x170
 [&lt;ffffffff8112ddf2&gt;] ? might_fault+0x72/0xd0
 [&lt;ffffffff816b326a&gt;] ? wext_handle_ioctl+0x3a/0x90
 [&lt;ffffffff8112de3b&gt;] ? might_fault+0xbb/0xd0
 [&lt;ffffffff815798d2&gt;] ? dev_ioctl+0x6f2/0x830
 [&lt;ffffffff810a1bae&gt;] ? put_lock_stats+0xe/0x40
 [&lt;ffffffff810a1c8c&gt;] ? lock_release_holdtime+0xac/0x150
 [&lt;ffffffff8155cf3d&gt;] ? sock_ioctl+0xfd/0x290
 [&lt;ffffffff8117dffd&gt;] ? do_vfs_ioctl+0x9d/0x590
 [&lt;ffffffff8116c8ff&gt;] ? fget_light+0x1df/0x3c0
 [&lt;ffffffff8117e53a&gt;] ? sys_ioctl+0x4a/0x80
 [&lt;ffffffff81003192&gt;] ? system_call_fastpath+0x16/0x1b

Signed-off-by: Daniel J Blueman &lt;daniel.blueman@gmail.com&gt;
Acked-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT</title>
<updated>2011-01-21T01:02:05+00:00</updated>
<author>
<name>David Rientjes</name>
<email>rientjes@google.com</email>
</author>
<published>2011-01-20T22:44:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6a108a14fa356ef607be308b68337939e56ea94e'/>
<id>6a108a14fa356ef607be308b68337939e56ea94e</id>
<content type='text'>
The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.

This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel.  A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).

Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.

Reviewed-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Acked-by: David Woodhouse &lt;david.woodhouse@intel.com&gt;
Signed-off-by: David Rientjes &lt;rientjes@google.com&gt;
Cc: Greg KH &lt;gregkh@suse.de&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Robin Holt &lt;holt@sgi.com&gt;
Cc: &lt;linux-arch@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.

This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel.  A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).

Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.

Reviewed-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Acked-by: David Woodhouse &lt;david.woodhouse@intel.com&gt;
Signed-off-by: David Rientjes &lt;rientjes@google.com&gt;
Cc: Greg KH &lt;gregkh@suse.de&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Robin Holt &lt;holt@sgi.com&gt;
Cc: &lt;linux-arch@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: fix transposition of words in printk</title>
<updated>2011-01-04T19:43:01+00:00</updated>
<author>
<name>Bob Copeland</name>
<email>me@bobcopeland.com</email>
</author>
<published>2010-12-29T22:09:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ff039c6fb372c87a3cc4fd25bb846790cb35edb8'/>
<id>ff039c6fb372c87a3cc4fd25bb846790cb35edb8</id>
<content type='text'>
Fixes the misplaced article in the following:

"cfg80211: Updating information on frequency 5785 MHz for
    20 a MHz width channel with regulatory rule:"

Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes the misplaced article in the following:

"cfg80211: Updating information on frequency 5785 MHz for
    20 a MHz width channel with regulatory rule:"

Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nl80211: Export available antennas</title>
<updated>2010-12-20T19:49:47+00:00</updated>
<author>
<name>Bruno Randolf</name>
<email>br1@einfach.org</email>
</author>
<published>2010-12-16T02:30:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=39fd5de4472b7b222c6cec78d72b069133f694e4'/>
<id>39fd5de4472b7b222c6cec78d72b069133f694e4</id>
<content type='text'>
Export the information which antennas are available for configuration as TX or
RX antennas via nl80211.

Signed-off-by: Bruno Randolf &lt;br1@einfach.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Export the information which antennas are available for configuration as TX or
RX antennas via nl80211.

Signed-off-by: Bruno Randolf &lt;br1@einfach.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: Separate available antennas for RX and TX</title>
<updated>2010-12-20T19:46:58+00:00</updated>
<author>
<name>Bruno Randolf</name>
<email>br1@einfach.org</email>
</author>
<published>2010-12-16T02:30:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7f531e03abf0162df3966c4fa5fa6fdd9302cb6b'/>
<id>7f531e03abf0162df3966c4fa5fa6fdd9302cb6b</id>
<content type='text'>
As has been pointed out by Daniel Halperin some devices (e.g. Intel IWL5100)
can only TX from a subset of RX antennas, so use separate availability masks
for RX and TX.

Signed-off-by: Bruno Randolf &lt;br1@einfach.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As has been pointed out by Daniel Halperin some devices (e.g. Intel IWL5100)
can only TX from a subset of RX antennas, so use separate availability masks
for RX and TX.

Signed-off-by: Bruno Randolf &lt;br1@einfach.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: Send mesh non-HWMP path selection frames to userspace</title>
<updated>2010-12-20T19:46:58+00:00</updated>
<author>
<name>Javier Cardona</name>
<email>javier@cozybit.com</email>
</author>
<published>2010-12-17T01:37:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c7108a7111cd9e592d6ad498be37276dbea75d2b'/>
<id>c7108a7111cd9e592d6ad498be37276dbea75d2b</id>
<content type='text'>
Let path selection frames for protocols other than HWMP be sent to
userspace via NL80211_CMD_REGISTER_FRAME.  Also allow userspace to send
and receive mesh path selection frames.

Signed-off-by: Javier Cardona &lt;javier@cozybit.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Let path selection frames for protocols other than HWMP be sent to
userspace via NL80211_CMD_REGISTER_FRAME.  Also allow userspace to send
and receive mesh path selection frames.

Signed-off-by: Javier Cardona &lt;javier@cozybit.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: Let userspace enable and configure vendor specific path selection.</title>
<updated>2010-12-20T19:46:57+00:00</updated>
<author>
<name>Javier Cardona</name>
<email>javier@cozybit.com</email>
</author>
<published>2010-12-17T01:37:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c80d545da3f7c0e534ccd4a780f322f80a92cff1'/>
<id>c80d545da3f7c0e534ccd4a780f322f80a92cff1</id>
<content type='text'>
Userspace will now be allowed to toggle between the default path
selection algorithm (HWMP, implemented in the kernel), and a vendor
specific alternative.  Also in the same patch, allow userspace to add
information elements to mesh beacons.  This is accordance with the
Extensible Path Selection Framework specified in version 7.0 of the
802.11s draft.

Signed-off-by: Javier Cardona &lt;javier@cozybit.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Userspace will now be allowed to toggle between the default path
selection algorithm (HWMP, implemented in the kernel), and a vendor
specific alternative.  Also in the same patch, allow userspace to add
information elements to mesh beacons.  This is accordance with the
Extensible Path Selection Framework specified in version 7.0 of the
802.11s draft.

Signed-off-by: Javier Cardona &lt;javier@cozybit.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: Rename mesh_params to mesh_config to prepare for mesh_setup</title>
<updated>2010-12-20T19:46:57+00:00</updated>
<author>
<name>Javier Cardona</name>
<email>javier@cozybit.com</email>
</author>
<published>2010-12-17T01:37:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=24bdd9f4c9af75b33b438d60381a67626de0128d'/>
<id>24bdd9f4c9af75b33b438d60381a67626de0128d</id>
<content type='text'>
Mesh parameters can be to setup a mesh or to configure it.
This patch renames the ambiguous name mesh_params to mesh_config
in preparation for mesh_setup.

Signed-off-by: Javier Cardona &lt;javier@cozybit.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Mesh parameters can be to setup a mesh or to configure it.
This patch renames the ambiguous name mesh_params to mesh_config
in preparation for mesh_setup.

Signed-off-by: Javier Cardona &lt;javier@cozybit.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
