linux-toradex.git/drivers/net/wireless/iwlegacy, branch v3.0.44

iwl3945: fix possible il->txq NULL pointer dereference in delayed works

2012-03-23T18:20:52+00:00

commit 210787e82a0ac1ffb5d7be1c796f0c51050849ad upstream.

On il3945_down procedure we free tx queue data and nullify il->txq
pointer. After that we drop mutex and then cancel delayed works. There
is possibility, that after drooping mutex and before the cancel, some
delayed work will start and crash while trying to send commands to
the device. For example, here is reported crash in
il3945_bg_reg_txpower_periodic():
https://bugzilla.kernel.org/show_bug.cgi?id=42766#c10

Patch fix problem by adding il->txq check on works that send commands,
hence utilize tx queue.

Reported-by: Clemens Eisserer 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville

iwlegacy: 3945: fix hw passive scan on radar channels

2012-01-26T01:25:06+00:00

commit 68acc4afb040d98ddfd2cae0de09e2f4e1ee127f upstream.

Patch fix firmware error on "iw dev wlan0 scan passive" for
hardware scanning (with disable_hw_scan=0 module parameter).

 iwl3945 0000:03:00.0: Microcode SW error detected. Restarting 0x82000008.
 iwl3945 0000:03:00.0: Loaded firmware version: 15.32.2.9
 iwl3945 0000:03:00.0: Start IWL Error Log Dump:
 iwl3945 0000:03:00.0: Status: 0x0002A2E4, count: 1
 iwl3945 0000:03:00.0: Desc       Time       asrtPC blink2 ilink1  nmiPC   Line
 iwl3945 0000:03:00.0: SYSASSERT     (0x5) 0041263900 0x13756 0x0031C 0x00000 764
 iwl3945 0000:03:00.0: Error Reply type 0x000002FC cmd C_SCAN (0x80) seq 0x443E ser 0x00340000
 iwl3945 0000:03:00.0: Command C_SCAN failed: FW Error
 iwl3945 0000:03:00.0: Can't stop Rx DMA.

We have disable ability to change passive scanning to active on
particular channel when traffic is detected on that channel. Otherwise
firmware will report error, when we try to do passive scan on radar
channels.

Reported-and-debugged-by: Pedro Francisco 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlegacy: do not use interruptible waits

2011-10-03T18:41:12+00:00

commit 65d0f19e583e80e42b1c67c166bfc4dfdf6ab693 upstream.

iwlegacy version of fix:

commit effd4d9aece9184f526e6556786a94d335e38b71
Author: Johannes Berg 
Date:   Thu Sep 15 11:46:52 2011 -0700

    iwlagn: do not use interruptible waits

    Since the dawn of its time, iwlwifi has used
    interruptible waits to wait for synchronous
    commands and firmware loading.

    This leads to "interesting" bugs, because it
    can't actually handle the interruptions; for
    example when a command sending is interrupted
    it will assume the command completed fully,
    and then leave it pending, which leads to all
    kinds of trouble when the command finishes
    later.

    Since there's no easy way to gracefully deal
    with interruptions, fix the driver to not use
    interruptible waits.

    This at least fixes the error
    iwlagn 0000:02:00.0: Error: Response NULL in  'REPLY_SCAN_ABORT_CMD'

    I have seen in P2P testing, but it is likely
    that there are other errors caused by this.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlegacy: fix command queue timeout

2011-10-03T18:41:11+00:00

commit 2e2a41d6ca07d1b2aa67015c35fd80701c98e867 upstream.

iwlegacy version of fix:

commit 282cdb325aea4ebbc42ce753b47cc96145eb54bc
Author: Johannes Berg 
Date:   Mon Sep 12 12:09:10 2011 -0700

    iwlagn: fix command queue timeout

    If the command queue is constantly busy,
    which can happen in P2P, the hangcheck
    timer will frequently find a command in
    it and will eventually reset the device
    because nothing sets the timestamp for
    this queue when commands are processed.

    Fix this by setting the timestamp when
    a command completes.

iwlegacy does not support P2P, but this patch fix possible
unneeded hardware resets, hence is needed.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlegacy: fix BUG_ON(info->control.rates[0].idx < 0)

2011-10-03T18:40:24+00:00

commit 7c2510120e9b43b0caf32c3786a6ab831f7d9e87 upstream.

When trying to connect to 5GHz we can provide negative index to
mac80211 what trigger BUG_ON. Reason of iwl-3945-rs malfunction
on 5GHz is unknown and needs further investigation. For now, to
do not trigger a bug, correct value and just print WARNING.

Address bug:
https://bugzilla.redhat.com/show_bug.cgi?id=730653

Reported-and-tested-by: Jan Teichmann 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlegacy: set tx power after rxon_assoc

2011-08-16T01:31:33+00:00

commit 17e859a899712d16c3e70b045d61ad9e02c53f8a upstream.

If settings of tx power was deferred during scan or changing channel we
have to setup them during commit rxon. Fix problem on 3945 (4965 already
has this fix).

Optimize code to apply tx settings only when tx power was actually
changed.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlegacy: fix channel switch locking

2011-06-08T18:19:05+00:00

We use priv->mutex to avoid race conditions between chswitch_done()
and mac_channel_switch(), when marking channel switch in
progress. But chswitch_done() can be called in atomic context
from rx_csa() or with mutex already taken from commit_rxon().

To fix remove mutex from chswitch_done() and use atomic bitops
for marking channel switch pending.

Cc: stable@kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville

iwl4965: set tx power after rxon_assoc

2011-06-06T19:24:18+00:00

Setting tx power can be deferred during scan or changing channel.
If after that correct tx power settings will not be sent to device,
we can observe transmission problems and timeouts. Force to send
tx power settings also after partial rxon change, to assure device
always be configured with up-to-date settings.

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=36492

Cc: stable@kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville

iwl4965: correctly validate temperature value

2011-06-01T18:41:13+00:00

In some cases we can read wrong temperature value. If after that
temperature value will not be updated to good one, we badly configure
tx power parameters and device is unable to send a data.

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=35932

Cc: stable@kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville

Merge git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem

2011-05-27T19:18:35+00:00