1. 05 6月, 2012 1 次提交
    • A
      wlcore: fixes for connection_loss_work · 6b8bf5bc
      Arik Nemtsov 提交于
      We can't use cancel_delayed_work_sync() from functions that take the
      wl->mutex, since connection_loss_work also takes the mutex. This might
      result in a deadlock. Restructure the code so the work is synchronously
      canceled before taking the mutex.
      Avoid a bug where we would indefinitely delay the connection loss
      indication by re-queuing the connection loss work on consecutive beacon
      loss events.
      
      Cc: bartosz.markowski <bartosz.markowski@tieto.com>
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NLuciano Coelho <coelho@ti.com>
      6b8bf5bc
  2. 16 5月, 2012 1 次提交
  3. 12 4月, 2012 6 次提交
  4. 10 4月, 2012 2 次提交
  5. 15 2月, 2012 3 次提交
  6. 21 12月, 2011 1 次提交
    • E
      wl12xx: mark no sched scan only after FW event · ee91d185
      Eyal Shapira 提交于
      stop sched scan isn't an immediate operation
      and we need to wait for PERIODIC_SCAN_COMPLETE_EVENT_ID
      after sending a stop before changing internal state
      and notifying upper layers.
      Not doing this caused problems when canceling an existing sched
      scan and immediately requesting to start a new one
      with a different configuration as the FW was still
      in the middle of the previous sched scan.
      Signed-off-by: NEyal Shapira <eyal@wizery.com>
      Signed-off-by: NLuciano Coelho <coelho@ti.com>
      ee91d185
  7. 08 11月, 2011 1 次提交
  8. 11 10月, 2011 8 次提交
  9. 07 10月, 2011 12 次提交
  10. 23 9月, 2011 1 次提交
  11. 14 9月, 2011 1 次提交
  12. 22 8月, 2011 2 次提交
  13. 06 7月, 2011 1 次提交