The first pull request for 4.15, unusually late this time but still
relatively small. Also includes merge from wireless-drivers to fix
conflicts in iwlwifi.
Major changes:
rsi
* add P2P mode support
* sdio suspend and resume support
iwlwifi
* A fix and an addition for PCI devices for the A000 family
* Dump PCI registers when an error occurs, to make it easier to debug
rtlwifi
* add support for 64 bit DMA, enabled with a module parameter
* add module parameter to enable ASPM
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJZ5x32AAoJEG4XJFUm622b22EIAKmIlD1tAXxK9YAtYE5AnD5A
QpklYuVJA4XFtpN9UKXP/KCGTRnflW6i4RQ3dt6WKNULkL8RMAjwDijxXrFz8YXw
uB1Aw+Rbmx8eSrWKTgBCLlfU4J3j8jj5gSc7rzYeG7DnMFVShRCxRChiR09GhY4n
gXX3p4+migW128EyQ4KYYFGxipS+5/0igsSwqE6UIyxDuhINjCS9MipwXmv2uG+G
eYOSlwPE+LI8rObqlaJKVgam77srQqZLnPnima+bKAYXiQOPxPDBLwGP1qjo38Wa
pHKDG//OPMOjyUccl5axulnvLPTjyng9jYNpzJlLLz9+M29SudtHI7YQQHhBj5M=
=bApF
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2017-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.15
The first pull request for 4.15, unusually late this time but still
relatively small. Also includes merge from wireless-drivers to fix
conflicts in iwlwifi.
Major changes:
rsi
* add P2P mode support
* sdio suspend and resume support
iwlwifi
* A fix and an addition for PCI devices for the A000 family
* Dump PCI registers when an error occurs, to make it easier to debug
rtlwifi
* add support for 64 bit DMA, enabled with a module parameter
* add module parameter to enable ASPM
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
brcmf_fweh_process_event() sets event->datalen to the
endian-swapped value of event_packet->msg.datalen, which is the
same as emsg.datalen. This length is already validated in
brcmf_fweh_process_event(), so there is no need to check it
again upon dequeuing the event.
Suggested-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before
the length of rxframe is validated. This could lead to uninitialized
data being accessed (but not printed). Since we already have a
perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec,
and ch.chspec is not modified by decchspec(), avoid the extra
assignment and use ch.chspec in the debug print.
Suggested-by: Mattias Nissler <mnissler@chromium.org>
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Here, I'm reducing the stack size by marking as many local variables as
'static const' as I can without changing the actual code.
This is the first of three patches to improve the stack usage in this
driver. It would be good to have this backported to stabl kernels
to get all drivers in 'allmodconfig' below the 2048 byte limit so
we can turn on the frame warning again globally, but I realize that
the patch is larger than the normal limit for stable backports.
The other two patches do not need to be backported.
Cc: <stable@vger.kernel.org>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The length of the data in the received skb is currently passed into
brcmf_fweh_process_event() as packet_len, but this value is not checked.
event_packet should be followed by DATALEN bytes of additional event
data. Ensure that the received packet actually contains at least
DATALEN bytes of additional data, to avoid copying uninitialized memory
into event->data.
Cc: <stable@vger.kernel.org> # v3.8
Suggested-by: Mattias Nissler <mnissler@chromium.org>
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Don't populate const arrays on the stack, instead make them static.
Makes the object code smaller by over 60 bytes:
Before:
text data bss dec hex filename
14816 1296 0 16112 3ef0 b43/phy_ht.o
After:
text data bss dec hex filename
14551 1496 0 16047 3eaf b43/phy_ht.o
(gcc 6.3.0, x86-64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Don't populate const array ucode_ofdm_rates on the stack, instead make it
static. Makes the object code smaller by 100 bytes:
Before:
text data bss dec hex filename
39482 564 0 40046 9c6e phy_cmn.o
After
text data bss dec hex filename
39326 620 0 39946 9c0a phy_cmn.o
(gcc 6.3.0, x86-64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The u8 char array ret is not being initialized and elements outside
the range start to end contain just garbage values from the stack.
This results in a later scan of the array to read potentially
uninitialized values. Fix this by initializing the array to zero.
This seems to have been an issue since the very first commit.
Detected by CoverityScan CID#139653 ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Michael Buesch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The u8 char array ret is not being initialized and elements outside
the range start to end contain just garbage values from the stack.
This results in a later scan of the array to read potentially
uninitialized values. Fix this by initializing the array to zero.
This seems to have been an issue since the very first commit.
Detected by CoverityScan CID#139652 ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Michael Buesch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The driver was not properly configuring firmware with regard to the
type of scan. It always performed an active scan even when user-space
was requesting for passive scan, ie. the scan request was done without
any SSIDs specified.
Cc: stable@vger.kernel.org # v4.0.x
Reported-by: Huang, Jiangyang <Jiangyang.Huang@itron.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Upon handling the firmware notification for scans the length was
checked properly and may result in corrupting kernel heap memory
due to buffer overruns. This fix addresses CVE-2017-0786.
Cc: stable@vger.kernel.org # v4.0.x
Cc: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The firmware feature check introduced for multi-scheduled scan is also
failing for bcm4345 devices resulting in a firmware crash.
The reason for this crash has not yet been root cause so this patch avoids
the feature check for those device as a short-term fix.
Fixes: 9fe929aaac ("brcmfmac: add firmware feature detection for gscan feature")
Cc: <stable@vger.kernel.org> # v4.13
Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
For debugging some problems, it is useful to know the chip revision
add a brcmf_info message logging this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Stephen Rothwell reported quite a few conflicts in iwlwifi between
wireless-drivers and wireless-drivers-next. To avoid any problems later in
other trees merge w-d to w-d-next to fix those conflicts early.
The firmware feature check introduced for multi-scheduled scan turned out
to be failing for bcm4343{0,1,8} devices resulting in a firmware crash.
The reason for this crash has not yet been root cause so this patch avoids
the feature check for those device as a short-term fix.
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Reported-by: Ian Molton <ian@mnementh.co.uk>
Fixes: 9fe929aaac ("brcmfmac: add firmware feature detection for gscan feature")
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by <linux/usb.h> work with
const usb_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
After association, ping is not working when sweeping the channel at the
AP side. It is caused by having incorrect carrier state (OFF) for the STA
in successful roaming. This patch sets the carrier state ON for the case.
Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When the device/firmware supports multi-channel, it can have P2P
connection and regular connection with AP simultaneous. In this case,
the num_different_channels in wiphy info was not correct when firmware
supports multi-channel (The iw wiphy# info showed "#channels <= 1" in
interface combinations). It caused association failed and error message
"CTRL-EVENT-FREQ-CONFLICT error" in wpa_supplicant when P2P GO interface
was running at the same time.
The root cause is that the num_different_channels was always overridden
to 1 in brcmf_setup_ifmodes even multi-channel was enabled.
We correct the logic by moving num_different_channels setting forward.
Signed-off-by: Wright Feng <wright.feng@cypress.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Add support for CYW4373 SDIO/USB chipset.
CYW4373 is a 1x1 dual-band 11ac chipset with 20/40/80Mhz channel support.
It's a WiFi/BT combo device.
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When setting wpa_auth to WPA_AUTH_NONE(1) in AP mode with WEP security,
firmware will set privacy bit and add WPA OUI in VENDOR IE in beacon and
probe response. The security type in softAP beacons confuse the
supplicant in client side, and the user client will see [WPA-?] in
supplicant scan result. So we set WPA_AUTH_DISABLED in softAP mode with
OPEN security.
Signed-off-by: Wright Feng <wright.feng@cypress.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The first wireless-drivers-next pull request for 4.14. I'm submitting
this unusally late in the cycle as my vacation postponed this. But
even if this is late there's not still that much new features, mostly
cleanup or fixes.
Major changes:
ath10k
* preparation for wcn3990 support
iwlwifi
* Reorganization of the code into separate directories continues
qtnfmac
* regulatory support updates
* add get_channel, dump_survey and channel_switch cfg80211 handlers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJZiHuQAAoJEG4XJFUm622bVSEIAKdausycC6OOZjwTGWnFyxE/
58n79VTrTbXVLwJ7lSBCGYCTujc7amPxAVlDOLYd+9TKm0fO7gap50Gdl35HO5sp
9v/augHQSouz52q2vgsTi0JbXsqhJQZ4Ie4P0fo8OyqJMYAvFga2FhFBpJseMYd9
NX88SMoxAGgDkTC0JfzzLnA/jZ0W6ULai6zmRE1s6lUIynP2kzHgpfbMH3+KEkod
SUW+yX91MdOkkyFGXyY11uuBqanUpEVSAQXW6J76vw3qS88qIqaL3iIeJ6C4Vozq
fKNkHN4iZOd9FlKY1IFi4vS0+7hWiq6DQ3c+ngtU6cuq1XdBa6PuanC3I2e0B8E=
=PKUU
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2017-08-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.14
The first wireless-drivers-next pull request for 4.14. I'm submitting
this unusally late in the cycle as my vacation postponed this. But
even if this is late there's not still that much new features, mostly
cleanup or fixes.
Major changes:
ath10k
* preparation for wcn3990 support
iwlwifi
* Reorganization of the code into separate directories continues
qtnfmac
* regulatory support updates
* add get_channel, dump_survey and channel_switch cfg80211 handlers
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Two minor conflicts in virtio_net driver (bug fix overlapping addition
of a helper) and MAINTAINERS (new driver edit overlapping revamp of
PHY entry).
Signed-off-by: David S. Miller <davem@davemloft.net>
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Due to a bugfix in wireless tree and the commit mentioned below a merge
was needed which went haywire. So the submitted change resulted in the
function brcmf_sdiod_sgtable_alloc() being called twice during the probe
thus leaking the memory of the first call.
Cc: stable@vger.kernel.org # 4.6.x
Fixes: 4d79289598 ("brcmfmac: switch to new platform data")
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is already sufficient headroom.
pskb_expand_head() does allow for size being 0, in which case it just
copies, so clamp the header delta to zero.
Opening Chrome (and all my tabs) on a PCIE device was enough to reliably
hit this.
Fixes: 270a6c1f65 ("brcmfmac: rework headroom check in .start_xmit()")
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
Cc: Hante Meuleman <hante.meuleman@broadcom.com>
Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Cc: Franky Lin <franky.lin@broadcom.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
we can use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
1. drivers/net/appletalk/ipddp.c
2. drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Recent change in brcmf_sdio_txpkt_hdalign() changed the
behavior and now always returns 0. This resulted in a
regression which basically renders the device useless.
Fixes: 270a6c1f65 ("brcmfmac: rework headroom check in .start_xmit()")
Reported-by: S. Gilles <sgilles@math.umd.edu>
Tested-by: S. Gilles <sgilles@math.umd.edu>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The lower level nl80211 code in cfg80211 ensures that "len" is between
25 and NL80211_ATTR_FRAME (2304). We subtract DOT11_MGMT_HDR_LEN (24) from
"len" so thats's max of 2280. However, the action_frame->data[] buffer is
only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can
overflow.
memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
le16_to_cpu(action_frame->len));
Cc: stable@vger.kernel.org # 3.9.x
Fixes: 18e2f61db3 ("brcmfmac: P2P action frame tx.")
Reported-by: "freenerguo(郭大兴)" <freenerguo@tencent.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The driver used cfg80211_connect_result() which is basically a wrapper
around cfg80211_connect_done() passing a subset of the information that
can be passed. For upcoming functionality this is not sufficient so
switching to use cfg80211_connect_done().
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Adding callbacks for PMK provisioning. If firmware supports offloading
it is indicated to user-space that 802.1X offload is supported.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The firmware may have supplicant code built-in. This is detected
by the driver and indicated in the wiphy features flags. User-space
can use this flag to determine whether or not to provide the
pre-shared key material in the nl80211 CONNECT command.
Reviewed-by: Gautam (Gautam Kumar) Shukla <gautams@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Since commit 9cc4b7cb86 ("brcmfmac: Make skb header writable
before use") the headroom usage has been fixed. However, the
driver was keeping statistics that got lost. So reworking the
code so we get those driver statistics back for debugging.
Cc: James Hughes <james.hughes@raspberrypi.org>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The statistic counter is used in common layer and in the bus layer
in different thread contexts so change to use atomic operations.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
A couple of old fields were still described and one field was not
described.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
If 'wiphy_new()' fails, we leak 'ops'. Add a new label in the error
handling path to free it in such a case.
Cc: stable@vger.kernel.org
Fixes: 5c22fb8510 ("brcmfmac: add wowl gtk rekeying offload support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The function brcmf_net_attach() can only fail when register_netdevice()
fails. When this happens register_netdevice() calls priv_destructor, ie.
brcmf_cfg80211_free_netdev() freeing the vif instance. Also upon this
failure brcmf_net_attach() calls free_netdev(). However, callers are also
doing cleanup resulting in double free. In some places they need netdev
private space as it holds parameters to communicate with the device. So
we want to do the cleanup only in callers of brcmf_net_attach() by making
the following changes:
- set priv_destructor after register_netdevice() succeeds.
- remove call to free_netdev() in brcmf_net_attach().
- call free_netdev() in brcmf_net_detach() for unregistered netdev.
- add free_netdev() if brcmf_net_attach() fails for a created interface.
Fixes: cf124db566 ("net: Fix inconsistent teardown and release of private netdev state.")
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
New features and bug fixes to quite a few different drivers, but
nothing really special standing out.
What makes me happy that we have now more vendors actively
contributing to upstream drivers. In this pull request we have patches
from Broadcom, Intel, Qualcomm, Realtek and Redpine Signals, and I
still have patches from Marvell and Quantenna pending in patchwork. Now
that's something comparing to how things looked 11 years ago in Jeff
Garzik's "State of the Union: Wireless" email:
https://lkml.org/lkml/2006/1/5/671
Major changes:
wil6210
* add low level RF sector interface via nl80211 vendor commands
* add module parameter ftm_mode to load separate firmware for factory
testing
* support devices with different PCIe bar size
* add support for PCIe D3hot in system suspend
* remove ioctl interface which should not be in a wireless driver
ath10k
* go back to using dma_alloc_coherent() for firmware scratch memory
* add per chain RSSI reporting
brcmfmac
* add support multi-scheduled scan
* add scheduled scan support for specified BSSIDs
* add support for brcm43430 revision 0
wlcore
* add wil1285 compatible
rsi
* add RS9113 USB support
iwlwifi
* FW API documentation improvements (for tools and htmldoc)
* continuing work for the new A000 family
* bump the maximum supported FW API to 31
* improve the differentiation between 8000, 9000 and A000 families
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJZT/ROAAoJEG4XJFUm622b/IwH+wQtBXP+P57DZ97BdETcZ3Wd
ejm9KKT3IxcP7kzItT9UR1zv7LNx4NgSkJMfhf37jJ1WIuE2fp/ctNv6mz3PvohW
jD1fLynwEMMC7PLHEy5+xGtL61KYc2mtXs/bfLFl94hZUiaocrsBDIT4fXoyIWif
y3MUlBKDbHA27ULRd485C0MRekRSvR/rq6iST4KsIsa8RflJbdH64teTEnQPp4kh
nvhfnaxVEqHK7mYbarC58yYLNOU8gfQXmeeTfd6jhCXRjfEw37IvtNC8BT4B9ZDX
YMZLbkeDSwNGXIH7EIrpGOYHCPh+qsiJ+sx7YodomcJvd1nVrmbuZZt9/EqWXuY=
=Fd/c
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2017-06-25' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.13
New features and bug fixes to quite a few different drivers, but
nothing really special standing out.
What makes me happy that we have now more vendors actively
contributing to upstream drivers. In this pull request we have patches
from Broadcom, Intel, Qualcomm, Realtek and Redpine Signals, and I
still have patches from Marvell and Quantenna pending in patchwork. Now
that's something comparing to how things looked 11 years ago in Jeff
Garzik's "State of the Union: Wireless" email:
https://lkml.org/lkml/2006/1/5/671
Major changes:
wil6210
* add low level RF sector interface via nl80211 vendor commands
* add module parameter ftm_mode to load separate firmware for factory
testing
* support devices with different PCIe bar size
* add support for PCIe D3hot in system suspend
* remove ioctl interface which should not be in a wireless driver
ath10k
* go back to using dma_alloc_coherent() for firmware scratch memory
* add per chain RSSI reporting
brcmfmac
* add support multi-scheduled scan
* add scheduled scan support for specified BSSIDs
* add support for brcm43430 revision 0
wlcore
* add wil1285 compatible
rsi
* add RS9113 USB support
iwlwifi
* FW API documentation improvements (for tools and htmldoc)
* continuing work for the new A000 family
* bump the maximum supported FW API to 31
* improve the differentiation between 8000, 9000 and A000 families
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Two entries being added at the same time to the IFLA
policy table, whilst parallel bug fixes to decnet
routing dst handling overlapping with the dst gc removal
in net-next.
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes spin-forever in irq handler when IRQ is already asserted
at request_irq() time.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The brcm43430 chip needs different firmware files for chip revision 0
and 1. The file currently in linux-firmware is for revision 1 only.
This commit makes brcmfmac request brcmfmac43430a0-sdio.bin instead
of brcmfmac43430-sdio.bin for revision 0 chips.
Note that the behavior for revision 1 chips is not changed, ideally those
would load brcmfmac43430a1-sdio.bin, but that will break existing setups.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Two important fixes for brcmfmac. The rest of the brcmfmac patches are
either code preparation and fixing a new build warning.
brcmfmac
* fix a NULL pointer dereference during resume
* fix a NULL pointer dereference with USB devices, a regression from
v4.12-rc1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJZSSOQAAoJEG4XJFUm622browIAKdoXRzDj9t/r1s9UY+Fvm2w
YLiVCEy3Z/enF2iQcdmBC+uHNeaVWGctvjljxWwL6UsWx+Dl0/Dxcfilnan7SrYI
x5ysh+K4vfQ3oOf314vRuw+7u/h1WgobxdD9dgv7+C8yA7AIgHJlzZeM6PYdhibE
cEw/BOKDMDQ9NDnTJmaUmUogB/92TP3f5ACrNBe11kyPBtHuYFhNzee3PJQ3xP3I
D2knpUD3LtHhPDRC7ku9tpsmBpGHbOwGPHkLW1i9YhjHPe5ecmfvXtc7o/yUlLZK
f+xOMNuktUwsTjV0qhRnwx6Z2uJS1LlCmqVncaZIn7f+BYhORmTYIo45x628FGg=
=D6GF
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-for-davem-2017-06-20' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
wireless-drivers fixes for 4.12
Two important fixes for brcmfmac. The rest of the brcmfmac patches are
either code preparation and fixing a new build warning.
brcmfmac
* fix a NULL pointer dereference during resume
* fix a NULL pointer dereference with USB devices, a regression from
v4.12-rc1
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.
An spatch similar to the one for skb_put_zero() converts many
of the places using it:
@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)
@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)
@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);
(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes the following warning:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function
'brcmf_usb_probe_phase2':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:1198:2:
warning: 'devinfo' may be used uninitialized in this function
[-Wmaybe-uninitialized]
mutex_unlock(&devinfo->dev_init_lock);
Fixes: 6d0507a777 ("brcmfmac: add parameter to pass error code in firmware callback")
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
USB devices rely on queuing functionality provided by the fwsignal
module regardless the mode fwsignal is operating in. For this some
data structure needs to be reserved which is tied to the interface,
which is done by brcmf_fws_add_interface(). However, it checks the
mode. Replace that by checking result from brcmf_fws_queue_skbs().
Otherwise the driver will crash in a null pointer dereference when
data is transmitted on the interface.
Fixes: fc0471e3e8 ("brcmfmac: ignore interfaces when fwsignal is disabled")
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When request firmware fails, brcmf_ops_sdio_remove is being called and
brcmf_bus freed. In such circumstancies if you do a suspend/resume cycle
the kernel hangs on resume due a NULL pointer dereference in resume
function. So in brcmf_sdio_firmware_callback() we need to unbind the
driver from both sdio_func devices when firmware load failure is indicated.
Cc: stable@vger.kernel.org # 4.9.x-
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When firmware loading failed the code used to unbind the device provided
by the calling code. However, for the sdio driver two devices are bound
and both need to be released upon failure. The callback has been extended
with parameter to pass error code so add that in this commit upon firmware
loading failure.
Cc: stable@vger.kernel.org # 4.9.x-
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>