1. 14 4月, 2016 5 次提交
  2. 12 4月, 2016 1 次提交
  3. 08 4月, 2016 1 次提交
  4. 07 4月, 2016 2 次提交
  5. 10 3月, 2016 1 次提交
    • H
      brcmfmac: Remove waitqueue_active check · 107b8713
      Hui Wang 提交于
      We met a problem of pm_suspend  when repeated closing/opening the lid
      on a Lenovo laptop (1/20 reproduce rate), below is the log:
      
      [ 199.735876] PM: Entering mem sleep
      [ 199.750516] e1000e: EEE TX LPI TIMER: 00000011
      [ 199.856638] Trying to free nonexistent resource <000000000000d000-000000000000d0ff>
      [ 201.753566] brcmfmac: brcmf_pcie_suspend: Timeout on response for entering D3 substate
      [ 201.753581] pci_legacy_suspend(): brcmf_pcie_suspend+0x0/0x1f0 [brcmfmac] returns -5
      [ 201.753585] dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -5
      [ 201.753589] PM: Device 0000:04:00.0 failed to suspend async: error -5
      
      Through debugging, we found when problem happens, it is not the device
      fails to enter D3, but the signal D3_ACK comes too early to pass the
      waitqueue_active() check.
      
      Just like this:
      brcmf_pcie_send_mb_data(devinfo, BRCMF_H2D_HOST_D3_INFORM);
      // signal is triggered here
      wait_event_timeout(devinfo->mbdata_resp_wait, devinfo->mbdata_completed,
      		   BRCMF_PCIE_MBDATA_TIMEOUT);
      
      So far I think it is safe to remove waitqueue_active check since there
      is only one place to trigger this signal (sending
      BRCMF_H2D_HOST_D3_INFORM). And it is not a problem calling wake_up
      event earlier than calling wait_event.
      
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Hante Meuleman <meuleman@broadcom.com>
      Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
      Cc: Pieter-Paul Giesberts <pieterpg@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      107b8713
  6. 07 3月, 2016 20 次提交
  7. 25 2月, 2016 1 次提交
    • H
      brcmfmac: Increase nr of supported flowrings. · 19c8f421
      Hante Meuleman 提交于
      New generation devices have firmware which has more than 256 flowrings.
      E.g. following debugging message comes from 14e4:4365 BCM4366:
      [  194.606245] brcmfmac: brcmf_pcie_init_ringbuffers Nr of flowrings is 264
      
      At various code places (related to flowrings) we were using u8 which
      could lead to storing wrong number or infinite loops when indexing with
      this type. This issue was quite easy to spot in brcmf_flowring_detach
      where it led to infinite loop e.g. on failed initialization.
      
      This patch switches code to proper types and increases the maximum
      number of supported flowrings to 512.
      
      Originally this change was sent in September 2015, but back it was
      causing a regression on BCM43602 resulting in:
      Unable to handle kernel NULL pointer dereference at virtual address ...
      
      The reason for this regression was missing update (s/u8/u16) of struct
      brcmf_flowring_ring. This problem was handled in 9f64df94 ("brcmfmac: Fix
      bug in flowring management."). Starting with that it's safe to apply
      this original patch as it doesn't cause a regression anymore.
      
      This patch fixes an infinite loop on BCM4366 which is supported since
      4.4 so it makes sense to apply it to stable 4.4+.
      
      Cc: <stable@vger.kernel.org> # 4.4+
      Reviewed-by: NArend Van Spriel <arend@broadcom.com>
      Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
      Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
      Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
      Signed-off-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      19c8f421
  8. 06 2月, 2016 8 次提交
  9. 20 1月, 2016 1 次提交