<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/wireless/rt2x00, branch v3.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>rt2x00: fix random stalls</title>
<updated>2012-03-12T18:00:17+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2012-03-09T11:39:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3780d038fdf4b5ef26ead10b0604ab1f46dd9510'/>
<id>3780d038fdf4b5ef26ead10b0604ab1f46dd9510</id>
<content type='text'>
Is possible that we stop queue and then do not wake up it again,
especially when packets are transmitted fast. That can be easily
reproduced with modified tx queue entry_num to some small value e.g. 16.

If mac80211 already hold local-&gt;queue_stop_reason_lock, then we can wait
on that lock in both rt2x00queue_pause_queue() and
rt2x00queue_unpause_queue(). After drooping -&gt;queue_stop_reason_lock
is possible that __ieee80211_wake_queue() will be performed before
__ieee80211_stop_queue(), hence we stop queue and newer wake up it
again.

Another race condition is possible when between rt2x00queue_threshold()
check and rt2x00queue_pause_queue() we will process all pending tx
buffers on different cpu. This might happen if for example interrupt
will be triggered on cpu performing rt2x00mac_tx().

To prevent race conditions serialize pause/unpause by queue-&gt;tx_lock.

Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Acked-by: Gertjan van Wingerde &lt;gwingerde@gmail.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>
Is possible that we stop queue and then do not wake up it again,
especially when packets are transmitted fast. That can be easily
reproduced with modified tx queue entry_num to some small value e.g. 16.

If mac80211 already hold local-&gt;queue_stop_reason_lock, then we can wait
on that lock in both rt2x00queue_pause_queue() and
rt2x00queue_unpause_queue(). After drooping -&gt;queue_stop_reason_lock
is possible that __ieee80211_wake_queue() will be performed before
__ieee80211_stop_queue(), hence we stop queue and newer wake up it
again.

Another race condition is possible when between rt2x00queue_threshold()
check and rt2x00queue_pause_queue() we will process all pending tx
buffers on different cpu. This might happen if for example interrupt
will be triggered on cpu performing rt2x00mac_tx().

To prevent race conditions serialize pause/unpause by queue-&gt;tx_lock.

Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Acked-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rt2x00: fix a possible NULL pointer dereference</title>
<updated>2012-02-21T19:45:25+00:00</updated>
<author>
<name>Gabor Juhos</name>
<email>juhosg@openwrt.org</email>
</author>
<published>2012-02-16T19:44:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7be081539e540517d5e1fcbf96b8080074afbf08'/>
<id>7be081539e540517d5e1fcbf96b8080074afbf08</id>
<content type='text'>
The 'rt2x00lib_probe_dev' function tries to
allocate the workqueue. If the allocation
fails, 'rt2x00_lib_remove_dev' is called on
the error path. Because 'rt2x00dev-&gt;workqueue'
is NULL in this case, the 'destroy_workqueue'
call will cause a NULL pointer dereference.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Acked-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.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 'rt2x00lib_probe_dev' function tries to
allocate the workqueue. If the allocation
fails, 'rt2x00_lib_remove_dev' is called on
the error path. Because 'rt2x00dev-&gt;workqueue'
is NULL in this case, the 'destroy_workqueue'
call will cause a NULL pointer dereference.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Acked-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rt2800lib: fix wrong -128dBm when signal is stronger than -12dBm</title>
<updated>2012-02-01T20:25:59+00:00</updated>
<author>
<name>Luigi Tarenga</name>
<email>luigi.tarenga@gmail.com</email>
</author>
<published>2012-01-31T17:51:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7fc417556473f15efac269523c17eb92103c6484'/>
<id>7fc417556473f15efac269523c17eb92103c6484</id>
<content type='text'>
This patch correct the type of variables containing the rssi
values read from the rxwi.

In function rt2800_agc_to_rssi() 3 variables (rssi0, rssi1, rss2)
defined as int was assigned a 16bit signed values as unsigned.
From a test with a hi-gain antenna I verified that the rxwi
contains signed rssi values in the  range -13/+81 (inclusive)
with 0 as an error condition. In case of negative values a
condition is triggered and the function return -128dBm while
the signal is at its maximum. This patch correct the cast so
negative values are not treated as very high positive values
(ex. -13 does not become 243).

Signed-off-by: Luigi Tarenga &lt;luigi.tarenga@gmail.com&gt;
Reviewed-by: Stanislaw Gruszka &lt;sgruszka@redhat.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 patch correct the type of variables containing the rssi
values read from the rxwi.

In function rt2800_agc_to_rssi() 3 variables (rssi0, rssi1, rss2)
defined as int was assigned a 16bit signed values as unsigned.
From a test with a hi-gain antenna I verified that the rxwi
contains signed rssi values in the  range -13/+81 (inclusive)
with 0 as an error condition. In case of negative values a
condition is triggered and the function return -128dBm while
the signal is at its maximum. This patch correct the cast so
negative values are not treated as very high positive values
(ex. -13 does not become 243).

Signed-off-by: Luigi Tarenga &lt;luigi.tarenga@gmail.com&gt;
Reviewed-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rt2800pci: fix spurious interrupts generation</title>
<updated>2012-01-13T19:40:57+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2012-01-13T11:59:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd'/>
<id>dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd</id>
<content type='text'>
Same devices can generate interrupt without properly setting bit in
INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line
will be disabled by interrupts controller driver.

We discovered that clearing INT_MASK_CSR stops such behaviour. We
previously first read that register, and then clear all know interrupt
sources bits and do not touch reserved bits. After this patch, we write
to all register content (I believe writing to reserved bits on that
register will not cause any problems, I tested that on my rt2800pci
device).

This fix very bad performance problem, practically making device
unusable (since worked without interrupts), reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=658451

We previously tried to workaround that issue in commit
4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious
interrupts", but it was reverted in commit
82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6
as thing, that will prevent to detect real spurious interrupts.

Reported-and-tested-by: Amir Hedayaty &lt;hedayaty@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Acked-by: Gertjan van Wingerde &lt;gwingerde@gmail.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>
Same devices can generate interrupt without properly setting bit in
INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line
will be disabled by interrupts controller driver.

We discovered that clearing INT_MASK_CSR stops such behaviour. We
previously first read that register, and then clear all know interrupt
sources bits and do not touch reserved bits. After this patch, we write
to all register content (I believe writing to reserved bits on that
register will not cause any problems, I tested that on my rt2800pci
device).

This fix very bad performance problem, practically making device
unusable (since worked without interrupts), reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=658451

We previously tried to workaround that issue in commit
4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious
interrupts", but it was reverted in commit
82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6
as thing, that will prevent to detect real spurious interrupts.

Reported-and-tested-by: Amir Hedayaty &lt;hedayaty@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Acked-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core</title>
<updated>2012-01-07T20:03:30+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-01-07T20:03:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7affca3537d74365128e477b40c529d6f2fe86c8'/>
<id>7affca3537d74365128e477b40c529d6f2fe86c8</id>
<content type='text'>
* 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (73 commits)
  arm: fix up some samsung merge sysdev conversion problems
  firmware: Fix an oops on reading fw_priv-&gt;fw in sysfs loading file
  Drivers:hv: Fix a bug in vmbus_driver_unregister()
  driver core: remove __must_check from device_create_file
  debugfs: add missing #ifdef HAS_IOMEM
  arm: time.h: remove device.h #include
  driver-core: remove sysdev.h usage.
  clockevents: remove sysdev.h
  arm: convert sysdev_class to a regular subsystem
  arm: leds: convert sysdev_class to a regular subsystem
  kobject: remove kset_find_obj_hinted()
  m86k: gpio - convert sysdev_class to a regular subsystem
  mips: txx9_sram - convert sysdev_class to a regular subsystem
  mips: 7segled - convert sysdev_class to a regular subsystem
  sh: dma - convert sysdev_class to a regular subsystem
  sh: intc - convert sysdev_class to a regular subsystem
  power: suspend - convert sysdev_class to a regular subsystem
  power: qe_ic - convert sysdev_class to a regular subsystem
  power: cmm - convert sysdev_class to a regular subsystem
  s390: time - convert sysdev_class to a regular subsystem
  ...

Fix up conflicts with 'struct sysdev' removal from various platform
drivers that got changed:
 - arch/arm/mach-exynos/cpu.c
 - arch/arm/mach-exynos/irq-eint.c
 - arch/arm/mach-s3c64xx/common.c
 - arch/arm/mach-s3c64xx/cpu.c
 - arch/arm/mach-s5p64x0/cpu.c
 - arch/arm/mach-s5pv210/common.c
 - arch/arm/plat-samsung/include/plat/cpu.h
 - arch/powerpc/kernel/sysfs.c
and fix up cpu_is_hotpluggable() as per Greg in include/linux/cpu.h
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (73 commits)
  arm: fix up some samsung merge sysdev conversion problems
  firmware: Fix an oops on reading fw_priv-&gt;fw in sysfs loading file
  Drivers:hv: Fix a bug in vmbus_driver_unregister()
  driver core: remove __must_check from device_create_file
  debugfs: add missing #ifdef HAS_IOMEM
  arm: time.h: remove device.h #include
  driver-core: remove sysdev.h usage.
  clockevents: remove sysdev.h
  arm: convert sysdev_class to a regular subsystem
  arm: leds: convert sysdev_class to a regular subsystem
  kobject: remove kset_find_obj_hinted()
  m86k: gpio - convert sysdev_class to a regular subsystem
  mips: txx9_sram - convert sysdev_class to a regular subsystem
  mips: 7segled - convert sysdev_class to a regular subsystem
  sh: dma - convert sysdev_class to a regular subsystem
  sh: intc - convert sysdev_class to a regular subsystem
  power: suspend - convert sysdev_class to a regular subsystem
  power: qe_ic - convert sysdev_class to a regular subsystem
  power: cmm - convert sysdev_class to a regular subsystem
  s390: time - convert sysdev_class to a regular subsystem
  ...

Fix up conflicts with 'struct sysdev' removal from various platform
drivers that got changed:
 - arch/arm/mach-exynos/cpu.c
 - arch/arm/mach-exynos/irq-eint.c
 - arch/arm/mach-s3c64xx/common.c
 - arch/arm/mach-s3c64xx/cpu.c
 - arch/arm/mach-s5p64x0/cpu.c
 - arch/arm/mach-s5pv210/common.c
 - arch/arm/plat-samsung/include/plat/cpu.h
 - arch/powerpc/kernel/sysfs.c
and fix up cpu_is_hotpluggable() as per Greg in include/linux/cpu.h
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'driver-core-next' into Linux 3.2</title>
<updated>2012-01-06T19:42:52+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@suse.de</email>
</author>
<published>2012-01-06T19:42:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ff4b8a57f0aaa2882d444ca44b2b9b333d22a4df'/>
<id>ff4b8a57f0aaa2882d444ca44b2b9b333d22a4df</id>
<content type='text'>
This resolves the conflict in the arch/arm/mach-s3c64xx/s3c6400.c file,
and it fixes the build error in the arch/x86/kernel/microcode_core.c
file, that the merge did not catch.

The microcode_core.c patch was provided by Stephen Rothwell
&lt;sfr@canb.auug.org.au&gt; who was invaluable in the merge issues involved
with the large sysdev removal process in the driver-core tree.

Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This resolves the conflict in the arch/arm/mach-s3c64xx/s3c6400.c file,
and it fixes the build error in the arch/x86/kernel/microcode_core.c
file, that the merge did not catch.

The microcode_core.c patch was provided by Stephen Rothwell
&lt;sfr@canb.auug.org.au&gt; who was invaluable in the merge issues involved
with the large sysdev removal process in the driver-core tree.

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-next into for-davem</title>
<updated>2012-01-05T15:13:24+00:00</updated>
<author>
<name>John W. Linville</name>
<email>linville@tuxdriver.com</email>
</author>
<published>2012-01-05T15:12:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1032c736e81cdf490ae62f86da7efe67c3c3e61d'/>
<id>1032c736e81cdf490ae62f86da7efe67c3c3e61d</id>
<content type='text'>
Conflicts:
	drivers/net/wireless/b43legacy/dma.c
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	drivers/net/wireless/b43legacy/dma.c
</pre>
</div>
</content>
</entry>
<entry>
<title>rt2x00: Change RF3853 to RF3053.</title>
<updated>2012-01-04T19:31:46+00:00</updated>
<author>
<name>Gertjan van Wingerde</name>
<email>gwingerde@gmail.com</email>
</author>
<published>2011-12-28T00:53:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7fbaf3efb042871fce7c9cd706cf9f90d61b5e59'/>
<id>7fbaf3efb042871fce7c9cd706cf9f90d61b5e59</id>
<content type='text'>
According to the latest Ralink vendor drivers, this seems to be the real
RF chipset type.

Signed-off-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.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>
According to the latest Ralink vendor drivers, this seems to be the real
RF chipset type.

Signed-off-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rt2x00: RT3593 is also applicable to USB.</title>
<updated>2012-01-04T19:31:46+00:00</updated>
<author>
<name>Gertjan van Wingerde</name>
<email>gwingerde@gmail.com</email>
</author>
<published>2011-12-28T00:53:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5a87e7a706750c84b3b17943e55a9de77d40869d'/>
<id>5a87e7a706750c84b3b17943e55a9de77d40869d</id>
<content type='text'>
Signed-off-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.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: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rt2x00usb: Zero USB padding before sending URB</title>
<updated>2012-01-04T19:31:46+00:00</updated>
<author>
<name>Jakub Kiciński</name>
<email>kubakici@wp.pl</email>
</author>
<published>2011-12-28T00:53:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d823a50e55fade0eda3708b00dbf49c5476c82e2'/>
<id>d823a50e55fade0eda3708b00dbf49c5476c82e2</id>
<content type='text'>
When USB driver requires padding at the end of frame or URB it will report
this need by increasing return value of get_tx_data_len callback. Common
USB code uses that return value as desired URB length.

Ensure that appropriate part of skb's tailroom exists and is zeroed.

Signed-off-by: Jakub Kicinski &lt;kubakici@wp.pl&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
--
 drivers/net/wireless/rt2x00/rt2x00usb.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)
Signed-off-by: Gertjan van Wingerde &lt;gwingerde@gmail.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>
When USB driver requires padding at the end of frame or URB it will report
this need by increasing return value of get_tx_data_len callback. Common
USB code uses that return value as desired URB length.

Ensure that appropriate part of skb's tailroom exists and is zeroed.

Signed-off-by: Jakub Kicinski &lt;kubakici@wp.pl&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
--
 drivers/net/wireless/rt2x00/rt2x00usb.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)
Signed-off-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
