- 19 Sep, 2022 1 commit
-
-
Hector Martin authored
This binding is currently used for SDIO devices, but these chips are also used as PCIe devices on DT platforms and may be represented in the DT. Re-use the existing binding and add chip compatibles used by Apple T2 and M1 platforms (the T2 ones are not known to be used in DT platforms, but we might as well document them). Then, add properties required for firmware selection and calibration on M1 machines. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Hector Martin <marcan@marcan.st> Reviewed-by:
Mark Kettenis <kettenis@openbsd.org> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDnO-0077Zy-18@rmk-PC.armlinux.org.uk
-
- 12 Sep, 2022 16 commits
-
-
Bitterblue Smith authored
It looks like a leftover from copying rtl8xxxu_update_rate_mask, which is used with the gen1 chips. It wasn't causing any problems for my RTL8188FU test device, but it's clearly a mistake, so remove it. Fixes: f653e690 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function") Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by:
-
Bitterblue Smith authored
Found by comparing with the vendor driver. Currently this affects only the RTL8192EU, which is the only gen2 chip with 2 TX paths supported by this driver. It's unclear what kind of effect the mistake had in practice, since I don't have any RTL8192EU devices to test it. Fixes: e1547c53 ("rtl8xxxu: First stab at adding IQK calibration for 8723bu parts") Signed-off-by:
-
Po-Hao Huang authored
The size limit of H2C commands is 2048. With regulatory that enables U-NII-6 ~ UNII-8 channels, channel list length combining with channel info length will exceed that. Split the channel list to parts and do scan multiple times to workaround that. Signed-off-by:
Po-Hao Huang <phhuang@realtek.com> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Po-Hao Huang authored
This enables hw_scan function for 52c. The mechanism is similar to 52a except that it adds modifications required for 6G channels and extends the command length to make driver compatible to both newer and existing firmware. Signed-off-by:
-
Chin-Yen Lee authored
8852c transmits packets with slow response in deep ps mode, and lead to low throughput. We need to call tx_wake for each pakcet to trigger firmware wake earlier to avoid it. Signed-off-by:
Chin-Yen Lee <timlee@realtek.com> Signed-off-by:
-
Chin-Yen Lee authored
rtw8852c could support deep ps mode if the firmware version is greater than 0.17.34. Signed-off-by:
-
Chia-Yuan Li authored
With suitable response rate, it can acknowledge peer packets are received. Otherwise, peer could re-transmit again due to missing of ACK frames. To achieve this, refer to RX rate and CMAC table to choose the smaller as initial response rate. Signed-off-by:
Chia-Yuan Li <leo.li@realtek.com> Signed-off-by:
-
Yi-Tang Chiu authored
With one path TX for 1SS rate, it can transmit higher power in 6GHz band to yield better performance in high attenuation circumstance. Signed-off-by:
Yi-Tang Chiu <chiuyitang@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
The range of calibration time of RX DCK is quite wide from ~40us to ~1300us by experiments, and probability is about 0.1% for the cases larger than 1000us. Though it can retry calibration and get positive result, it will spend more time. Therefore, enlarge it to avoid warning and duplicate calibration. Signed-off-by:
-
Ping-Ke Shih authored
Enable MU-MIMO interference cancellation (MUIC) to yield expected performance of receiving MU-MIMO packets on 6GHz. Signed-off-by:
-
Eric Huang authored
Since control register address for DIG are different per IC, add a new struct rtw89_dig_regs in chip info for each IC to define their own address. Signed-off-by:
Eric Huang <echuang@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
Check RSSI strength to decide which path is better, and then set TX path accordingly. Signed-off-by:
-
Ping-Ke Shih authored
Originally, we show average signal strength. To support TX diversity, this patch prepares strength per path, then we can decide TX path. RSSI: -54 dBm (raw=112, prev=110) [-57, -52] Signed-off-by:
-
Ping-Ke Shih authored
In order to support TX diversity, add a function to control TX path. Signed-off-by:
-
Ping-Ke Shih authored
Two fields, TX/RX ANT NUM, are introduced to address variant TX/RX antenna number of hardware. For example, a 1x1 chip with TX diversity, TX NSS = 1 and TX/RX ANT NUM = 2. Signed-off-by:
-
Ping-Ke Shih authored
The definitions of bit fields in structure will be wrong in big-endian platform, so use u32_get_bits() to access them. Signed-off-by:
-
- 07 Sep, 2022 20 commits
-
-
Johannes Berg authored
There's a TODO here, just move the dependency on phy->rev into the comment. Not that this driver is likely to get any updates. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
Instead of the code here that copies into a variable first and then flips endianness, which confuses sparse, just directly use get_unaligned_le64(). Signed-off-by:
-
Johannes Berg authored
We can call this in one of two ways: through mac80211, where we're already in an RCU read-side critical section, or from some other code in the driver where this pointer can only be NULL. In any case, we get a 'free' already protected pointer to the sta through info->control.sta, so we can use it on the stack without any further protection. Remove the rcu_dereference() and critical section. Signed-off-by:
-
Johannes Berg authored
These cause sparse warnings, and since the device generally works in little endian we can assume the code is correct, so just fix the casts accordingly. No binary changes on x86. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Johannes Berg authored
Clearly the value should be converted and then compared, not the result of the comparison be converted. No binary changes on x86. Signed-off-by:
-
Johannes Berg authored
We need to read a value from the device to wake it, but if it succeeds we don't really care about it. Mark the variable to avoid a compiler warning. Signed-off-by:
-
Johannes Berg authored
This caused sparse warnings, and clearly is needed per how other firmware interfaces behave. Signed-off-by:
-
Johannes Berg authored
- endian swapping is required in one place, use the already swapped 'bsssize' local - lbs_disablemesh need not be exported and can be static Signed-off-by:
-
Johannes Berg authored
Just remove the extra asterisk to make it not be kernel-doc formatted. Signed-off-by:
-
Bitterblue Smith authored
rtl8xxxu_queue_select() selects the wrong TX queues because it's reading memory from the wrong address. It expects to find ieee80211_hdr at skb->data, but that's not the case after skb_push(). Move the call to rtl8xxxu_queue_select() before the call to skb_push(). Fixes: 26f1fad2 ("New driver: rtl8xxxu (mac80211)") Signed-off-by:
-
Jinpeng Cui authored
Return value from brcmf_fil_iovar_data_set() and brcmf_config_ap_mgmt_ie() directly instead of taking this in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Jinpeng Cui <cui.jinpeng2@zte.com.cn> Signed-off-by:
-
Marek Vasut authored
Add HW and SDIO ids for use with the muRata 1YN (Cypress CYW43439). Add the firmware mapping structures for the CYW43439 chipset. The 43439 needs some things setup similar to the 43430 chipset. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Zheyu Ma authored
Since the logic of the driver's error handling code has changed, the previous dead store and checks are not needed. Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
-
Shaomin Deng authored
Remove the repeated word "registers" in comments. Signed-off-by:
Shaomin Deng <dengshaomin@cdjrlc.com> Signed-off-by:
-
Jason Wang authored
The double `to' is duplicated in the comment, remove one. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Acked-by:
Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
-
Jason Wang authored
The double `the' is duplicated in the comment, remove one. Signed-off-by:
-
Hans de Goede authored
The Chuwi Hi8 Pro tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: "brcmfmac43430a0-sdio.Default string-Default string.txt" as nvram file which is way too generic. The Chuwi Hi8 Pro uses the same Ampak AP6212 module as the Chuwi Vi8 Plus and the nvram for the Vi8 Plus is already in linux-firmware, so point the new DMI nvram filename quirk to the Vi8 Plus nvram file. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
Many devices ship with a nvram ccode value of X2/XT/XU/XV/ALL which are all special world-wide compatibility ccode-s. Most of these world-wide ccode-s allow passive scan mode only for 2.4GHz channels 12-14, only enabling them when an AP is seen on them. Since linux-firmware has moved to the new cyfmac43430-sdio.bin + cyfmac43430-sdio.clm_blob firmware files this no longer works and 43430 devices using e.g. an X2 ccode fail to connect to an AP on channel 13. Add the 43430 chip-id to the list of chips for which to use the ISO3166 country code + rev 0 as fallback in brcmf_translate_country_code() to fix this. Signed-off-by:
-
Alexander Coffin authored
> ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb); may be schedule, and then complete before the line > ndev->stats.tx_bytes += skb->len; [ 46.912801] ================================================================== [ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328 [ 46.935991] [ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1 [ 46.947255] Hardware name: [REDACTED] [ 46.954568] Call trace: [ 46.957037] dump_backtrace+0x0/0x2b8 [ 46.960719] show_stack+0x24/0x30 [ 46.964052] dump_stack+0x128/0x194 [ 46.967557] print_address_description.isra.0+0x64/0x380 [ 46.972877] __kasan_report+0x1d4/0x240 [ 46.976723] kasan_report+0xc/0x18 [ 46.980138] __asan_report_load4_noabort+0x18/0x20 [ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.990613] dev_hard_start_xmit+0x1bc/0xda0 [ 46.994894] sch_direct_xmit+0x198/0xd08 [ 46.998827] __qdisc_run+0x37c/0x1dc0 [ 47.002500] __dev_queue_xmit+0x1528/0x21f8 [ 47.006692] dev_queue_xmit+0x24/0x30 [ 47.010366] neigh_resolve_output+0x37c/0x678 [ 47.014734] ip_finish_output2+0x598/0x2458 [ 47.018927] __ip_finish_output+0x300/0x730 [ 47.023118] ip_output+0x2e0/0x430 [ 47.026530] ip_local_out+0x90/0x140 [ 47.030117] igmpv3_sendpack+0x14c/0x228 [ 47.034049] igmpv3_send_cr+0x384/0x6b8 [ 47.037895] igmp_ifc_timer_expire+0x4c/0x118 [ 47.042262] call_timer_fn+0x1cc/0xbe8 [ 47.046021] __run_timers+0x4d8/0xb28 [ 47.049693] run_timer_softirq+0x24/0x40 [ 47.053626] __do_softirq+0x2c0/0x117c [ 47.057387] irq_exit+0x2dc/0x388 [ 47.060715] __handle_domain_irq+0xb4/0x158 [ 47.064908] gic_handle_irq+0x58/0xb0 [ 47.068581] el0_irq_naked+0x50/0x5c [ 47.072162] [ 47.073665] Allocated by task 328: [ 47.077083] save_stack+0x24/0xb0 [ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0 [ 47.084776] kasan_slab_alloc+0x14/0x20 [ 47.088622] kmem_cache_alloc+0x15c/0x468 [ 47.092643] __alloc_skb+0xa4/0x498 [ 47.096142] igmpv3_newpack+0x158/0xd78 [ 47.099987] add_grhead+0x210/0x288 [ 47.103485] add_grec+0x6b0/0xb70 [ 47.106811] igmpv3_send_cr+0x2e0/0x6b8 [ 47.110657] igmp_ifc_timer_expire+0x4c/0x118 [ 47.115027] call_timer_fn+0x1cc/0xbe8 [ 47.118785] __run_timers+0x4d8/0xb28 [ 47.122457] run_timer_softirq+0x24/0x40 [ 47.126389] __do_softirq+0x2c0/0x117c [ 47.130142] [ 47.131643] Freed by task 180: [ 47.134712] save_stack+0x24/0xb0 [ 47.138041] __kasan_slab_free+0x108/0x180 [ 47.142146] kasan_slab_free+0x10/0x18 [ 47.145904] slab_free_freelist_hook+0xa4/0x1b0 [ 47.150444] kmem_cache_free+0x8c/0x528 [ 47.154292] kfree_skbmem+0x94/0x108 [ 47.157880] consume_skb+0x10c/0x5a8 [ 47.161466] __dev_kfree_skb_any+0x88/0xa0 [ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil] [ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac] [ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac] [ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac] [ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac] [ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac] [ 47.197859] process_one_work+0x7fc/0x1a80 [ 47.201965] worker_thread+0x31c/0xc40 [ 47.205726] kthread+0x2d8/0x370 [ 47.208967] ret_from_fork+0x10/0x18 [ 47.212546] [ 47.214051] The buggy address belongs to the object at ffffff803f588280 [ 47.214051] which belongs to the cache skbuff_head_cache of size 208 [ 47.227086] The buggy address is located 104 bytes inside of [ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350) [ 47.238814] The buggy address belongs to the page: [ 47.243618] page:ffffffff00dd6200 refcount:1 mapcount:0 mapping:ffffff804b6bf800 index:0xffffff803f589900 compound_mapcount: 0 [ 47.255007] flags: 0x10200(slab|head) [ 47.258689] raw: 0000000000010200 ffffffff00dfa980 0000000200000002 ffffff804b6bf800 [ 47.266439] raw: ffffff803f589900 0000000080190018 00000001ffffffff 0000000000000000 [ 47.274180] page dumped because: kasan: bad access detected [ 47.279752] [ 47.281251] Memory state around the buggy address: [ 47.286051] ffffff803f588180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 47.293277] ffffff803f588200: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 47.300502] >ffffff803f588280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 47.307723] ^ [ 47.314343] ffffff803f588300: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc [ 47.321569] ffffff803f588380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb [ 47.328789] ================================================================== Signed-off-by:
Alexander Coffin <alex.coffin@matician.com> Signed-off-by:
-
Kees Cook authored
In preparation for FORTIFY_SOURCE performing run-time destination buffer bounds checking for memcpy(), refactor the use of struct iwl_calib_result: - Have struct iwl_calib_result contain struct iwl_calib_cmd since functions expect to operate on the "data" flex array in "cmd", which follows the "hdr" member. - Switch argument passing around to use struct iwl_calib_cmd instead of struct iwl_calib_hdr to prepare functions to see the "data" member. - Change iwl_calib_set()'s "len" argument to a size_t since it is always unsigned and is normally receiving the output of sizeof(). - Add an explicit length sanity check in iwl_calib_set(). - Adjust the memcpy() to avoid copying across the now visible composite flex array structure. This avoids the future run-time warning: memcpy: detected field-spanning write (size 8) of single field "&res->hdr" (size 4) Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Johannes Berg <johannes.berg@intel.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Reported-by:
Andy Lavr <andy.lavr@gmail.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
- 06 Sep, 2022 3 commits
-
-
Johannes Berg authored
One of my previous patches here changed the function prototype, but since it was (half?) automated, I didn't update the docs. Fix that now. Fixes: b3e2130b ("wifi: mac80211: change QoS settings API to take link into account") Signed-off-by:
-
Johannes Berg authored
By default, even in client mode, hwsim always had all links active, where it then uses them in a round-robin fashion. Re-enable that by activating all valid links work right after the connection is authorized. Signed-off-by: -
Johannes Berg authored
Implement an API function and debugfs file to switch active links. Also provide an async version of the API so drivers can call it in arbitrary contexts, e.g. while in the authorized callback. Signed-off-by:
-
