1. 29 9月, 2012 36 次提交
  2. 28 9月, 2012 1 次提交
  3. 27 9月, 2012 3 次提交
    • E
      wlcore: protect wlcore_op_set_key with mutex · af390f4d
      Eliad Peller 提交于
      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: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NLuciano Coelho <luca@coelho.fi>
      af390f4d
    • E
      wlcore: decrease elp timeout · ab2c4f37
      Eliad Peller 提交于
      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: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NLuciano Coelho <luca@coelho.fi>
      ab2c4f37
    • I
      wlcore: Load the NVS file asynchronously · 6f8d6b20
      Ido Yariv 提交于
      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: NIdo Yariv <ido@wizery.com>
      Signed-off-by: NLuciano Coelho <luca@coelho.fi>
      6f8d6b20