1. 20 1月, 2017 5 次提交
  2. 19 1月, 2017 1 次提交
  3. 17 1月, 2017 3 次提交
    • R
      brcmfmac: setup wiphy bands after registering it first · ab99063f
      Rafał Miłecki 提交于
      During bands setup we disable all channels that firmware doesn't support
      in the current regulatory setup. If we do this before wiphy_register
      it will result in copying set flags (including IEEE80211_CHAN_DISABLED)
      to the orig_flags which is supposed to be persistent. We don't want this
      as regulatory change may result in enabling some channels. We shouldn't
      mess with orig_flags then (by changing them or ignoring them) so it's
      better to just take care of their proper values.
      
      This patch cleanups code a bit (by taking orig_flags more seriously) and
      allows further improvements like disabling really unavailable channels.
      We will need that e.g. if some frequencies should be disabled for good
      due to hardware setup (design).
      Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
      Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      ab99063f
    • R
      brcmfmac: don't preset all channels as disabled · 9ea0c307
      Rafał Miłecki 提交于
      During init we take care of regulatory stuff by disabling all
      unavailable channels (see brcmf_construct_chaninfo) so this predisabling
      them is not really required (and this patch won't change any behavior).
      It will on the other hand allow more detailed runtime control over
      channels which is the main reason for this change.
      Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      9ea0c307
    • R
      brcmfmac: avoid writing channel out of allocated array · 77c0d0cd
      Rafał Miłecki 提交于
      Our code was assigning number of channels to the index variable by
      default. If firmware reported channel we didn't predict this would
      result in using that initial index value and writing out of array. This
      never happened so far (we got a complete list of supported channels) but
      it means possible memory corruption so we should handle it anyway.
      
      This patch simply detects unexpected channel and ignores it.
      
      As we don't try to create new entry now, it's also safe to drop hw_value
      and center_freq assignment. For known channels we have these set anyway.
      
      I decided to fix this issue by assigning NULL or a target channel to the
      channel variable. This was one of possible ways, I prefefred this one as
      it also avoids using channel[index] over and over.
      
      Fixes: 58de92d2 ("brcmfmac: use static superset of channels for wiphy bands")
      Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
      Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      77c0d0cd
  4. 30 12月, 2016 1 次提交
  5. 20 12月, 2016 2 次提交
  6. 16 12月, 2016 1 次提交
  7. 29 11月, 2016 12 次提交
  8. 25 11月, 2016 1 次提交
    • T
      brcmsmac: fix array out-of-bounds access in qm_log10 · 4c0bfeaa
      Tobias Regnery 提交于
      I get the following UBSAN warning during boot on my laptop:
      
      ================================================================================
      UBSAN: Undefined behaviour in drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c:280:21
      index 32 is out of range for type 's16 [32]'
      CPU: 0 PID: 879 Comm: NetworkManager Not tainted 4.9.0-rc4 #28
      Hardware name: LENOVO Lenovo IdeaPad N581/INVALID, BIOS 5ECN96WW(V9.01) 03/14/2013
      ffff8800b74a6478 ffffffff828e59d2 0000000041b58ab3 ffffffff8398330c
      ffffffff828e5920 ffff8800b74a64a0 ffff8800b74a6450 0000000000000020
      1ffffffff845848c ffffed0016e94bf1 ffffffffc22c2460 000000006b9c0514
      Call Trace:
      [<ffffffff828e59d2>] dump_stack+0xb2/0x110
      [<ffffffff828e5920>] ? _atomic_dec_and_lock+0x150/0x150
      [<ffffffff82968c9d>] ubsan_epilogue+0xd/0x4e
      [<ffffffff82969875>] __ubsan_handle_out_of_bounds+0xfa/0x13e
      [<ffffffff8296977b>] ? __ubsan_handle_shift_out_of_bounds+0x241/0x241
      [<ffffffffc0d48379>] ? bcma_host_pci_read16+0x59/0xa0 [bcma]
      [<ffffffffc0d48388>] ? bcma_host_pci_read16+0x68/0xa0 [bcma]
      [<ffffffffc212ad78>] ? read_phy_reg+0xe8/0x180 [brcmsmac]
      [<ffffffffc2184714>] qm_log10+0x2e4/0x350 [brcmsmac]
      [<ffffffffc2142eb8>] wlc_phy_init_lcnphy+0x538/0x1f20 [brcmsmac]
      [<ffffffffc2142980>] ? wlc_lcnphy_periodic_cal+0x5c0/0x5c0 [brcmsmac]
      [<ffffffffc1ba0c93>] ? ieee80211_open+0xb3/0x110 [mac80211]
      [<ffffffff82f73a02>] ? sk_busy_loop+0x1e2/0x840
      [<ffffffff82f7a6ce>] ? __dev_change_flags+0xae/0x220
      ...
      
      The report is valid: doing the math in this function, with an input value
      N=63 the variable s16tableIndex gets a value of 31. This value is used as
      an index in the array log_table with 32 entries. But the next line is:
      
      	s16errorApproximation = (s16) qm_mulu16(u16offset,
      				(u16) (log_table[s16tableIndex + 1] -
      				       log_table[s16tableIndex]));
      
      With s16tableIndex + 1 we are trying an out-of-bounds access to the array.
      
      The log_table array provides log2 values in q.15 format and the above
      statement tries an error approximation with the next value. To fix this
      issue add the next value to the array and update the comment accordingly.
      Signed-off-by: NTobias Regnery <tobias.regnery@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      4c0bfeaa
  9. 23 11月, 2016 1 次提交
  10. 17 11月, 2016 1 次提交
  11. 09 11月, 2016 1 次提交
    • R
      brcmfmac: proto: add callback for queuing TX data · b073ac1f
      Rafał Miłecki 提交于
      So far our core code was calling brcmf_fws_process_skb which wasn't
      a proper thing to do. If case of devices using msgbuf protocol fwsignal
      shouldn't be used. It was an unnecessary extra layer simply calling
      a protocol specifix txdata function.
      
      Please note we already have txdata callback, but it's used for calls
      between bcdc and fwsignal so it couldn't be simply used there.
      
      This makes core code more generic (instead of bcdc/fwsignal specific).
      Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      b073ac1f
  12. 27 10月, 2016 2 次提交
    • A
      brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap · d3532ea6
      Arnd Bergmann 提交于
      A bugfix added a sanity check around the assignment and use of the
      'is_11d' variable, which looks correct to me, but as the function is
      rather complex already, this confuses the compiler to the point where
      it can no longer figure out if the variable is always initialized
      correctly:
      
      brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
      brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      This adds an initialization for the newly introduced case in which
      the variable should not really be used, in order to make the warning
      go away.
      
      Fixes: b3589dfe ("brcmfmac: ignore 11d configuration errors")
      Cc: Hante Meuleman <hante.meuleman@broadcom.com>
      Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      d3532ea6
    • J
      wireless: deprecate WDS and disable by default · 8f205423
      Johannes Berg 提交于
      The old WDS 4-addr frame support is very limited, e.g.
       * no encryption is possible on such links
       * it cannot support rate/HT/VHT negotiation
       * management APIs are very restricted
      
      These make the WDS legacy mode useless in practice.
      
      All of these are resolved by the 4-addr AP/client support,
      so there's also no reason to improve WDS in the future.
      
      Therefore, add a Kconfig option to disable legacy WDS.
      This gives people an "emergency valve" while they migrate
      to the better-supported 4-addr AP/client option; we plan
      to remove it (and the associated cfg80211/mac80211 code,
      which is the ultimate goal) in the future.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8f205423
  13. 13 10月, 2016 1 次提交
  14. 27 9月, 2016 8 次提交