1. 14 6月, 2016 1 次提交
  2. 10 6月, 2016 1 次提交
    • R
      brcmfmac: rework function picking free BSS index · d02fb8f1
      Rafał Miłecki 提交于
      The old implementation was overcomplicated and slightly bugged in some
      corner cases.
      
      Consider following state of BSS-es (limited to 6 for simplification):
      drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, }
      drvr->iflist[1]:  (null)
      drvr->iflist[2]: { bsscfgidx:2, ndev->name:wlan1-1, }
      drvr->iflist[3]: { bsscfgidx:3, ndev->name:wlan1-2, }
      drvr->iflist[4]:  (null)
      drvr->iflist[5]:  (null)
      In such case the next AP interface should bsscfgidx 4 (we don't use 1 as
      it's reserved for P2P).
      
      With old code the loop iterations were following:
      [ifidx = 0] [bsscfgidx = 2] [highest = 2]
      [ifidx = 1] [bsscfgidx = 2] [highest = 2] available = true
      [ifidx = 2] [bsscfgidx = 2] [highest = 2] bsscfgidx = highest + 1
      [ifidx = 3] [bsscfgidx = 3] [highest = 2] bsscfgidx = highest + 1
      [ifidx = 4] [bsscfgidx = 3] [highest = 2] available = true
      [ifidx = 5] [bsscfgidx = 3] [highest = 2] available = true
      There were 2 obvious problems:
      1) Having empty BSS at index 1 was resulting in available being always
         set to true, even if we would run out of BSS-es.
      2) Calculated bsscfgidx was invalid (3 instead of 4) resulting in driver
         not being able to create the 4th AP interface.
      
      New code is simpler, placed in file where it's really used, handles
      running out of free BSS-es and allows using 4 interfaces at the same
      time. It also looks for the first free BSS instead of one after the last
      in use. It works well with current driver (which doesn't allow deleting
      interfaces) and should be future proof (if we ever allow deleting).
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      d02fb8f1
  3. 04 6月, 2016 2 次提交
    • C
      brcmfmac: Fix 'did not remove int handler' warning · b7467401
      Christian Daudt 提交于
      brcmf_sdiod_intr_unregister call that removes both func1 and
      func2 interrupt handlers only called when brcmf_ops_sdio_remove
      is called for func 1 (which is the 2nd call) but sdio is expecting
      it to be removed at the end of each sdio_remove call.
      This is causing 'rmmod bcmrfmac' on a 4356-sdio chip to complain
      with:
      WARNING: driver brcmfmac did not remove its interrupt handler!
      
      The modification makes calling brcmf_sdiod_intr_unregister multiple
      times harmless by clearing the variables that track if interrupt
      handlers have been installed, and then calls it on every
      brcmf_ops_sdio_remove call instead of just remove for func 1.
      Signed-off-by: NChristian Daudt <csd@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      b7467401
    • C
      brcmfmac: Fix kernel oops in failed chip_attach · b88a2e80
      Christian Daudt 提交于
      When chip attach fails, brcmf_sdiod_intr_unregister is being called
      but that is too early as sdiodev->settings has not been set yet
      nor has brcmf_sdiod_intr_register been called.
      Change to use oob_irq_requested + newly created sd_irq_requested
      to decide on what to unregister at intr_unregister time.
      
      Steps to reproduce problem:
      - modprobe brcmfmac using buggy FW
      - rmmod brcmfmac
      - modprobe brcmfmac again.
      
      If done with a buggy firmware, brcm_chip_attach will fail on the
      2nd modprobe triggering the call to intr_unregister and the
      kernel oops when attempting to de-reference sdiodev->settings->bus.sdio
      which has not yet been set.
      Signed-off-by: NChristian Daudt <csd@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      b88a2e80
  4. 12 5月, 2016 1 次提交
  5. 04 5月, 2016 1 次提交
  6. 26 4月, 2016 3 次提交
  7. 14 4月, 2016 8 次提交
  8. 12 4月, 2016 1 次提交
  9. 08 4月, 2016 1 次提交
  10. 07 4月, 2016 2 次提交
  11. 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
  12. 07 3月, 2016 18 次提交