1. 13 4月, 2017 1 次提交
  2. 05 4月, 2017 1 次提交
  3. 21 3月, 2017 2 次提交
  4. 28 2月, 2017 1 次提交
  5. 07 2月, 2017 1 次提交
  6. 31 1月, 2017 4 次提交
  7. 20 1月, 2017 1 次提交
  8. 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
  9. 30 12月, 2016 1 次提交
  10. 20 12月, 2016 1 次提交
  11. 29 11月, 2016 9 次提交
  12. 23 11月, 2016 1 次提交
  13. 17 11月, 2016 1 次提交
  14. 27 10月, 2016 1 次提交
    • 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
  15. 13 10月, 2016 1 次提交
  16. 27 9月, 2016 4 次提交
  17. 07 9月, 2016 1 次提交
  18. 04 9月, 2016 1 次提交
    • N
      brcmfmac: fix pmksa->bssid usage · 7703773e
      Nicolas Iooss 提交于
      The struct cfg80211_pmksa defines its bssid field as:
      
          const u8 *bssid;
      
      contrary to struct brcmf_pmksa, which uses:
      
          u8 bssid[ETH_ALEN];
      
      Therefore in brcmf_cfg80211_del_pmksa(), &pmksa->bssid takes the address
      of this field (of type u8**), not the one of its content (which would be
      u8*).  Remove the & operator to make brcmf_dbg("%pM") and memcmp()
      behave as expected.
      
      This bug have been found using a custom static checker (which checks the
      usage of %p... attributes at build time).  It has been introduced in
      commit 6c404f34 ("brcmfmac: Cleanup pmksa cache handling code"),
      which replaced pmksa->bssid by &pmksa->bssid while refactoring the code,
      without modifying struct cfg80211_pmksa definition.
      
      Replace &pmk[i].bssid with pmk[i].bssid too to make the code clearer,
      this change does not affect the semantic.
      
      Fixes: 6c404f34 ("brcmfmac: Cleanup pmksa cache handling code")
      Cc: stable@vger.kernel.org
      Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      7703773e
  19. 24 8月, 2016 1 次提交
    • M
      brcmfmac: Change vif_event_lock to spinlock · b64abcb7
      mhiramat@kernel.org 提交于
      Change vif_event_lock to spinlock from mutex, since this lock is
      used in wait_event_timeout() via vif_event_equals(). This caused
      a warning report as below.
      
      As far as I can see, this lock protects regions where updating
      structure members, not function calls. Also, since those
      regions are not called from interrupt handlers (of course, it
      was a mutex), spin_lock is used instead of spin_lock_irqsave.
      
      [  186.678550] ------------[ cut here ]------------
      [  186.678556] WARNING: CPU: 2 PID: 7140 at /home/mhiramat/ksrc/linux/kernel/sched/core.c:7545 __might_sleep+0x7c/0x80
      [  186.678560] do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff980d9090>] prepare_to_wait_event+0x60/0x100
      [  186.678560] Modules linked in: brcmfmac xt_CHECKSUM rfcomm ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_addrtype br_netfilter xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_raw ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_filter ip6_tables iptable_raw iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter ip_tables x_tables bnep nls_iso8859_1 i2c_designware_platform i2c_designware_core snd_hda_codec_hdmi snd_hda_codec_realtek dcdbas snd_hda_codec_generic snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal intel_powerclamp coretemp
      [  186.678594]  snd_pcm crct10dif_pclmul crc32_pclmul aesni_intel aes_x86_64 joydev glue_helper snd_hwdep lrw gf128mul uvcvideo ablk_helper snd_seq_midi cryptd snd_seq_midi_event snd_rawmidi videobuf2_vmalloc videobuf2_memops snd_seq input_leds videobuf2_v4l2 cfg80211 videobuf2_core snd_timer videodev serio_raw btusb snd_seq_device media btrtl rtsx_pci_ms snd mei_me memstick hid_multitouch mei soundcore brcmutil idma64 virt_dma intel_lpss_pci processor_thermal_device intel_soc_dts_iosf hci_uart btbcm btqca btintel bluetooth int3403_thermal dell_smo8800 intel_lpss_acpi intel_lpss int3402_thermal int340x_thermal_zone intel_hid mac_hid int3400_thermal shpchp sparse_keymap acpi_pad acpi_thermal_rel acpi_als kfifo_buf industrialio kvm_intel kvm irqbypass parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq
      [  186.678631]  usbhid nouveau ttm i915 rtsx_pci_sdmmc mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops psmouse drm ahci rtsx_pci nvme nvme_core libahci i2c_hid hid pinctrl_sunrisepoint video wmi pinctrl_intel fjes [last unloaded: brcmfmac]
      [  186.678646] CPU: 2 PID: 7140 Comm: wpa_supplicant Not tainted 4.8.0-rc1+ #8
      [  186.678647] Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 01.02.00 04/07/2016
      [  186.678648]  0000000000000000 ffff9d8c64b5b900 ffffffff98442f23 ffff9d8c64b5b950
      [  186.678651]  0000000000000000 ffff9d8c64b5b940 ffffffff9808b22b 00001d790000000d
      [  186.678653]  ffffffff98c75e78 000000000000026c 0000000000000000 ffff9d8c2706d058
      [  186.678655] Call Trace:
      [  186.678659]  [<ffffffff98442f23>] dump_stack+0x85/0xc2
      [  186.678666]  [<ffffffff9808b22b>] __warn+0xcb/0xf0
      [  186.678668]  [<ffffffff9808b29f>] warn_slowpath_fmt+0x4f/0x60
      [  186.678671]  [<ffffffff980d9090>] ? prepare_to_wait_event+0x60/0x100
      [  186.678672]  [<ffffffff980d9090>] ? prepare_to_wait_event+0x60/0x100
      [  186.678674]  [<ffffffff980b922c>] __might_sleep+0x7c/0x80
      [  186.678680]  [<ffffffff988b0853>] mutex_lock_nested+0x33/0x3b0
      [  186.678682]  [<ffffffff980e5d8d>] ? trace_hardirqs_on+0xd/0x10
      [  186.678689]  [<ffffffffc0c57d2d>] brcmf_cfg80211_wait_vif_event+0xcd/0x130 [brcmfmac]
      [  186.678691]  [<ffffffff980d9190>] ? wake_atomic_t_function+0x60/0x60
      [  186.678697]  [<ffffffffc0c628e9>] brcmf_p2p_del_vif+0xf9/0x220 [brcmfmac]
      [  186.678702]  [<ffffffffc0c57fab>] brcmf_cfg80211_del_iface+0x21b/0x270 [brcmfmac]
      [  186.678716]  [<ffffffffc0b0539e>] nl80211_del_interface+0xfe/0x3a0 [cfg80211]
      [  186.678718]  [<ffffffff987ca335>] genl_family_rcv_msg+0x1b5/0x370
      [  186.678720]  [<ffffffff980e5d8d>] ? trace_hardirqs_on+0xd/0x10
      [  186.678721]  [<ffffffff987ca56d>] genl_rcv_msg+0x7d/0xb0
      [  186.678722]  [<ffffffff987ca4f0>] ? genl_family_rcv_msg+0x370/0x370
      [  186.678724]  [<ffffffff987c9a47>] netlink_rcv_skb+0x97/0xb0
      [  186.678726]  [<ffffffff987ca168>] genl_rcv+0x28/0x40
      [  186.678727]  [<ffffffff987c93c3>] netlink_unicast+0x1d3/0x2f0
      [  186.678729]  [<ffffffff987c933b>] ? netlink_unicast+0x14b/0x2f0
      [  186.678731]  [<ffffffff987c97cb>] netlink_sendmsg+0x2eb/0x3a0
      [  186.678733]  [<ffffffff9876dad8>] sock_sendmsg+0x38/0x50
      [  186.678734]  [<ffffffff9876e4df>] ___sys_sendmsg+0x27f/0x290
      [  186.678737]  [<ffffffff9828b935>] ? mntput_no_expire+0x5/0x3f0
      [  186.678739]  [<ffffffff9828b9be>] ? mntput_no_expire+0x8e/0x3f0
      [  186.678741]  [<ffffffff9828b935>] ? mntput_no_expire+0x5/0x3f0
      [  186.678743]  [<ffffffff9828bd44>] ? mntput+0x24/0x40
      [  186.678744]  [<ffffffff98267830>] ? __fput+0x190/0x200
      [  186.678746]  [<ffffffff9876f125>] __sys_sendmsg+0x45/0x80
      [  186.678748]  [<ffffffff9876f172>] SyS_sendmsg+0x12/0x20
      [  186.678749]  [<ffffffff988b5680>] entry_SYSCALL_64_fastpath+0x23/0xc1
      [  186.678751]  [<ffffffff980e2b8f>] ? trace_hardirqs_off_caller+0x1f/0xc0
      [  186.678752] ---[ end trace e224d66c5d8408b5 ]---
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      b64abcb7
  20. 19 7月, 2016 1 次提交
  21. 08 7月, 2016 1 次提交
  22. 06 7月, 2016 1 次提交
    • A
      nl80211: support beacon report scanning · 1d76250b
      Avraham Stern 提交于
      Beacon report radio measurement requires reporting observed BSSs
      on the channels specified in the beacon request. If the measurement
      mode is set to passive or active, it requires actually performing a
      scan (passive or active, accordingly), and reporting the time that
      the scan was started and the time each beacon/probe was received
      (both in terms of TSF of the BSS of the requesting AP). If the
      request mode is table, this information is optional.
      In addition, the radio measurement request specifies the channel
      dwell time for the measurement.
      
      In order to use scan for beacon report when the mode is active or
      passive, add a parameter to scan request that specifies the
      channel dwell time, and add scan start time and beacon received time
      to scan results information.
      
      Supporting beacon report is required for Multi Band Operation (MBO).
      Signed-off-by: NAssaf Krauss <assaf.krauss@intel.com>
      Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
      Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1d76250b
  23. 29 6月, 2016 1 次提交