Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 4月, 2017 2 次提交
  3. 13 4月, 2017 4 次提交
  5. 05 4月, 2017 1 次提交
  7. 21 3月, 2017 2 次提交
  9. 28 2月, 2017 1 次提交
  11. 07 2月, 2017 1 次提交
  13. 31 1月, 2017 4 次提交
  15. 20 1月, 2017 1 次提交
  17. 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
  19. 30 12月, 2016 1 次提交
  21. 20 12月, 2016 1 次提交
  23. 29 11月, 2016 9 次提交
  25. 23 11月, 2016 1 次提交
  27. 17 11月, 2016 1 次提交
  29. 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
  31. 13 10月, 2016 1 次提交
  33. 27 9月, 2016 4 次提交
  35. 07 9月, 2016 1 次提交
  37. 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