- 28 Mar, 2018 2 commits
-
-
Sara Sharon authored
Hardware bug was fixed in later generation. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.gitKalle Valo authored
Requested by Luca, needed for upcoming patch "iwlwifi: add a bunch of new 9000 PCI IDs".
-
- 27 Mar, 2018 37 commits
-
-
Lorenzo Bianconi authored
Fall back to software encryption for hw unsupported ciphers in order to fix the following warning in ieee80211_get_key_rx_seq routine: WARNING: CPU: 1 PID: 1277 at backports-2017-11-01/net/mac80211/key.c: 1010 mt76_wcid_key_setup+0x6c/0x138 [mt76] CPU: 1 PID: 1277 Comm: hostapd Tainted: G W 4.9.86 #0 Stack : 00000000 00000000 80527b4a 00000042 80523824 00000000 00000000 80520000 8fd79a9c 804bbda7 80454c84 00000001 000004fd 80523824 8f7e4ba0 8eceda12 00000010 8006af94 00000001 80520000 804c1f04 804c1f08 80459890 8ec999b4 00000003 800a7840 8f7e4ba0 8eceda12 8121de20 00000000 00000001 00c999b4 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ... Call Trace: [<8000f52c>] show_stack+0x70/0x8c [<801d8d04>] dump_stack+0x94/0xd0 [<8002bcd4>] __warn+0x110/0x118 [<8002bd70>] warn_slowpath_null+0x1c/0x2c [<8f0415cc>] mt76_wcid_key_setup+0x6c/0x138 [mt76] [<8f1311b4>] mt76x2_dma_cleanup+0xa38/0x1048 [mt76x2e] Fixes: 30ce7f44 ("mt76: validate rx CCMP PN") Signed-off-by:Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Acked-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Lorenzo Bianconi authored
Fix a theoretical NULL pointer dereferencing in mt76x2_tx routine that can occurs for injected frames in a monitor vif since vif pointer could be NULL for that interfaces Fixes: 23405236 ("mt76: fix transmission of encrypted mgmt frames") Signed-off-by:
-
Lorenzo Bianconi authored
Use mt76_poll_msec() in mt76pci_load_firmware to check if the firmware has been started instead of explicitly poll MCU running register Signed-off-by:
-
Takashi Iwai authored
The brcms_ucode_init_buf() duplicates the ucode chunks via kmemdup() with GFP_ATOMIC as a precondition of wl->lock acquired. This caused allocation failures sometimes as reported in the bugzilla below. When looking at the the real usage, one can find that it's called solely from brcms_request_fw(), and it's obviously outside the lock. Hence we can use GFP_KERNEL there safely for avoiding such allocation errors. Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=1085174Signed-off-by:
Takashi Iwai <tiwai@suse.de> Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Arend Van Spriel authored
This field did not have kerneldoc description so adding it now. Signed-off-by:
-
Arend Van Spriel authored
The function was pretty minimal and now it is called only from one place so just get rid of it. Signed-off-by:
-
Arend Van Spriel authored
The function is no longer used so removing it. 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 authored
This changes the bus layer api by having the caller provide an extension. With this the callback can use brcmf_fw_alloc_request() to get the needed firmware name. Reviewed-by:
-
Arend Van Spriel authored
The function brcmf_fw_alloc_request() takes a list of required files and allocated the struct brcmf_fw_request instance accordingly. The request can be modified by the caller before being passed to the brcmf_fw_request_firmwares() function. Reviewed-by:
-
Arend Van Spriel authored
Make the function brcmf_fw_get_firmwares() a bit more easy to extend using a structure to pass the request parameters. Reviewed-by:
-
Arend Van Spriel authored
Instead of defining individual filenames for firmware and nvram use a basename and derive the names from that. Reviewed-by:
-
Arend Van Spriel authored
The driver used to create a brcmfmac dir entry at the top level debugfs mount point. This moves the debugfs entries into the wiphy debugfs dir entry. Reviewed-by:
-
Arend Van Spriel authored
Rework the driver so the wiphy instance holds the main driver information in its private buffer. Previously it held struct brcmf_cfg80211_info instance so a bit of reorg was needed. This was done so that the wiphy name or its parent device can be shown in debug output. Reviewed-by:
-
Arend Van Spriel authored
When logging the chip id/revision information make use of brcmf_chip_name() so it is always the same. Reviewed-by:
-
Arend Van Spriel authored
The chip id can either be four or five digits. For the chip name either the hexadecimal value needs to be taken (four digits) or the decimal value (five digits). The function brcmf_chip_name() does this conversion so use it to store the name in driver revision info. Reviewed-by:
-
Arend Van Spriel authored
In case of a linux error brcmf_fil_cmd_data() blurts an error message in which the error code is translated to an error string. However, it maps it to a firmware error string which should not happen. Simply print only the numeric error code and be done with it. Reviewed-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in RT_TRACE message text. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net? Signed-off-by:
-
Kevin Lo authored
Correct comment. Set bit 3 and bit 4 of 0x0005 register (REG_APS_FSMCO + 1) to 0 which means disable WL suspend, not enable WL suspend. Signed-off-by:
Kevin Lo <kevlo@kevlo.org> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
btcoex support multiple platforms, but this drivers doesn't support full functions yet, so this commit adds dummy definitions. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Ping-Ke Shih authored
New constant and variables definitions are used by btcoex of 8822b, so this commit add them. Signed-off-by:
-
Ping-Ke Shih authored
In connection notify v1, btcoex only need to know start/end association, and it will discriminate 2G and 5G band in v2. Signed-off-by:
-
Ping-Ke Shih authored
Normal LPS is decomposed into pre- and post- parts, so we can issue H2C with TDMA parameters in the "critical section" that dirver can't change LPS state at the moment. Signed-off-by:
-
Ping-Ke Shih authored
Get phydm's counter and version from the module phydm that is not submitted so we implement dummy functions. Signed-off-by:
-
Ping-Ke Shih authored
The btcoex use the rate to rsolve IOT issue that some APs reduce TX rate quickly, so it uses the RX rate as a clue to decide TDMA. Signed-off-by:
-
Ping-Ke Shih authored
btcoex does different decision according to MCC or SCC status, but driver is still SCC currently. Signed-off-by:
-
Ping-Ke Shih authored
Add customer_id field in structure, and then this is a clue to implement the behavior defined by vendor LENOVO_CHINA. Signed-off-by:
-
Ping-Ke Shih authored
btcoex uses dm's counters to check the environment is noisy or not. If it is clean, btcoex set more time slots to WiFi so that it can transmit as soon as possible. That will save time, and BT will have more time slots after WiFi traffic is complete. Signed-off-by:
-
Ping-Ke Shih authored
smatch reports "rtl_is_special_data() warn: inconsistent indenting", but it is an obvious redundant statement so remove it. Signed-off-by:
-
Ping-Ke Shih authored
sparse reports some functions were not declared, so add 'static' as modifier. Remove an unused function btc8821a1ant_is_wifi_status_changed() exposed due to 'static'. Signed-off-by:
-
Amitkumar Karwar authored
Following kernel panic is observed on 64bit machine while loading the driver. It is fixed if we pass dynamically allocated memory to SDIO for DMA. BUG: unable to handle kernel paging request at ffffeb04000172e0 IP: sg_miter_stop+0x56/0x70 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Modules linked in: rsi_sdio(OE+) rsi_91x(OE) btrsi(OE) rfcomm bluetooth ecdh_generic mac80211 mmc_block fuse xt_CHECKSUM iptable_mangle drm_kms_helper mmc_core serio_raw drm firewire_ohci tg3 CPU: 0 PID: 4003 Comm: insmod Tainted: G OE 4.16.0-rc1+ #27 Hardware name: Dell Inc. Latitude E5500 /0DW634, BIOS A19 06/13/2013 RIP: 0010:sg_miter_stop+0x56/0x70 RSP: 0018:ffff88007d003e78 EFLAGS: 00010002 RAX: 0000000000000003 RBX: 0000000000000004 RCX: 0000000000000000 RDX: ffffeb04000172c0 RSI: ffff88002f58002c RDI: ffff88007d003e80 RBP: 0000000000000004 R08: ffff88007d003e80 R09: 0000000000000008 R10: 0000000000000003 R11: 0000000000000001 R12: 0000000000000004 R13: ffff88002f580028 R14: 0000000000000000 R15: 0000000000000004 FS: 00007f35c29db700(0000) GS:ffff88007d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffeb04000172e0 CR3: 000000007038e000 CR4: 00000000000406f0 Call Trace: <IRQ> sg_copy_buffer+0xc6/0xf0 sdhci_tasklet_finish+0x170/0x260 [sdhci] tasklet_action+0xf4/0x100 __do_softirq+0xef/0x26e irq_exit+0xbe/0xd0 do_IRQ+0x4a/0xc0 common_interrupt+0xa2/0xa2 </IRQ> Signed-off-by:
Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by:
-
Amitkumar Karwar authored
We miss to release IRQ in certain error path in SDIO probe which causes following kernel panic. This patch corrects error path handling BUG: unable to handle kernel NULL pointer dereference at (null) IP: (null) PGD 0 P4D 0 Oops: 0010 [#1] SMP PTI Call Trace: <IRQ> ? call_timer_fn+0x29/0x120 ? run_timer_softirq+0x1da/0x420 ? timer_interrupt+0x11/0x20 ? __do_softirq+0xef/0x26e ? irq_exit+0xbe/0xd0 ? do_IRQ+0x4a/0xc0 ? common_interrupt+0xa2/0xa2 </IRQ> ? cpuidle_enter_state+0x118/0x250 ? do_idle+0x186/0x1e0 ? cpu_startup_entry+0x6f/0x80 ? start_kernel+0x47c/0x49c ? secondary_startup_64+0xa5/0xb0 Fixes: 50117605 ("rsi: improve RX handling in SDIO interface") Signed-off-by:
-
Colin Ian King authored
Variable buffer_size is re-assigned the same value, this duplicated assignment is redundant and can be removed. Cleans up clang warning: drivers/net/wireless/rsi/rsi_91x_usb.c:140:4: warning: Value stored to 'buffer_size' is never read Signed-off-by:
-
Tobin C. Harding authored
The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug (kernel Oops) or a security flaw (overwriting memory beyond the stack). Also, in general, as code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having runtime failures that are hard to debug. As part of the directive[1] to remove all VLAs from the kernel, and build with -Wvla. Currently rsi code uses a VLA based on a function argument to `rsi_sdio_load_data_master_write()`. The function call chain is Both these functions rsi_sdio_reinit_device() rsi_probe() start the call chain: rsi_hal_device_init() rsi_load_fw() auto_fw_upgrade() ping_pong_write() rsi_sdio_load_data_master_write() [Without familiarity with the code] it appears that none of the 4 locks mutex rx_mutex tx_mutex tx_bus_mutex are held when `rsi_sdio_load_data_master_write()` is called. It is therefore safe to use kmalloc with GFP_KERNEL. We can avoid using the VLA by using `kmalloc()` and free'ing the memory on all exit paths. Change buffer from 'u8 array' to 'u8 *'. Call `kmalloc()` to allocate memory for the buffer. Using goto statement to call `kfree()` on all return paths. It can be expected that this patch will result in a small increase in overhead due to the use of `kmalloc()` however this code is only called on initialization (and re-initialization) so this overhead should not degrade performance. [1] https://lkml.org/lkml/2018/3/7/621Signed-off-by:
Tobin C. Harding <me@tobin.cc> Signed-off-by:
-
Ganapathi Bhat authored
Fix the following sparse warning in mwifiex_cmd_append_11n_tlv: drivers/net/wireless/marvell/mwifiex/11n.c:358:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:358:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:358:65: right side has type int drivers/net/wireless/marvell/mwifiex/11n.c:360:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:360:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:360:65: right side has type int drivers/net/wireless/marvell/mwifiex/11n.c:366:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:366:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:366:65: right side has type int drivers/net/wireless/marvell/mwifiex/11n.c:368:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:368:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:368:65: right side has type int Fixes: 77423fa7 ("mwifiex: fix incorrect ht capability problem") Signed-off-by:
Ganapathi Bhat <gbhat@marvell.com> Signed-off-by:
-
Joe Perches authored
Prefer the direct use of octal for permissions. Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace and some typing. Miscellanea: o Whitespace neatening around these conversions. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Arnd Bergmann authored
The linkage between the bluetooth driver and the wireless driver is not defined properly, leading to build problems such as: warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X) drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt': (.text+0x205): undefined reference to `rsi_bt_ops' As the dependency is actually the reverse (RSI_91X uses the BT_RSI driver, not the other way round), this changes the dependency to match, and enables the bluetooth driver from the RSI_COEX symbol. Fixes: 38aa4da5 ("Bluetooth: btrsi: add new rsi bluetooth driver") Acked-by; Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for 4.17. Major changes: wil6210 * support multiple virtual interfaces
-
- 26 Mar, 2018 1 commit
-
-
Ramon Fried authored
IRQ reason was not cheked for errors. Although error handing is not currently supported, it will be nice to output an error value to the log if the DMA operation failed. Signed-off-by:
Ramon Fried <rfried@codeaurora.org> Signed-off-by:
-
