1. 04 10月, 2011 1 次提交
    • D
      libertas: detect TX lockups and reset hardware · 8f641d93
      Daniel Drake 提交于
      Recent patches added support for resetting the SD8686 hardware when
      commands time out, which seems to happen quite frequently soon after
      resuming the system from a Wake-on-WLAN-triggered resume.
      
      At http://dev.laptop.org/ticket/10969 we see the same thing happen
      with transmits. In this case, the hardware will fail to respond to
      a frame passed for transmission, and libertas (correctly) will block
      all further commands and transmissions as the hardware can only
      deal with one thing at a time. This results in a lockup while the
      system waits indefinitely for the dead card to respond.
      
      Hook up a TX lockup timer to detect this and reset the hardware.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8f641d93
  2. 28 9月, 2011 1 次提交
    • D
      libertas: scan behaviour consistency improvements · b4c3f34a
      Daniel Drake 提交于
      When scanning for the broadcast SSID, there is no need to add the
      SSID TLV (restoring the behaviour of the driver behaviour in the wext
      days, confirmed in Marvell specifications).
      
      If bssid is unspecified, the current scan code will usually fire off an
      active scan probing for the specific requested SSID. However, if a scan
      is ongoing (or has just finished), those scan results will be used
      instead (even if that scan is totally different, e.g. a passive scan on
      channel 4 for a different SSID). Fix this inconsistency by always
      firing off a scan when associating without a bssid.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Acked-by: NDan Williams <dcbw@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b4c3f34a
  3. 15 9月, 2011 1 次提交
  4. 25 8月, 2011 2 次提交
  5. 18 8月, 2011 1 次提交
  6. 10 8月, 2011 3 次提交
  7. 09 8月, 2011 3 次提交
  8. 21 7月, 2011 2 次提交
  9. 12 7月, 2011 2 次提交
    • D
      libertas: fix handling of command timeout, completion and interruption · df90d843
      Daniel Drake 提交于
      When commands time out, corruption ensues. As lbs_complete_command()
      is called without locking, the command node is mistakenly freed twice.
      Also fixed up locking here in a few other places.
      
      The nature of command timeout may be that the card didn't even
      acknowledge receipt of the request. Detect this case and reset dnld_sent
      so that other commands don't hang forever.
      
      When cmdnodes are moved between the free list and the pending list,
      their list heads should be reinitialized. Fixed this.
      
      Sometimes commands are completed without actually submitting them or
      removing them from cmdpendingq. We must remember to remove them from
      cmdpendingq in these cases, so handle this in lbs_complete_command().
      
      Harmless signals generated during suspend/resume were interrupting
      lbs_cmd. Convert to an uninterruptible sleep to avoid this.
      
      lbs_thread must be woken up every time there is some new work to do.
      I found that when 2 commands are queued, ther completion of the first
      command would not wake up lbs_thread to submit the second. Poke lbs_thread
      at the end of lbs_complete_command() to fix this.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      df90d843
    • O
      libertas: fix errors in functions accessing module registers · edcc3604
      Olivier Sobrie 提交于
      Problems located in the two functions lbs_set_reg() and lbs_get_reg():
      - The offset field of struct cmd_ds_reg_access was not filled in
      - The test on the return code of lbs_cmd_with_response() in function
        lbs_get_reg() was inverted
      Signed-off-by: NOlivier Sobrie <olivier@sobrie.be>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      edcc3604
  10. 18 6月, 2011 1 次提交
  11. 11 6月, 2011 1 次提交
  12. 07 6月, 2011 1 次提交
  13. 04 6月, 2011 1 次提交
    • D
      libertas_sdio: handle spurious interrupts · d2ac49fe
      Daniel Drake 提交于
      Commit 06e8935f adds an IRQ handling
      optimization for single-function SDIO cards like this one, but at the
      same time exposes a small hardware bug.
      
      During hardware init, an interrupt is generated with (apparently) no
      source. Previously, mmc threw this interrupt away, but now (due to the
      optimization), the mmc layer passes this onto libertas, before it is ready
      (and before it has enabled interrupts), causing a crash.
      
      Work around this hardware bug by registering the IRQ handler later and
      making it capable of handling interrupts with no cause. The change that
      makes the IRQ handler registration happen later actually eliminates
      the spurious interrupt as well.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d2ac49fe
  14. 01 6月, 2011 1 次提交
  15. 12 5月, 2011 3 次提交
  16. 11 5月, 2011 1 次提交
  17. 06 5月, 2011 2 次提交
    • J
      pcmcia: Convert pcmcia_device_id declarations to const · 25f8f54f
      Joe Perches 提交于
      Saves about 50KB of data.
      
      Old/new size of all objects:
         text	   data	    bss	    dec	    hex	filename
       563015	  80096	 130684	 773795	  bcea3	(TOTALS)
       610916	  32256	 130632	 773804	  bceac	(TOTALS)
      Signed-off-by: NJoe Perches <joe@perches.com>
      Acked-by: Kurt Van Dijck <kurt.van.dijck@eia.be> (for drivers/net/can/softing/softing_cs.c)
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      25f8f54f
    • D
      libertas: remove tx_timeout handler · 7e4b4eec
      Daniel Drake 提交于
      As described at http://marc.info/?l=linux-netdev&m=130428493104730&w=2
      libertas frequently generates spurious tx timeouts, because the tx
      queue is brought down for extended periods during scanning. The net
      layer takes a look and incorrectly assumes the queue has been down for
      several seconds, and generates a tx_timeout.
      
      One way to fix this is to bump the trans_start counter while scanning
      so that the network layer knows that the device is still alive, but
      I think the tx_timeout handler is implemented wrongly here and not of
      any real use, so I vote to remove it.
      
      As explained at http://marc.info/?l=linux-wireless&m=130430311115755&w=2
      the watchdog is primarily meant to deal with lockup on the hardware TX
      path (detected by the tx queue being stopped for an extended period of
      time), but this is unlikely to happen with libertas. In this case, the tx
      queue is stopped only while waiting for lbs_thread to send the queued frame
      to the driver, and lbs_thread wakes up the queue immediately after, even
      if the frame could not be sent correctly.
      
      So, the only hardware-related possibility that this catches is if
      hw_host_to_card hangs - this is something I have never seen. And if it
      were to happen, nothing done by lbs_tx_timeout would actually wake up
      lbs_thread any quicker than otherwise.
      
      Removing this oddly-behaving spuriously-firing tx_timeout handler should
      fix an occasional kernel crash during resume
      (http://dev.laptop.org/ticket/10748)
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Acked-by: NDan Williams <dcbw@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7e4b4eec
  18. 29 4月, 2011 1 次提交
  19. 31 3月, 2011 2 次提交
  20. 12 3月, 2011 1 次提交
  21. 10 3月, 2011 1 次提交
  22. 04 2月, 2011 2 次提交
  23. 22 1月, 2011 1 次提交
    • B
      cfg80211: Extend channel to frequency mapping for 802.11j · 59eb21a6
      Bruno Randolf 提交于
      Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
      IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
      channel numbers in the 2GHz and 5GHz band we can't map from channel to
      frequency without knowing the band. This is no problem as in most contexts we
      know the band. In places where we don't know the band (and WEXT compatibility)
      we assume the 2GHz band for channels below 14.
      
      This patch does not implement all channel to frequency mappings defined in
      802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
      channels as well as 802.11y channels have been omitted.
      
      The following drivers have been updated to reflect the API changes:
      iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
      The drivers have been compile-tested only.
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NBrian Prodoehl <bprodoehl@gmail.com>
      Acked-by: NLuciano Coelho <coelho@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      59eb21a6
  24. 05 1月, 2011 1 次提交
  25. 14 12月, 2010 2 次提交
  26. 30 11月, 2010 2 次提交