Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 09 9月, 2016 1 次提交
  3. 04 9月, 2016 2 次提交
    • 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
    • I
      brcmfmac: Add USB ID for Cisco Linksys AE1200 · bccf3ffc
      由 Ismael Luceno 提交于 
      The AE1200 comes with different revisions of the BCM43235 chipset,
but all have the same USB ID. Only revision 3 can be supported.
Signed-off-by: NIsmael Luceno <ismael@iodev.co.uk>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      bccf3ffc
  5. 03 9月, 2016 1 次提交
  7. 14 8月, 2016 1 次提交
  9. 20 7月, 2016 3 次提交
  11. 19 7月, 2016 3 次提交
  13. 08 7月, 2016 2 次提交
    • R
      brcmfmac: support removing AP interfaces with "interface_remove" · dba8fbc6
      由 Rafał Miłecki 提交于 
      New firmwares (e.g. 10.10.69.36 for BCM4366) support "interface_remove"
for removing interfaces. Try to use this method on cfg80211 request. In
case of older firmwares (e.g. 7.35.177.56 for BCM43602 as I tested) this
will just result in firmware rejecting command and this won't change any
behavior.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      dba8fbc6
    • R
      brcmfmac: delete interface directly in code that sent fw request · a63b0987
      由 Rafał Miłecki 提交于 
      So far when receiving event about in-firmware-interface removal our
event worker was notifying listener and afterwards it was removing Linux
interface.

First of all it was resulting in slightly unexpected order. The listener
(del_virtual_intf callback) was (usually) returning with success before
we even called unregister_netdev(ice).

Please note this couldn't be simply fixed by changing order of calls in
brcmf_fweh_handle_if_event as unregistering interface earlier could free
struct brcmf_if.

Another problem of current implementation are possible lockups. Focus on
the time slot between calling event handler and removing Linux
interface. During that time original caller may leave (unlocking rtnl
semaphore) *and* another call to the same code may be done (locking it
again). If that happens our event handler will stuck at removing Linux
interface, it won't handle another event and will block process holding
rtnl lock.

This can be simply solved by unregistering interface in a proper
callback, right after receiving confirmation event from firmware. This
only required modifying worker to don't unregister on its own if there
is someone waiting for the event.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      a63b0987
  15. 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
  17. 30 6月, 2016 2 次提交
  19. 29 6月, 2016 4 次提交
  21. 16 6月, 2016 13 次提交
  23. 14 6月, 2016 4 次提交
  25. 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
  27. 04 6月, 2016 2 次提交
    • A
      b43: don't unconditionally fall back to CCK if the rate is 6MB OFDM. · d0b03439
      由 Adrian Chadd 提交于 
      Check the current PHY operating mode (gmode) to see if we should
fall back from 6MB OFDM to 11MB CCK.  For 5GHz operation this isn't
allowed.

Note, the fallback lookup is only done for RTS rates; normal fallback
rates are done via mac80211 and aren't affected by this change.
Signed-off-by: NAdrian Chadd <adrian@freebsd.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      d0b03439
    • C
      brcmfmac: Fix 'did not remove int handler' warning · b7467401
      由 Christian Daudt 提交于 
      brcmf_sdiod_intr_unregister call that removes both func1 and
func2 interrupt handlers only called when brcmf_ops_sdio_remove
is called for func 1 (which is the 2nd call) but sdio is expecting
it to be removed at the end of each sdio_remove call.
This is causing 'rmmod bcmrfmac' on a 4356-sdio chip to complain
with:
WARNING: driver brcmfmac did not remove its interrupt handler!

The modification makes calling brcmf_sdiod_intr_unregister multiple
times harmless by clearing the variables that track if interrupt
handlers have been installed, and then calls it on every
brcmf_ops_sdio_remove call instead of just remove for func 1.
Signed-off-by: NChristian Daudt <csd@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      b7467401