1. 28 Jul, 2017 36 commits
  2. 27 Jul, 2017 4 commits
    • Cong Wang's avatar
      wl1251: add a missing spin_lock_init() · 6e9aae17
      Cong Wang authored
      This fixes the following kernel warning:
      
        [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745
        [ 5668.771850]  lock: 0xce63ef20, .magic: 00000000, .owner: <none>/-1,
        .owner_cpu: 0
        [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: G        W
        4.12.0-03002-gec979a4-dirty #40
        [ 5668.772796] Hardware name: Nokia RX-51 board
        [ 5668.773071] Workqueue: phy1 wl1251_irq_work
        [ 5668.773345] [<c010c9e4>] (unwind_backtrace) from [<c010a274>]
        (show_stack+0x10/0x14)
        [ 5668.773803] [<c010a274>] (show_stack) from [<c01545a4>]
        (do_raw_spin_lock+0x6c/0xa0)
        [ 5668.774230] [<c01545a4>] (do_raw_spin_lock) from [<c06ca578>]
        (_raw_spin_lock_irqsave+0x10/0x18)
        [ 5668.774658] [<c06ca578>] (_raw_spin_lock_irqsave) from [<c048c010>]
        (wl1251_op_tx+0x38/0x5c)
        [ 5668.775115] [<c048c010>] (wl1251_op_tx) from [<c06a12e8>]
        (ieee80211_tx_frags+0x188/0x1c0)
        [ 5668.775543] [<c06a12e8>] (ieee80211_tx_frags) from [<c06a138c>]
        (__ieee80211_tx+0x6c/0x130)
        [ 5668.775970] [<c06a138c>] (__ieee80211_tx) from [<c06a3dbc>]
        (ieee80211_tx+0xdc/0x104)
        [ 5668.776367] [<c06a3dbc>] (ieee80211_tx) from [<c06a4af0>]
        (__ieee80211_subif_start_xmit+0x454/0x8c8)
        [ 5668.776824] [<c06a4af0>] (__ieee80211_subif_start_xmit) from
        [<c06a4f94>] (ieee80211_subif_start_xmit+0x30/0x2fc)
        [ 5668.777343] [<c06a4f94>] (ieee80211_subif_start_xmit) from
        [<c0578848>] (dev_hard_start_xmit+0x80/0x118)
        ...
      
      by adding the missing spin_lock_init().
      Reported-by: default avatarPavel Machek <pavel@ucw.cz>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      6e9aae17
    • Florian Fainelli's avatar
      bcma: gpio: Correct number of GPIOs for BCM53573 · 459c3514
      Florian Fainelli authored
      Broadcom BCM53573 SoCs actually have 32 GPIOs, and not 16.
      
      Fixes: 3f37ec79 ("bcma: support BCM53573 series of wireless SoCs")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      459c3514
    • Colin Ian King's avatar
      rtlwifi: kfree entry until after entry->bssid has been accessed · d0116f6f
      Colin Ian King authored
      The current code kfree's entry and then dereferences it by accessing
      entry->bssid.  Avoid the dereference-after-free by moving the kfree
      after the access to entry->bssid.
      
      Detected by CoverityScan, CID#1448600 ("Read from pointer after free")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      d0116f6f
    • Brian Norris's avatar
      mwifiex: correct channel stat buffer overflows · 4b5dde2d
      Brian Norris authored
      mwifiex records information about various channels as it receives scan
      information. It does this by appending to a buffer that was sized
      to the max number of supported channels on any band, but there are
      numerous problems:
      
      (a) scans can return info from more than one band (e.g., both 2.4 and 5
          GHz), so the determined "max" is not large enough
      (b) some firmware appears to return multiple results for a given
          channel, so the max *really* isn't large enough
      (c) there is no bounds checking when stashing these stats, so problems
          (a) and (b) can easily lead to buffer overflows
      
      Let's patch this by setting a slightly-more-correct max (that accounts
      for a combination of both 2.4G and 5G bands) and adding a bounds check
      when writing to our statistics buffer.
      
      Due to problem (b), we still might not properly report all known survey
      information (e.g., with "iw <dev> survey dump"), since duplicate results
      (or otherwise "larger than expected" results) will cause some
      truncation. But that's a problem for a future bugfix.
      
      (And because of this known deficiency, only log the excess at the WARN
      level, since that isn't visible by default in this driver and would
      otherwise be a bit too noisy.)
      
      Fixes: bf354433 ("mwifiex: channel statistics support for mwifiex")
      Cc: <stable@vger.kernel.org>
      Cc: Avinash Patil <patila@marvell.com>
      Cc: Xinming Hu <huxm@marvell.com>
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Reviewed-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Reviewed-by: default avatarGanapathi Bhat <gbhat@marvell.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      4b5dde2d