1. 08 May, 2013 5 commits
    • Bing Zhao's avatar
      mwifiex: clear is_suspended flag when interrupt is received early · 48795424
      Bing Zhao authored
      When the XO-4 with 8787 wireless is woken up due to wake-on-WLAN
      mwifiex is often flooded with "not allowed while suspended" messages
      and the interface is unusable.
      
      [  202.171609] int: sdio_ireg = 0x1
      [  202.180700] info: mwifiex_process_hs_config: auto cancelling host
                     sleep since there is interrupt from the firmware
      [  202.201880] event: wakeup device...
      [  202.211452] event: hs_deactivated
      [  202.514638] info: --- Rx: Data packet ---
      [  202.514753] data: 4294957544 BSS(0-0): Data <= kernel
      [  202.514825] PREP_CMD: device in suspended state
      [  202.514839] data: dequeuing the packet ec7248c0 ec4869c0
      [  202.514886] mwifiex_write_data_sync: not allowed while suspended
      [  202.514886] host_to_card, write iomem (1) failed: -1
      [  202.514917] mwifiex_write_data_sync: not allowed while suspended
      [  202.514936] host_to_card, write iomem (2) failed: -1
      [  202.514949] mwifiex_write_data_sync: not allowed while suspended
      [  202.514965] host_to_card, write iomem (3) failed: -1
      [  202.514976] mwifiex_write_data_async failed: 0xFFFFFFFF
      
      This can be readily reproduced when putting the XO-4 in a loop where
      it goes to sleep due to inactivity, but then wakes up due to an
      incoming ping. The error is hit within an hour or two.
      
      This issue happens when an interrupt comes in early while host sleep
      is still activated. Driver handles this case by auto cancelling host
      sleep. However is_suspended flag is still set which prevents any cmd
      or data from being sent to firmware. Fix it by clearing is_suspended
      flag in this path.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarDaniel Drake <dsd@laptop.org>
      Tested-by: default avatarDaniel Drake <dsd@laptop.org>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      48795424
    • Sujith Manoharan's avatar
      ath9k: Update initvals for AR9565 · f0fb6af2
      Sujith Manoharan authored
      * Register Modification for xLNA board.
      * TX gain table modification for zero calibration.
      * AUX chain (LNA2) sensitivity enhancement
      * Modify diversity bias default setting in INI.
      Signed-off-by: default avatarSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f0fb6af2
    • Sujith Manoharan's avatar
      ath9k: Fix beacon reconfiguration · a6768280
      Sujith Manoharan authored
      When a reset or a channel-change happens, for managed mode,
      the HW beacon timers have to be programmed after the TSF has
      been synchronized. This is handled via the sync flags.
      Signed-off-by: default avatarSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a6768280
    • Stanislaw Gruszka's avatar
      iwl4965: workaround connection regression on passive channel · dd9c4640
      Stanislaw Gruszka authored
      Jake reported that since commit 1672c0e3
      "mac80211: start auth/assoc timeout on frame status", he is unable to
      connect to his AP, which is configured to use passive channel.
      
      After switch to passive channel 4965 firmware drops any TX packet until
      it receives beacon. Before commit 1672c0e3 we waited on channel and
      retransmit packet after 200ms, that makes we receive beacon on the
      meantime and association process succeed. New mac80211 behaviour cause
      that any ASSOC frame fail immediately on iwl4965 and we can not
      associate.
      
      This patch restore old mac80211 behaviour for iwl4965, by removing
      IEEE80211_HW_REPORTS_TX_ACK_STATUS feature. This feature will be
      added again to iwl4965 driver, when different, more complex
      workaround for this firmware issue, will be added to the driver.
      
      Cc: stable@vger.kernel.org # 3.9
      Bisected-by: default avatarJake Edge <jake@lwn.net>
      Reported-and-tested-by: default avatarJake Edge <jake@lwn.net>
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      dd9c4640
    • Thommy Jakobsson's avatar
      B43: Handle DMA RX descriptor underrun · 73b82bf0
      Thommy Jakobsson authored
      Add handling of rx descriptor underflow. This fixes a fault that could
      happen on slow machines, where data is received faster than the CPU can
      handle. In such a case the device will use up all rx descriptors and
      refuse to send any more data before confirming that it is ok. This
      patch enables necessary interrupt to discover such a situation and will
      handle them by dropping everything in the ring buffer.
      Reviewed-by: default avatarMichael Buesch <m@bues.ch>
      Signed-off-by: default avatarThommy Jakobsson <thommyj@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      73b82bf0
  2. 03 May, 2013 2 commits
  3. 29 Apr, 2013 1 commit
    • John W. Linville's avatar
      Merge tag 'nfc-next-3.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next · a8a48e60
      John W. Linville authored
      Samuel Ortiz <sameo@linux.intel.com> says:
      
      "With this one we have:
      
      - One patch for moving the LLCP code into net/nfc.
        It fixes a build annoyance reported by Dave Miller caused by the fact
        that the LLCP code object targets are not in the same directory as the
        Makefile trying to build them is. It prevents us from doing e.g.
      
              make net/nfc/llcp/sock.o
      
        Moving the LLCP code into net/nfc and not making it optional anymore
        makes sense as LLCP is a fundamental piece of the NFC specifications
        and thus should be in the core NFC directory.
      
      - One patch that fixes the missing dependency against RFKILL. Without it NFC
        fails to properly build when it's builtin and CONFIG_RFKILL=m."
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a8a48e60
  4. 26 Apr, 2013 11 commits
  5. 23 Apr, 2013 21 commits