1. 30 5月, 2014 8 次提交
  2. 20 5月, 2014 1 次提交
  3. 19 5月, 2014 1 次提交
  4. 14 5月, 2014 14 次提交
  5. 13 5月, 2014 1 次提交
  6. 25 4月, 2014 1 次提交
    • H
      brcmfmac: Fix brcmf_chip_ai_coredisable not applying reset bits to BCMA_IOCTL · ffa216bb
      Hans de Goede 提交于
      brcmfmac has been broken on my cubietruck with a BCM43362:
      
      brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1
      brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
              Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
      
      since commit 53036261: "brcmfmac: update core reset and disable routines".
      
      The problem is that since this commit brcmf_chip_ai_resetcore no longer sets
      BCMA_IOCTL itself before bringing the core out of reset, instead relying on
      brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop
      of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable
      to always set BCMA_IOCTL even if the core is already in reset.
      
      This fixes brcmfmac hanging in firmware loading on my board.
      
      Cc: stable@vger.kernel.org # v3.14
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ffa216bb
  7. 09 4月, 2014 1 次提交
  8. 28 3月, 2014 1 次提交
  9. 20 3月, 2014 4 次提交
  10. 18 3月, 2014 5 次提交
  11. 15 3月, 2014 3 次提交
    • J
      brcmfmac: Make probe function __init · c2d23c70
      Jean Delvare 提交于
      One of the benefits of platform_driver_probe() is that you can make
      the probe function __init.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Cc: Hante Meuleman <meuleman@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: John W. Linville <linville@tuxdriver.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c2d23c70
    • E
      brcmsmac: update comment to reflect the code · c9423937
      Emil Goode 提交于
      The brcms_attach function is defined as static but the comment is
      saying that it should not be static or gcc will issue a warning.
      I believe we can remove the comment as I don't se a problem with
      this function being defined as static.
      Signed-off-by: NEmil Goode <emilgoode@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c9423937
    • E
      brcmsmac: fix deadlock on missing firmware · 8fc1e8c2
      Emil Goode 提交于
      When brcm80211 firmware is not installed networking hangs.
      A deadlock happens because we call ieee80211_unregister_hw()
      from the .start callback of struct ieee80211_ops. When .start
      is called we are under rtnl lock and ieee80211_unregister_hw()
      tries to take it again.
      
      Function call stack:
      
      dev_change_flags()
      	__dev_change_flags()
      		__dev_open()
      			ASSERT_RTNL() <-- Assert rtnl lock
      			ops->ndo_open()
      
      .ndo_open = ieee80211_open,
      
      ieee80211_open()
      	ieee80211_do_open()
      		drv_start()
      			local->ops->start()
      
      .start = brcms_ops_start,
      
      brcms_ops_start()
      	brcms_remove()
      		ieee80211_unregister_hw()
      			rtnl_lock() <-- Here we deadlock
      
      Introduced by:
      commit 25b5632f
      ("brcmsmac: request firmware in .start() callback")
      
      This patch fixes the bug by removing the call to brcms_remove()
      and moves the brcms_request_fw() call to the top of the .start
      callback to not initiate anything unless firmware is installed.
      Signed-off-by: NEmil Goode <emilgoode@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8fc1e8c2