Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 29 11月, 2016 2 次提交
  3. 23 11月, 2016 1 次提交
  5. 17 11月, 2016 1 次提交
  7. 27 9月, 2016 4 次提交
  9. 07 9月, 2016 1 次提交
  11. 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
  13. 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
  15. 19 7月, 2016 1 次提交
  17. 08 7月, 2016 1 次提交
  19. 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
  21. 29 6月, 2016 1 次提交
  23. 16 6月, 2016 4 次提交
    • R
      brcmfmac: drop unused pm_block vif attribute · 26072330
      由 Rafał Miłecki 提交于 
      This attribute was added 3 years ago by
commit 3eacf866 ("brcmfmac: introduce brcmf_cfg80211_vif structure")
but it remains unused since then. It seems we can safely drop it.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      26072330
    • R
      brcmfmac: don't remove interface on link down firmware event · fd3667a8
      由 Rafał Miłecki 提交于 
      There are two firmware events we handle similarly in brcmfmac:
BRCMF_E_LINK and BRCMF_E_IF. The difference from firmware point of view
is that the first one means BSS remains present in the firmware. Trying
to (re)create it (e.g. when adding new virtual interface) will result in
an error.

Current code treats both events in a similar way. It removes Linux
interface for each of them. It works OK with e.g. BCM43602. Its firmware
generates both events for each interface. It means we get BRCMF_E_LINK
and remove interface. That is soon followed by BRCMF_E_IF which means
BSS was also removed in a firmware. The only downside of this is a
harmless error like:
[  208.643180] brcmfmac: brcmf_fweh_call_event_handler: no interface object

Unfortunately BCM4366 firmware doesn't automatically remove BSS and so
it doesn't generate BRCMF_E_IF. In such case we incorrectly remove Linux
interface on BRCMF_E_LINK as BSS is still present in the firmware. It
results in an error when trying to re-create virtual interface, e.g.:
> iw phy phy1 interface add wlan1-1 type __ap
[ 3602.929199] brcmfmac: brcmf_ap_add_vif: timeout occurred
command failed: I/O error (-5)

With this patch we don't remove Linux interface while firmware keeps
BSS. Thanks to this we keep a consistent states of host driver and
device firmware.

Further improvement should be to mark BSS as disabled and remove
interface on BRCMF_E_LINK. Then we should add support for reusing
BSS-es.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      fd3667a8
    • R
      brcmfmac: fix setting AP channel with new firmwares · 8707e08d
      由 Rafał Miłecki 提交于 
      Firmware for new chipsets is based on a new major version of code
internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for
BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was
based on 7.35.177.56.

Currently setting AP 5 GHz channel doesn't work reliably with BCM4366B1.
When setting e.g. 36 control channel with VHT80 (center channel 42)
firmware may randomly pick one of:
1) 52 control channel with 58 as center one
2) 100 control channel with 106 as center one
3) 116 control channel with 122 as center one
4) 149 control channel with 155 as center one

It seems new firmwares require setting AP mode (BRCMF_C_SET_AP) before
specifying a channel. Changing an order of firmware calls fixes the
problem. This requirement resulted in two separated "chanspec" calls,
one in AP code path and one in P2P path.

This fix was verified with BCM4366B1 and tested for regressions on
BCM43602.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      8707e08d
    • R
      brcmfmac: print errors if creating interface fails · 0cd33c20
      由 Rafał Miłecki 提交于 
      This is helpful for debugging. Without this all I was getting from "iw"
command on failed creating of P2P interface was:
> command failed: Too many open files in system (-23)
Signed-off-by: NRafal Milecki <zajec5@gmail.com>
[arend@broadcom.com: reduce error prints upon iface creation]
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Reviewed-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      0cd33c20
  25. 14 6月, 2016 3 次提交
  27. 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
  29. 28 5月, 2016 1 次提交
  31. 26 4月, 2016 1 次提交
  33. 14 4月, 2016 1 次提交
  35. 12 4月, 2016 1 次提交
  37. 07 3月, 2016 11 次提交
  39. 06 2月, 2016 1 次提交
  41. 08 1月, 2016 1 次提交