linux-toradex.git/drivers/net/wireless/ti, branch v3.7.2 Linux kernel for Apalis and Colibri modules wlcore: protect wlcore_op_set_key with mutex 2012-09-27T09:13:54+00:00 Eliad Peller eliad@wizery.com 2012-09-03T15:27:58+00:00 af390f4dd35373b3ca32bafc12d7f2ad12840529 wlcore_op_set_key() calls wl18xx_set_key(), which in turn executes some of his function calls without acquiring wl->mutex and making sure the fw is awake. Adding mutex_lock()/ps_elp_wakeup() calls is not enough, as wl18xx_set_key() calls wl1271_tx_flush() which can't be called while the mutex is taken. Add the required calls to wlcore_op_set_key, but limit the queues_stop and flushing to the only encryption types in which a spare block might be needed (GEM and TKIP). [Arik - move state != ON check] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Luciano Coelho <luca@coelho.fi> 
wlcore_op_set_key() calls wl18xx_set_key(),
which in turn executes some of his function
calls without acquiring wl->mutex and making
sure the fw is awake.

Adding mutex_lock()/ps_elp_wakeup() calls is
not enough, as wl18xx_set_key() calls
wl1271_tx_flush() which can't be called while
the mutex is taken.

Add the required calls to wlcore_op_set_key,
but limit the queues_stop and flushing
to the only encryption types in which
a spare block might be needed (GEM and TKIP).

[Arik - move state != ON check]

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>
wlcore: decrease elp timeout 2012-09-27T09:13:54+00:00 Eliad Peller eliad@wizery.com 2012-09-02T10:30:04+00:00 ab2c4f37dcef5bd517a95a32da50d5ed0cc24cb5 The current elp timeout (the same as the dynamic ps timeout - 1500ms) is too high. Usually, wl1271_ps_elp_sleep() get called right after tx/rx, which is fine, but some command might get sent even when there is no traffic (e.g. ht changes triggered by beacon frames), and leaving the device awake for 1500ms in this case is redundant. Use a timeout of 30ms. The fw won't enter elp anyway before the dynamic-ps timeout was expired as well (and it entered ps successfully). Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Luciano Coelho <luca@coelho.fi> 
The current elp timeout (the same as the dynamic
ps timeout - 1500ms) is too high. Usually,
wl1271_ps_elp_sleep() get called right after tx/rx,
which is fine, but some command might get sent
even when there is no traffic (e.g. ht changes
triggered by beacon frames), and leaving the
device awake for 1500ms in this case is redundant.

Use a timeout of 30ms.
The fw won't enter elp anyway before the dynamic-ps
timeout was expired as well (and it entered ps
successfully).

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>
wlcore: Load the NVS file asynchronously 2012-09-27T09:13:54+00:00 Ido Yariv ido@wizery.com 2012-09-01T22:32:47+00:00 6f8d6b20bb0bdda333e781faf775db14cb4660dd The NVS file is loaded by the device's probe callback with the help of request_firmware(). Since request_firmware() relies on udevd, the modules cannot be loaded before hotplug events are handled. Fix this by loading the NVS file asynchronously and continue initialization only after the firmware request is over. Signed-off-by: Ido Yariv <ido@wizery.com> Signed-off-by: Luciano Coelho <luca@coelho.fi> 
The NVS file is loaded by the device's probe callback with the help of
request_firmware(). Since request_firmware() relies on udevd, the
modules cannot be loaded before hotplug events are handled.

Fix this by loading the NVS file asynchronously and continue
initialization only after the firmware request is over.

Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>
wlcore: Refactor probe 2012-09-27T09:13:54+00:00 Ido Yariv ido@wizery.com 2012-09-02T09:29:27+00:00 3992eb2bf2b1f6d244cf527c922c0cbd810e69c5 Move most of the device-specific probe functionality into setup(), a new op. By doing this, wlcore_probe will be the first to request a firmware from userspace, making it easier to load the NVS file asynchronously. Signed-off-by: Ido Yariv <ido@wizery.com> Signed-off-by: Luciano Coelho <luca@coelho.fi> 
Move most of the device-specific probe functionality into setup(), a new
op. By doing this, wlcore_probe will be the first to request a firmware
from userspace, making it easier to load the NVS file asynchronously.

Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>
wlcore: Allow memory access when the FW crashes 2012-09-27T09:13:53+00:00 Ido Yariv ido@wizery.com 2012-08-21T14:17:13+00:00 d556023895c8968fd97ccb08300006b78975a23b When the no_recovery flag is used, the recovery work will not restart the FW and the state will not be set to 'on'. To enable post-mortem analysis, allow memory access in the 'restarting' state. Also, since the FW might not be operational, don't fail the read/write operations if elp_wakeup fails. Reported-by: Arkady Miasnikov <a-miasnikov@ti.com> Signed-off-by: Ido Yariv <ido@wizery.com> Signed-off-by: Luciano Coelho <luca@coelho.fi> 
When the no_recovery flag is used, the recovery work will not restart
the FW and the state will not be set to 'on'. To enable post-mortem
analysis, allow memory access in the 'restarting' state.

Also, since the FW might not be operational, don't fail the read/write
operations if elp_wakeup fails.

Reported-by: Arkady Miasnikov <a-miasnikov@ti.com>
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>
wlcore: use dynamic keep-alive template ids 2012-09-27T09:13:53+00:00 Eliad Peller eliad@wizery.com 2012-08-16T10:52:47+00:00 001e39a8effd5a9774153ca6ca67849a93b95852 Currently, all the (station) roles use the same keep-alive template id (0). However, the klv template ids shouldn't be shared by different roles. Implement a simple klv_templates bitmap, and let each role allocate its own klv template id on role initialization. [Arik - remove invalidation of KLV template when getting into "idle". This is already handled in unjoin] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Luciano Coelho <luca@coelho.fi> 
Currently, all the (station) roles use the same
keep-alive template id (0). However, the klv
template ids shouldn't be shared by different
roles.

Implement a simple klv_templates bitmap, and let
each role allocate its own klv template id on
role initialization.

[Arik - remove invalidation of KLV template when getting into "idle".
This is already handled in unjoin]

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>
wlcore: invalidate keep-alive template on disconnection 2012-09-27T09:13:53+00:00 Eliad Peller eliad@wizery.com 2012-08-16T10:32:32+00:00 4137c17c8c88eca51a9e9d53c5eea0ea3d49940e Previously, invalidation of the keep-alive template was done when going idle. However, while removing the idle-handling we didn't move the keep-alive template invalidation to another place. This finally resulted in fw error when trying to use the keep-alive template by another role. (Note that we still have an error here - each role should have its unique keep-alive template id, while currently they all use CMD_TEMPL_KLV_IDX_NULL_DATA (0). This only works now because we don't support concurrent connected stations yet) Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Luciano Coelho <luca@coelho.fi> 
Previously, invalidation of the keep-alive template was
done when going idle. However, while removing the
idle-handling we didn't move the keep-alive template
invalidation to another place.

This finally resulted in fw error when trying to use
the keep-alive template by another role.

(Note that we still have an error here - each role
should have its unique keep-alive template id, while
currently they all use CMD_TEMPL_KLV_IDX_NULL_DATA (0).
This only works now because we don't support concurrent
connected stations yet)

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>
wl18xx: default to siso40 in 2.4ghz with a single antenna 2012-09-27T09:13:53+00:00 Arik Nemtsov arik@wizery.com 2012-08-15T16:11:43+00:00 8c5dab1a8449428685414c0de494b77841571fd3 The driver used siso20 in this case for legacy reasons. Reported-by: Ido Reis <idor@ti.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Luciano Coelho <luca@coelho.fi> 
The driver used siso20 in this case for legacy reasons.

Reported-by: Ido Reis <idor@ti.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>
wlcore: Fix unbalanced interrupts enablement 2012-09-27T09:13:53+00:00 Ido Yariv ido@wizery.com 2012-08-15T15:29:04+00:00 a8311c8a9a7c41de9cc2d5e1573ff7005b4959ab The interrupt line is enabled by wl12xx_enable_interrupts and wl18xx_enable_interrupts, but it will not be disabled in all failure paths. Fix this. Signed-off-by: Ido Yariv <ido@wizery.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Luciano Coelho <luca@coelho.fi> 
The interrupt line is enabled by wl12xx_enable_interrupts and
wl18xx_enable_interrupts, but it will not be disabled in all failure
paths. Fix this.

Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>
wlcore: Don't recover during boot 2012-09-27T09:13:53+00:00 Ido Yariv ido@wizery.com 2012-08-15T12:09:30+00:00 792a58a8720f02c8f340583f6ee54c9eb46adf0b While recursive recovery is avoided during shutdown, a new recovery may be queued when the FW boots. The recovery work will then try to stop an already stopped hardware, which will most likely result in a kernel panic. Fix this by verifying that wl->state is on before queueing a new recovery. Signed-off-by: Ido Yariv <ido@wizery.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Luciano Coelho <luca@coelho.fi> 
While recursive recovery is avoided during shutdown, a new recovery may
be queued when the FW boots. The recovery work will then try to stop an
already stopped hardware, which will most likely result in a kernel
panic.

Fix this by verifying that wl->state is on before queueing a new
recovery.

Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>