1. 04 2月, 2011 2 次提交
    • I
      r8169: use RxFIFO overflow workaround for 8168c chipset. · b5ba6d12
      Ivan Vecera 提交于
      I found that one of the 8168c chipsets (concretely XID 1c4000c0) starts
      generating RxFIFO overflow errors. The result is an infinite loop in
      interrupt handler as the RxFIFOOver is handled only for ...MAC_VER_11.
      With the workaround everything goes fine.
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Hayes <hayeswang@realtek.com>
      b5ba6d12
    • D
      niu: Fix races between up/down and get_stats. · 9690c636
      David S. Miller 提交于
      As reported by Flavio Leitner, there is no synchronization to protect
      NIU's get_stats method from seeing a NULL pointer in either
      np->rx_rings or np->tx_rings.  In fact, as far as ->ndo_get_stats
      is concerned, these values are set completely asynchronously.
      
      Flavio attempted to fix this using a RW semaphore, which in fact
      works most of the time.  However, dev_get_stats() can be invoked
      from non-sleepable contexts in some cases, so this fix doesn't
      work in all cases.
      
      So instead, control the visibility of the np->{rx,tx}_ring pointers
      when the device is being brough up, and use properties of the device
      down sequence to our advantage.
      
      In niu_get_stats(), return immediately if netif_running() is false.
      The device shutdown sequence first marks the device as not running (by
      clearing the __LINK_STATE_START bit), then it performans a
      synchronize_rcu() (in dev_deactive_many()), and then finally it
      invokes the driver ->ndo_stop() method.
      
      This guarentees that all invocations of niu_get_stats() either see
      netif_running() as false, or they see the channel pointers before
      ->ndo_stop() clears them out.
      
      If netif_running() is true, protect against startup races by loading
      the np->{rx,tx}_rings pointer into a local variable, and punting if
      it is NULL.  Use ACCESS_ONCE to prevent the compiler from reloading
      the pointer on us.
      
      Also, during open, control the order in which the pointers and the
      ring counts become visible globally using SMP write memory barriers.
      We make sure the np->num_{rx,tx}_rings value is stable and visible
      before np->{rx,tx}_rings is.
      
      Such visibility control is not necessary on the niu_free_channels()
      side because of the RCU sequencing that happens during device down as
      described above.  We are always guarenteed that all niu_get_stats
      calls are finished, or will see netif_running() false, by the time
      ->ndo_stop is invoked.
      Reported-by: NFlavio Leitner <fleitner@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9690c636
  2. 03 2月, 2011 7 次提交
  3. 02 2月, 2011 7 次提交
  4. 01 2月, 2011 5 次提交
  5. 31 1月, 2011 5 次提交
  6. 30 1月, 2011 1 次提交
  7. 29 1月, 2011 2 次提交
    • R
      ath9k: Fix power save usage count imbalance on deinit · c7c18060
      Rajkumar Manoharan 提交于
      While unloading the driver, the ps_usecount is incremented
      before configuring gpio registers in deinit_device.
      But it is failed to restore the ps_usecount after that.
      The problem is that the chip is forcibly moved to FULL SLEEP
      by radio_disable when mac80211 is reporting as idle
      though ps_usecount is not zero.
      
      This patch retores ps_usecount properly and ensures that
      the chip is always moved to full sleep only if ps usage
      count is zero which also helps in debugging deadbeef on
      multivif case. And also fixes the following warning.
      
      ath: DMA failed to stop in 10 ms AR_CR=0xdeadbeef AR_DIAG_SW=0xdeadbeef
      ath: Could not stop RX, we could be confusing the DMA engine when we
      start RX up
      ------------[ cut here ]------------
      WARNING: at drivers/net/wireless/ath/ath9k/recv.c:536
      ath_stoprecv+0xf4/0x100 [ath9k]()
      
      Cc: stable@kernel.org
      Cc: Paul Stewart <pstew@google.com>
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c7c18060
    • R
      ath9k_hw: Fix system hang when resuming from S3/S4 · 5b64aa72
      Rajkumar Manoharan 提交于
      The bit 6 & 7 of AR_WA (0x4004) should be enabled only
      for the chips that are supporting L0s functionality
      while resuming back from S3/S4.
      
      Enabling these bits for AR9280 is causing system hang
      within a few S3/S4-resume cycles.
      
      Cc: stable@kernel.org
      Cc: Jack Lee <jlee@atheros.com>
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5b64aa72
  8. 28 1月, 2011 7 次提交
  9. 27 1月, 2011 3 次提交
  10. 26 1月, 2011 1 次提交
新手
引导
客服 返回
顶部