<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net/wireless/reg.c, branch v2.6.30</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>cfg80211: fix race between core hint and driver's custom apply</title>
<updated>2009-05-20T18:29:54+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-05-13T21:04:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5078b2e32ad4b1f753b1c837c15892202f753c97'/>
<id>5078b2e32ad4b1f753b1c837c15892202f753c97</id>
<content type='text'>
Its possible for cfg80211 to have scheduled the work and for
the global workqueue to not have kicked in prior to a cfg80211
driver's regulatory hint or wiphy_apply_custom_regulatory().

Although this is very unlikely its possible and should fix
this race. When this race would happen you are expected to have
hit a null pointer dereference panic.

Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Tested-by: Alan Jenkins &lt;alan-jenkins@tuffmail.co.uk&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>
Its possible for cfg80211 to have scheduled the work and for
the global workqueue to not have kicked in prior to a cfg80211
driver's regulatory hint or wiphy_apply_custom_regulatory().

Although this is very unlikely its possible and should fix
this race. When this race would happen you are expected to have
hit a null pointer dereference panic.

Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Tested-by: Alan Jenkins &lt;alan-jenkins@tuffmail.co.uk&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: fix comment on regulatory hint processing</title>
<updated>2009-05-04T20:22:14+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-05-02T05:17:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=30a548c727514484b08ac06edf0a7eb0f7fd70bf'/>
<id>30a548c727514484b08ac06edf0a7eb0f7fd70bf</id>
<content type='text'>
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.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>
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: fix bug while trying to process beacon hints on init</title>
<updated>2009-05-04T20:22:13+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-05-02T04:34:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b1ed8ddd21a2d7acf8efbb60a112ea5c9f914159'/>
<id>b1ed8ddd21a2d7acf8efbb60a112ea5c9f914159</id>
<content type='text'>
During initialization we would not have received any beacons
so skip processing reg beacon hints, also adds a check to
reg_is_world_roaming() for last_request before accessing its
fields.

This should fix this:

BUG: unable to handle kernel NULL pointer dereference at

IP: [&lt;e0171332&gt;] wiphy_update_regulatory+0x20f/0x295

*pdpt = 0000000008bf1001 *pde = 0000000000000000
Oops: 0000 [#1]
last sysfs file: /sys/class/backlight/eeepc/brightness
Modules linked in: ath5k(+) mac80211 led_class cfg80211
go_bit cfbcopyarea cfbimgblt cfbfillrect ipv6
ydev usual_tables(P) snd_hda_codec_realtek snd_hda_intel
nd_hwdep uhci_hcd snd_pcm_oss snd_mixer_oss i2c_i801
e serio_raw i2c_core pcspkr atl2 snd_pcm intel_agp
re agpgart eeepc_laptop snd_page_alloc ac video backlight
rfkill button processor evdev thermal fan ata_generic

Pid: 2909, comm: modprobe Tainted: Pc #112) 701
EIP: 0060:[&lt;e0171332&gt;] EFLAGS: 00010246 CPU: 0
EIP is at wiphy_update_regulatory+0x20f/0x295 [cfg80211]
EAX: 00000000 EBX: c5da0000 ECX: 00000000 EDX: c5da0060
ESI: 0000001a EDI: c5da0060 EBP: df3bdd70 ESP: df3bdd40
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process modprobe (pid: 2909, ti=df3bc000 task=c5d030000)
Stack:
 df3bdd90 c5da0060 c04277e0 00000001 00000044 c04277e402
 00000002 c5da0000 0000001a c5da0060 df3bdda8 e01706a2 02
 00000282 000080d0 00000068 c5d53500 00000080 0000028240
Call Trace:
 [&lt;e01706a2&gt;] ? wiphy_register+0x122/0x1b7 [cfg80211]
 [&lt;e0328e02&gt;] ? ieee80211_register_hw+0xd8/0x346
 [&lt;e06a7c9f&gt;] ? ath5k_hw_set_bssid_mask+0x71/0x78 [ath5k]
 [&lt;e06b0c52&gt;] ? ath5k_pci_probe+0xa5c/0xd0a [ath5k]
 [&lt;c01a6037&gt;] ? sysfs_find_dirent+0x16/0x27
 [&lt;c01fec95&gt;] ? local_pci_probe+0xe/0x10
 [&lt;c01ff526&gt;] ? pci_device_probe+0x48/0x66
 [&lt;c024c9fd&gt;] ? driver_probe_device+0x7f/0xf2
 [&lt;c024cab3&gt;] ? __driver_attach+0x43/0x5f
 [&lt;c024c0af&gt;] ? bus_for_each_dev+0x39/0x5a
 [&lt;c024c8d0&gt;] ? driver_attach+0x14/0x16
 [&lt;c024ca70&gt;] ? __driver_attach+0x0/0x5f
 [&lt;c024c5b3&gt;] ? bus_add_driver+0xd7/0x1e7
 [&lt;c024ccb9&gt;] ? driver_register+0x7b/0xd7
 [&lt;c01ff827&gt;] ? __pci_register_driver+0x32/0x85
 [&lt;e00a8018&gt;] ? init_ath5k_pci+0x18/0x30 [ath5k]
 [&lt;c0101131&gt;] ? _stext+0x49/0x10b
 [&lt;e00a8000&gt;] ? init_ath5k_pci+0x0/0x30 [ath5k]
 [&lt;c012f452&gt;] ? __blocking_notifier_call_chain+0x40/0x4c
 [&lt;c013a714&gt;] ? sys_init_module+0x87/0x18b
 [&lt;c0102804&gt;] ? sysenter_do_call+0x12/0x22
Code: b8 da 17 e0 83 c0 04 e8 92 f9 ff ff 84 c0 75 2a 8b
85 c0 74 0c 83 c0 04 e8 7c f9 ff ff 84 c0 75 14 a1 bc da
4 03 74 66 8b 4d d4 80 79 08 00 74 5d a1 e0 d2 17 e0 48
EIP: [&lt;e0171332&gt;] wiphy_update_regulatory+0x20f/0x295
SP 0068:df3bdd40
CR2: 0000000000000004
---[ end trace 830f2dd2a95fd1a8 ]---

This issue is hard to reproduce, but it was noticed and discussed on
this thread:

http://marc.info/?t=123938022700005&amp;r=1&amp;w=2

Cc: stable@kernel.org
Reported-by: Alan Jenkins &lt;alan-jenkins@tuffmail.co.uk&gt;
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.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>
During initialization we would not have received any beacons
so skip processing reg beacon hints, also adds a check to
reg_is_world_roaming() for last_request before accessing its
fields.

This should fix this:

BUG: unable to handle kernel NULL pointer dereference at

IP: [&lt;e0171332&gt;] wiphy_update_regulatory+0x20f/0x295

*pdpt = 0000000008bf1001 *pde = 0000000000000000
Oops: 0000 [#1]
last sysfs file: /sys/class/backlight/eeepc/brightness
Modules linked in: ath5k(+) mac80211 led_class cfg80211
go_bit cfbcopyarea cfbimgblt cfbfillrect ipv6
ydev usual_tables(P) snd_hda_codec_realtek snd_hda_intel
nd_hwdep uhci_hcd snd_pcm_oss snd_mixer_oss i2c_i801
e serio_raw i2c_core pcspkr atl2 snd_pcm intel_agp
re agpgart eeepc_laptop snd_page_alloc ac video backlight
rfkill button processor evdev thermal fan ata_generic

Pid: 2909, comm: modprobe Tainted: Pc #112) 701
EIP: 0060:[&lt;e0171332&gt;] EFLAGS: 00010246 CPU: 0
EIP is at wiphy_update_regulatory+0x20f/0x295 [cfg80211]
EAX: 00000000 EBX: c5da0000 ECX: 00000000 EDX: c5da0060
ESI: 0000001a EDI: c5da0060 EBP: df3bdd70 ESP: df3bdd40
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process modprobe (pid: 2909, ti=df3bc000 task=c5d030000)
Stack:
 df3bdd90 c5da0060 c04277e0 00000001 00000044 c04277e402
 00000002 c5da0000 0000001a c5da0060 df3bdda8 e01706a2 02
 00000282 000080d0 00000068 c5d53500 00000080 0000028240
Call Trace:
 [&lt;e01706a2&gt;] ? wiphy_register+0x122/0x1b7 [cfg80211]
 [&lt;e0328e02&gt;] ? ieee80211_register_hw+0xd8/0x346
 [&lt;e06a7c9f&gt;] ? ath5k_hw_set_bssid_mask+0x71/0x78 [ath5k]
 [&lt;e06b0c52&gt;] ? ath5k_pci_probe+0xa5c/0xd0a [ath5k]
 [&lt;c01a6037&gt;] ? sysfs_find_dirent+0x16/0x27
 [&lt;c01fec95&gt;] ? local_pci_probe+0xe/0x10
 [&lt;c01ff526&gt;] ? pci_device_probe+0x48/0x66
 [&lt;c024c9fd&gt;] ? driver_probe_device+0x7f/0xf2
 [&lt;c024cab3&gt;] ? __driver_attach+0x43/0x5f
 [&lt;c024c0af&gt;] ? bus_for_each_dev+0x39/0x5a
 [&lt;c024c8d0&gt;] ? driver_attach+0x14/0x16
 [&lt;c024ca70&gt;] ? __driver_attach+0x0/0x5f
 [&lt;c024c5b3&gt;] ? bus_add_driver+0xd7/0x1e7
 [&lt;c024ccb9&gt;] ? driver_register+0x7b/0xd7
 [&lt;c01ff827&gt;] ? __pci_register_driver+0x32/0x85
 [&lt;e00a8018&gt;] ? init_ath5k_pci+0x18/0x30 [ath5k]
 [&lt;c0101131&gt;] ? _stext+0x49/0x10b
 [&lt;e00a8000&gt;] ? init_ath5k_pci+0x0/0x30 [ath5k]
 [&lt;c012f452&gt;] ? __blocking_notifier_call_chain+0x40/0x4c
 [&lt;c013a714&gt;] ? sys_init_module+0x87/0x18b
 [&lt;c0102804&gt;] ? sysenter_do_call+0x12/0x22
Code: b8 da 17 e0 83 c0 04 e8 92 f9 ff ff 84 c0 75 2a 8b
85 c0 74 0c 83 c0 04 e8 7c f9 ff ff 84 c0 75 14 a1 bc da
4 03 74 66 8b 4d d4 80 79 08 00 74 5d a1 e0 d2 17 e0 48
EIP: [&lt;e0171332&gt;] wiphy_update_regulatory+0x20f/0x295
SP 0068:df3bdd40
CR2: 0000000000000004
---[ end trace 830f2dd2a95fd1a8 ]---

This issue is hard to reproduce, but it was noticed and discussed on
this thread:

http://marc.info/?t=123938022700005&amp;r=1&amp;w=2

Cc: stable@kernel.org
Reported-by: Alan Jenkins &lt;alan-jenkins@tuffmail.co.uk&gt;
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: fix race condition with wiphy_apply_custom_regulatory()</title>
<updated>2009-05-04T20:22:12+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-05-01T22:44:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ac46d48e00349c63650b3cc6f9460fcc183da6a6'/>
<id>ac46d48e00349c63650b3cc6f9460fcc183da6a6</id>
<content type='text'>
We forgot to lock using the cfg80211_mutex in
wiphy_apply_custom_regulatory(). Without the lock
there is possible race between processing a reply from CRDA
and a driver calling wiphy_apply_custom_regulatory(). During
the processing of the reply from CRDA we free last_request and
wiphy_apply_custom_regulatory() eventually accesses an
element from last_request in the through freq_reg_info_regd().

This is very difficult to reproduce (I haven't), it takes us
3 hours and you need to be banging hard, but the race is obvious
by looking at the code.

This should only affect those who use this caller, which currently
is ath5k, ath9k, and ar9170.

EIP: 0060:[&lt;f8ebec50&gt;] EFLAGS: 00210282 CPU: 1
EIP is at freq_reg_info_regd+0x24/0x121 [cfg80211]
EAX: 00000000 EBX: f7ca0060 ECX: f5183d94 EDX: 0024cde0
ESI: f8f56edc EDI: 00000000 EBP: 00000000 ESP: f5183d44
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modprobe (pid: 14617, ti=f5182000 task=f3934d10 task.ti=f5182000)
Stack: c0505300 f7ca0ab4 f5183d94 0024cde0 f8f403a6 f8f63160 f7ca0060 00000000
00000000 f8ebedf8 f5183d90 f8f56edc 00000000 00000004 00000f40 f8f56edc
f7ca0060 f7ca1234 00000000 00000000 00000000 f7ca14f0 f7ca0ab4 f7ca1289
Call Trace:
[&lt;f8ebedf8&gt;] wiphy_apply_custom_regulatory+0x8f/0x122 [cfg80211]
[&lt;f8f3f798&gt;] ath_attach+0x707/0x9e6 [ath9k]
[&lt;f8f45e46&gt;] ath_pci_probe+0x18d/0x29a [ath9k]
[&lt;c023c7ba&gt;] pci_device_probe+0xa3/0xe4
[&lt;c02a860b&gt;] really_probe+0xd7/0x1de
[&lt;c02a87e7&gt;] __driver_attach+0x37/0x55
[&lt;c02a7eed&gt;] bus_for_each_dev+0x31/0x57
[&lt;c02a83bd&gt;] driver_attach+0x16/0x18
[&lt;c02a78e6&gt;] bus_add_driver+0xec/0x21b
[&lt;c02a8959&gt;] driver_register+0x85/0xe2
[&lt;c023c9bb&gt;] __pci_register_driver+0x3c/0x69
[&lt;f8e93043&gt;] ath9k_init+0x43/0x68 [ath9k]
[&lt;c010112b&gt;] _stext+0x3b/0x116
[&lt;c014a872&gt;] sys_init_module+0x8a/0x19e
[&lt;c01049ad&gt;] sysenter_do_call+0x12/0x21
[&lt;ffffe430&gt;] 0xffffe430
=======================
Code: 0f 94 c0 c3 31 c0 c3 55 57 56 53 89 c3 83 ec 14 8b 74 24 2c 89 54 24 0c 89 4c 24 08 85 f6 75
06 8b 35 c8 bb ec f8 a1 cc bb ec f8 &lt;8b&gt; 40 04 83 f8 03 74 3a 48 74 37 8b 43 28 85 c0 74 30 89 c6
8b
EIP: [&lt;f8ebec50&gt;] freq_reg_info_regd+0x24/0x121 [cfg80211] SS:ESP 0068:f5183d44

Cc: stable@kernel.org
Reported-by: Nataraj Sadasivam &lt;Nataraj.Sadasivam@Atheros.com&gt;
Reported-by: Vivek Natarajan &lt;Vivek.Natarajan@Atheros.com&gt;
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.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>
We forgot to lock using the cfg80211_mutex in
wiphy_apply_custom_regulatory(). Without the lock
there is possible race between processing a reply from CRDA
and a driver calling wiphy_apply_custom_regulatory(). During
the processing of the reply from CRDA we free last_request and
wiphy_apply_custom_regulatory() eventually accesses an
element from last_request in the through freq_reg_info_regd().

This is very difficult to reproduce (I haven't), it takes us
3 hours and you need to be banging hard, but the race is obvious
by looking at the code.

This should only affect those who use this caller, which currently
is ath5k, ath9k, and ar9170.

EIP: 0060:[&lt;f8ebec50&gt;] EFLAGS: 00210282 CPU: 1
EIP is at freq_reg_info_regd+0x24/0x121 [cfg80211]
EAX: 00000000 EBX: f7ca0060 ECX: f5183d94 EDX: 0024cde0
ESI: f8f56edc EDI: 00000000 EBP: 00000000 ESP: f5183d44
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modprobe (pid: 14617, ti=f5182000 task=f3934d10 task.ti=f5182000)
Stack: c0505300 f7ca0ab4 f5183d94 0024cde0 f8f403a6 f8f63160 f7ca0060 00000000
00000000 f8ebedf8 f5183d90 f8f56edc 00000000 00000004 00000f40 f8f56edc
f7ca0060 f7ca1234 00000000 00000000 00000000 f7ca14f0 f7ca0ab4 f7ca1289
Call Trace:
[&lt;f8ebedf8&gt;] wiphy_apply_custom_regulatory+0x8f/0x122 [cfg80211]
[&lt;f8f3f798&gt;] ath_attach+0x707/0x9e6 [ath9k]
[&lt;f8f45e46&gt;] ath_pci_probe+0x18d/0x29a [ath9k]
[&lt;c023c7ba&gt;] pci_device_probe+0xa3/0xe4
[&lt;c02a860b&gt;] really_probe+0xd7/0x1de
[&lt;c02a87e7&gt;] __driver_attach+0x37/0x55
[&lt;c02a7eed&gt;] bus_for_each_dev+0x31/0x57
[&lt;c02a83bd&gt;] driver_attach+0x16/0x18
[&lt;c02a78e6&gt;] bus_add_driver+0xec/0x21b
[&lt;c02a8959&gt;] driver_register+0x85/0xe2
[&lt;c023c9bb&gt;] __pci_register_driver+0x3c/0x69
[&lt;f8e93043&gt;] ath9k_init+0x43/0x68 [ath9k]
[&lt;c010112b&gt;] _stext+0x3b/0x116
[&lt;c014a872&gt;] sys_init_module+0x8a/0x19e
[&lt;c01049ad&gt;] sysenter_do_call+0x12/0x21
[&lt;ffffe430&gt;] 0xffffe430
=======================
Code: 0f 94 c0 c3 31 c0 c3 55 57 56 53 89 c3 83 ec 14 8b 74 24 2c 89 54 24 0c 89 4c 24 08 85 f6 75
06 8b 35 c8 bb ec f8 a1 cc bb ec f8 &lt;8b&gt; 40 04 83 f8 03 74 3a 48 74 37 8b 43 28 85 c0 74 30 89 c6
8b
EIP: [&lt;f8ebec50&gt;] freq_reg_info_regd+0x24/0x121 [cfg80211] SS:ESP 0068:f5183d44

Cc: stable@kernel.org
Reported-by: Nataraj Sadasivam &lt;Nataraj.Sadasivam@Atheros.com&gt;
Reported-by: Vivek Natarajan &lt;Vivek.Natarajan@Atheros.com&gt;
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: fix NULL pointer deference in reg_device_remove()</title>
<updated>2009-04-16T14:39:01+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-03-25T01:21:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0ad8acaf434d360ad99813d981a68e605d6c8179'/>
<id>0ad8acaf434d360ad99813d981a68e605d6c8179</id>
<content type='text'>
We won't ever get here as regulatory_hint_core() can only fail
on -ENOMEM and in that case we don't initialize cfg80211 but this is
technically correct code.

This is actually good for stable, where we don't check for -ENOMEM
failure on __regulatory_hint()'s failure.

Cc: stable@kernel.org
Reported-by: Quentin Armitage &lt;Quentin@armitage.org.uk&gt;
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.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>
We won't ever get here as regulatory_hint_core() can only fail
on -ENOMEM and in that case we don't initialize cfg80211 but this is
technically correct code.

This is actually good for stable, where we don't check for -ENOMEM
failure on __regulatory_hint()'s failure.

Cc: stable@kernel.org
Reported-by: Quentin Armitage &lt;Quentin@armitage.org.uk&gt;
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: remove code about country IE support with OLD_REG</title>
<updated>2009-03-28T00:13:07+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-03-21T03:53:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=86f04680df4a136a4a90501572dc2f31f8426581'/>
<id>86f04680df4a136a4a90501572dc2f31f8426581</id>
<content type='text'>
We had left in code to allow interested developers to add
support for parsing country IEs when OLD_REG was enabled.
This never happened and since we're going to remove OLD_REG
lets just remove these comments and code for it.

This code path was never being entered so this has no
functional change.

Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.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>
We had left in code to allow interested developers to add
support for parsing country IEs when OLD_REG was enabled.
This never happened and since we're going to remove OLD_REG
lets just remove these comments and code for it.

This code path was never being entered so this has no
functional change.

Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: make regdom module parameter available oustide of OLD_REG</title>
<updated>2009-03-28T00:13:07+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-03-21T03:53:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6ee7d33056f6e6fc7437d980dcc741816deedd0f'/>
<id>6ee7d33056f6e6fc7437d980dcc741816deedd0f</id>
<content type='text'>
It seems a few users are using this module parameter although its not
recommended. People are finding it useful despite there being utilities
for setting this in userspace. I'm not aware of any distribution using
this though.

Until userspace and distributions catch up with a default userspace
automatic replacement (GeoClue integration would be nirvana) we copy
the ieee80211_regdom module parameter from OLD_REG to the new reg
code to help these users migrate.

Users who are using the non-valid ISO / IEC 3166 alpha "EU" in their
ieee80211_regdom module parameter and migrate to non-OLD_REG enabled
system will world roam.

This also schedules removal of this same ieee80211_regdom module
parameter circa March 2010. Hope is by then nirvana is reached and
users will abandoned the module parameter completely.

Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.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>
It seems a few users are using this module parameter although its not
recommended. People are finding it useful despite there being utilities
for setting this in userspace. I'm not aware of any distribution using
this though.

Until userspace and distributions catch up with a default userspace
automatic replacement (GeoClue integration would be nirvana) we copy
the ieee80211_regdom module parameter from OLD_REG to the new reg
code to help these users migrate.

Users who are using the non-valid ISO / IEC 3166 alpha "EU" in their
ieee80211_regdom module parameter and migrate to non-OLD_REG enabled
system will world roam.

This also schedules removal of this same ieee80211_regdom module
parameter circa March 2010. Hope is by then nirvana is reached and
users will abandoned the module parameter completely.

Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: fix incorrect assumption on last_request for 11d</title>
<updated>2009-03-28T00:13:07+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-03-21T03:53:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=cc0b6fe88e99096868bdbacbf486c97299533b5a'/>
<id>cc0b6fe88e99096868bdbacbf486c97299533b5a</id>
<content type='text'>
The incorrect assumption is the last regulatory request
(last_request) is always a country IE when processing
country IEs. Although this is true 99% of the time the
first time this happens this could not be true.

This fixes an oops in the branch check for the last_request
when accessing drv_last_ie. The access was done under the
assumption the struct won't be null.

Note to stable: to port to 29 replace as follows, only 29 has
country IE code:

s|NL80211_REGDOM_SET_BY_COUNTRY_IE|REGDOM_SET_BY_COUNTRY_IE

Cc: stable@kernel.org
Reported-by: Quentin Armitage &lt;Quentin@armitage.org.uk&gt;
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.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>
The incorrect assumption is the last regulatory request
(last_request) is always a country IE when processing
country IEs. Although this is true 99% of the time the
first time this happens this could not be true.

This fixes an oops in the branch check for the last_request
when accessing drv_last_ie. The access was done under the
assumption the struct won't be null.

Note to stable: to port to 29 replace as follows, only 29 has
country IE code:

s|NL80211_REGDOM_SET_BY_COUNTRY_IE|REGDOM_SET_BY_COUNTRY_IE

Cc: stable@kernel.org
Reported-by: Quentin Armitage &lt;Quentin@armitage.org.uk&gt;
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: force last_request to be set for OLD_REG if regdom is EU</title>
<updated>2009-03-28T00:13:06+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-03-21T03:53:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2e097dc65673ed421bbc2e49f52c125aa43a8ee6'/>
<id>2e097dc65673ed421bbc2e49f52c125aa43a8ee6</id>
<content type='text'>
Although EU is a bogus alpha2 we need to process the send request
as our code depends on last_request being set.

Cc: stable@kernel.org
Reported-by: Quentin Armitage &lt;Quentin@armitage.org.uk&gt;
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.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>
Although EU is a bogus alpha2 we need to process the send request
as our code depends on last_request being set.

Cc: stable@kernel.org
Reported-by: Quentin Armitage &lt;Quentin@armitage.org.uk&gt;
Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: add regulatory netlink multicast group</title>
<updated>2009-03-16T22:09:40+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-03-10T02:07:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=73d54c9e74c4d8ee8a41bc516f481f0f754eca32'/>
<id>73d54c9e74c4d8ee8a41bc516f481f0f754eca32</id>
<content type='text'>
This allows us to send to userspace "regulatory" events.
For now we just send an event when we change regulatory domains.
We also notify userspace when devices are using their own custom
world roaming regulatory domains.

Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.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>
This allows us to send to userspace "regulatory" events.
For now we just send an event when we change regulatory domains.
We also notify userspace when devices are using their own custom
world roaming regulatory domains.

Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
