When doing the PLDR flow, the fw goes through a re-read and needs
PCI re-enumeration in order to recover. In this case, skip the mac
start retry and fw dumps as all the fw and registers are invalid
until the PCI re-enumeration.

In addition, print the register that shows the re-read counter
when loading the fw.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Link: https://lore.kernel.org/r/20221123225313.9ae77968961e.Ie06e886cef4b5921b65dacb7724db1276bed38cb@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

We see kernel crashes and lockups and KASAN errors related to ax210
firmware crashes.  One of the KASAN dumps pointed at the tx path,
and it appears there is indeed a way to double-free an skb.

If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the
method will be freed.  But, in case where we build TSO skb buffer,
the skb may also be freed in error case.  So, return 0 in that particular
error case and do cleanup manually.

BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90
iwlwifi 0000:06:00.0: 0x00000000 | tsf hi
Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650

CPU: 4 PID: 9650 Comm: btserver Tainted: G        W         5.19.8+ #5
iwlwifi 0000:06:00.0: 0x00000000 | time gp1
Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019
Call Trace:
 <TASK>
 dump_stack_lvl+0x55/0x6d
 print_report.cold.12+0xf2/0x684
iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2
 ? __list_del_entry_valid+0x12/0x90
 kasan_report+0x8b/0x180
iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type
 ? __list_del_entry_valid+0x12/0x90
 __list_del_entry_valid+0x12/0x90
iwlwifi 0000:06:00.0: 0x00000048 | uCode version major
 tcp_update_skb_after_send+0x5d/0x170
 __tcp_transmit_skb+0xb61/0x15c0
iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor
 ? __tcp_select_window+0x490/0x490
iwlwifi 0000:06:00.0: 0x00000420 | hw version
 ? trace_kmalloc_node+0x29/0xd0
 ? __kmalloc_node_track_caller+0x12a/0x260
 ? memset+0x1f/0x40
 ? __build_skb_around+0x125/0x150
 ? __alloc_skb+0x1d4/0x220
 ? skb_zerocopy_clone+0x55/0x230
iwlwifi 0000:06:00.0: 0x00489002 | board version
 ? kmalloc_reserve+0x80/0x80
 ? rcu_read_lock_bh_held+0x60/0xb0
 tcp_write_xmit+0x3f1/0x24d0
iwlwifi 0000:06:00.0: 0x034E001C | hcmd
 ? __check_object_size+0x180/0x350
iwlwifi 0000:06:00.0: 0x24020000 | isr0
 tcp_sendmsg_locked+0x8a9/0x1520
iwlwifi 0000:06:00.0: 0x01400000 | isr1
 ? tcp_sendpage+0x50/0x50
iwlwifi 0000:06:00.0: 0x48F0000A | isr2
 ? lock_release+0xb9/0x400
 ? tcp_sendmsg+0x14/0x40
iwlwifi 0000:06:00.0: 0x00C3080C | isr3
 ? lock_downgrade+0x390/0x390
 ? do_raw_spin_lock+0x114/0x1d0
iwlwifi 0000:06:00.0: 0x00200000 | isr4
 ? rwlock_bug.part.2+0x50/0x50
iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id
 ? rwlock_bug.part.2+0x50/0x50
 ? lockdep_hardirqs_on_prepare+0xe/0x200
iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event
 ? __local_bh_enable_ip+0x87/0xe0
 ? inet_send_prepare+0x220/0x220
iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control
 tcp_sendmsg+0x22/0x40
 sock_sendmsg+0x5f/0x70
iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration
 __sys_sendto+0x19d/0x250
iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid
 ? __ia32_sys_getpeername+0x40/0x40
iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match
 ? rcu_read_lock_held_common+0x12/0x50
 ? rcu_read_lock_sched_held+0x5a/0xd0
 ? rcu_read_lock_bh_held+0xb0/0xb0
 ? rcu_read_lock_sched_held+0x5a/0xd0
 ? rcu_read_lock_sched_held+0x5a/0xd0
 ? lock_release+0xb9/0x400
 ? lock_downgrade+0x390/0x390
 ? ktime_get+0x64/0x130
 ? ktime_get+0x8d/0x130
 ? rcu_read_lock_held_common+0x12/0x50
 ? rcu_read_lock_sched_held+0x5a/0xd0
 ? rcu_read_lock_held_common+0x12/0x50
 ? rcu_read_lock_sched_held+0x5a/0xd0
 ? rcu_read_lock_bh_held+0xb0/0xb0
 ? rcu_read_lock_bh_held+0xb0/0xb0
 __x64_sys_sendto+0x6f/0x80
 do_syscall_64+0x34/0xb0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f1d126e4531
Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89
RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 000000000000ffdc RCX: 00007f1d126e4531
RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014
RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000010
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000
 </TASK>

Allocated by task 9650:
 kasan_save_stack+0x1c/0x40
 __kasan_slab_alloc+0x6d/0x90
 kmem_cache_alloc_node+0xf3/0x2b0
 __alloc_skb+0x191/0x220
 tcp_stream_alloc_skb+0x3f/0x330
 tcp_sendmsg_locked+0x67c/0x1520
 tcp_sendmsg+0x22/0x40
 sock_sendmsg+0x5f/0x70
 __sys_sendto+0x19d/0x250
 __x64_sys_sendto+0x6f/0x80
 do_syscall_64+0x34/0xb0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Freed by task 9650:
 kasan_save_stack+0x1c/0x40
 kasan_set_track+0x21/0x30
 kasan_set_free_info+0x20/0x30
 __kasan_slab_free+0x102/0x170
 kmem_cache_free+0xc8/0x3e0
 iwl_mvm_mac_itxq_xmit+0x124/0x270 [iwlmvm]
 ieee80211_queue_skb+0x874/0xd10 [mac80211]
 ieee80211_xmit_fast+0xf80/0x1180 [mac80211]
 __ieee80211_subif_start_xmit+0x287/0x680 [mac80211]
 ieee80211_subif_start_xmit+0xcd/0x730 [mac80211]
 dev_hard_start_xmit+0xf6/0x420
 __dev_queue_xmit+0x165b/0x1b50
 ip_finish_output2+0x66e/0xfb0
 __ip_finish_output+0x487/0x6d0
 ip_output+0x11c/0x350
 __ip_queue_xmit+0x36b/0x9d0
 __tcp_transmit_skb+0xb35/0x15c0
 tcp_write_xmit+0x3f1/0x24d0
 tcp_sendmsg_locked+0x8a9/0x1520
 tcp_sendmsg+0x22/0x40
 sock_sendmsg+0x5f/0x70
 __sys_sendto+0x19d/0x250
 __x64_sys_sendto+0x6f/0x80
 do_syscall_64+0x34/0xb0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

The buggy address belongs to the object at ffff88813cfa4b40
 which belongs to the cache skbuff_fclone_cache of size 472
The buggy address is located 96 bytes inside of
 472-byte region [ffff88813cfa4b40, ffff88813cfa4d18)

The buggy address belongs to the physical page:
page:ffffea0004f3e900 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813cfa6c40 pfn:0x13cfa4
head:ffffea0004f3e900 order:2 compound_mapcount:0 compound_pincount:0
flags: 0x5fff8000010200(slab|head|node=0|zone=2|lastcpupid=0x3fff)
raw: 005fff8000010200 ffffea0004656b08 ffffea0008e8cf08 ffff8881081a5240
raw: ffff88813cfa6c40 0000000000170015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88813cfa4a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88813cfa4b00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
>ffff88813cfa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                               ^
 ffff88813cfa4c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88813cfa4c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Fixes: 08f7d8b6 ("iwlwifi: mvm: bring back mvm GSO code")
Link: https://lore.kernel.org/linux-wireless/20220928193057.16132-1-greearb@candelatech.com/Tested-by: NAmol Jawale <amol.jawale@candelatech.com>
Signed-off-by: NBen Greear <greearb@candelatech.com>
Link: https://lore.kernel.org/r/20221123225313.21b1ee31d666.I3b3ba184433dd2a544d91eeeda29b467021824ae@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

These are register values which are needed for debug regardless of alive
fail/success.
Signed-off-by: NDaniel Gabay <daniel.gabay@intel.com>
Link: https://lore.kernel.org/r/20221123225313.a5ae3679491b.Ic618934df084a9b269e56d892665523c79e40eee@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

Update EHT MAC and PHY capabilities for GL device
for station and softap interface.
Add relevant code in nvm_fixup_sband_iftd.
Signed-off-by: NAbhishek Naik <abhishek.naik@intel.com>
Link: https://lore.kernel.org/r/20221122220713.1da816ab7ffc.Ief570e27007c9e2ad3a97bee4b074e2fc1c75bae@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

We support large A-MPDU in EHT in 2.4 GHz, so add the right
bits for that in the EHT capabilities.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/r/20221122220713.3e7449760415.Id394d7fd0acaca48d429feccda4e66dbadaab993@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

We can't have it in AP mode unless for debug, since we don't have
160 MHz in HE PHY capabilities, and also set it only in 6 GHz even
if (unlike in HE) it's always defined.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/r/20221122220713.293ef3e5a1c4.I867526a6bd3f93ee50076ff359436dfb5ec6101c@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

The bits are reserved on the opposite bands, so we shouldn't
always send them, only the 2G bit on 2.4 GHz and the 5G bits
on 5/6GHz. Fix that.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/r/20221122220713.0a075d00c796.Ib4cac0b7f90dfadebceceb1e07c8cdfd7a4138f6@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

In an EHT connection fill in the HE context command
with PPE Thresholds field from EHT Capabilities IE.
If PPE Thresholds field presents only in HE Capabilities IE,
take the thresholds from there.
If it's not present in both - set the Common Nominal Packet Padding
field from EHT Capabilities IE.
Signed-off-by: NMiri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://lore.kernel.org/r/20221122220713.062ac86110f2.I0bcd5ee35f4d987a49f15501985f90e0d3ce7590@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

In 11be we can receive 1K aggregation size so update our max HW rx
aggregation for mac80211 usage.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Link: https://lore.kernel.org/r/20221122220713.ef0431f64975.Ie4d90c376c822694f4523ff0fb5731f20004c24d@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

Rate scale needs to be configured to what MCS it can use per BW and NSS,
this is done by parsing our capabilities of TX and peer's capabilities of
RX and setting the minimum for rate scale usage.

Also do some cleanup removing redundant enum defines not used by
FW/Driver.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Link: https://lore.kernel.org/r/20221122220713.f71f3b4c4583.I7b5e8071df91146c4bee3e9bcb7ad62595b275e1@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

Support 320 MHz PHY configuration and while doing so rewrite
the code since we'd otherwise double the number of cases in
the switch statement.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/r/20221122220713.964db911b733.If56c94a9bf20c050f35d2421b680e400a9f4aeb8@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

Add support for advertising EHT capabilities if supported by
device SKU and not disabled by module parameters.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Link: https://lore.kernel.org/r/20221122220713.6bc00d851794.I214005645f3da21d8f2458a70355deeca04a19e8@changeidSigned-off-by: NGregory Greenman <gregory.greenman@intel.com>

For SDIO/USB interface, since the tranferring speed is slower than
that in PCIE, it may have race condition when the driver sets down
H2C command to the FW.

In the function rtw_fw_send_h2c_command, before the patch, box_reg
is written first, then box_ex_reg is written. FW starts to work and
fetch the value of box_ex_reg,  when the most significant byte of
box_reg(4 bytes) is written. Meanwhile, for SDIO/USB interface,
since the transferring speed is slow, the driver is still in writing
the new value of box_ex_reg through the bus, and FW may get the
wrong value of box_ex_reg at the moment.

To prevent the above driver/FW racing situation, box_ex_reg is
written first then box_reg. Furthermore, it is written in 4 bytes at
a time, instead of written in one byte one by one. It can increase
the speed for SDIO/USB interface.
Signed-off-by: NJi-Pin Jou <neo_jou@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221124064442.28042-1-pkshih@realtek.com

Commit 399500da ("ssb: pick PCMCIA host code support from b43 driver")
removes the config B43_PCMCIA.

Clean up the last reference to this removed config B43_PCMCIA in the
b43_print_driverinfo() function.
Signed-off-by: NLukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221122131248.23738-1-lukas.bulwahn@gmail.com

Commit a8b5aef2 ("wifi: rtl8xxxu: gen2: Enable 40 MHz channel width")
introduced a line where the pointer returned by ieee80211_find_sta() is
used after rcu_read_unlock().

Move rcu_read_unlock() a bit lower to fix this.

Fixes: a8b5aef2 ("wifi: rtl8xxxu: gen2: Enable 40 MHz channel width")
Signed-off-by: NBitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/3c82ad09-7593-3be1-1d2c-e58505fb43cb@gmail.com

urbs does not be freed in exception paths in __lf_x_usb_enable_rx().
That will trigger memory leak. To fix it, add kfree() for urbs within
"error" label. Compile tested only.

Fixes: 68d57a07 ("wireless: add plfxlc driver for pureLiFi X, XL, XC devices")
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221119051900.1192401-1-william.xuanziyang@huawei.com

Zero-length arrays are deprecated[1] and are being replaced with
flexible array members in support of the ongoing efforts to tighten the
FORTIFY_SOURCE routines on memcpy(), correctly instrument array indexing
with UBSAN_BOUNDS, and to globally enable -fstrict-flex-arrays=3.

Replace zero-length array with flexible-array member.

This results in no differences in binary output.

[1] https://github.com/KSPP/linux/issues/78

Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Kalle Valo <kvalo@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: NChristian Lamparter <chunkeey@gmail.com>
Signed-off-by: NKalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221118211146.never.395-kees@kernel.org

In a SoC based solution, it would be useful to know the versions of the
various binary firmware blobs the system is running on. On a QCOM based
SoC, this info can be obtained from socinfo debugfs infrastructure. For
this to work, respective subsystem drivers have to export the firmware
version information to an SMEM based version information table.

Having firmware version information at one place will help quickly
figure out the firmware versions of various subsystems on the device
instead of going through builds/logs in an event of a system crash.

Fill WLAN firmware version information in SMEM version table to be
printed as part of socinfo debugfs infrastructure on a Qualcomm based
SoC.

This change is applicable only for SNOC/QMI based targets.

Example:
cat /sys/kernel/debug/qcom_socinfo/cnss/name
QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
Signed-off-by: NYoughandhar Chintala <quic_youghand@quicinc.com>
Signed-off-by: NKalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221117180534.2267-1-quic_youghand@quicinc.com

Zero-length arrays are deprecated[1] and are being replaced with
flexible array members in support of the ongoing efforts to tighten the
FORTIFY_SOURCE routines on memcpy(), correctly instrument array indexing
with UBSAN_BOUNDS, and to globally enable -fstrict-flex-arrays=3.

Replace zero-length array with flexible-array member.

This results in no differences in binary output (most especially because
struct pda_antenna_gain is unused). The struct is kept for future
reference.

[1] https://github.com/KSPP/linux/issues/78

Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Kalle Valo <kvalo@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>
Acked-by: NChristian Lamparter <chunkeey@gmail.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221118234240.gonna.369-kees@kernel.org

The index RTW89_PHYSTS_BITMAP_NUM is not a valid physts IE page.
So, fix the check condition.

Fixes: eb4e52b3 ("rtw89: fix incorrect channel info during scan")
Signed-off-by: NZong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221118042322.26794-1-pkshih@realtek.com

During doing change_interface(), hardware is power-off, so some components
are inaccessible and return error. This causes things unexpected, and we
don't have a warning message for that. So, ignore some IO operations in
this situation, and add a warning message to indicate something wrong.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221117085235.53777-1-pkshih@realtek.com

There are some registers for transmit waveform control, two of them used
in this change are for BANDEDGE and TX_SHAPE control. BANDEDGE controls
whether to apply band edge filter to transmit waveform. TX_SHAPE controls
whether to apply triangular mask to transmit waveform. It is found for
some chip, these two should be turned off during OFDMA UL traffic for
better performance.
Signed-off-by: NEric Huang <echuang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221117063001.42967-3-pkshih@realtek.com

Add macro to get FD(frequency domain) CFO field from ie_type 1, and correct
the naming for preamble CFO field. Each IC could assign the CFO source to
either FD CFO or preamble CFO in chip_info. Based on the suggestion from HW
designer, rtw8852b and its derived versions will have better CFO tracking
performance with FD CFO.
Signed-off-by: NEric Huang <echuang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221117063001.42967-2-pkshih@realtek.com

When coexistence mechanism is under free-run mode, it could adjust WiFi
and BT TX power to avoid interference with each other. For other cases,
it should keep original TX power from regular predefined tables, so
set correct values to 255 for these cases.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221117061832.42057-1-pkshih@realtek.com

Prefer struct_size() over open-coded versions of idiom:

sizeof(struct-with-flex-array) + sizeof(typeof-flex-array-elements) * count

where count is the max number of items the flexible array is supposed to
contain.

In this particular case, in the open-coded version sizeof(typeof-flex-array-elements)
is implicit in _count_ because the type of the flex array data is u8:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h:941:
 941 struct brcmf_dload_data_le {
 942         __le16 flag;
 943         __le16 dload_type;
 944         __le32 len;
 945         __le32 crc;
 946         u8 data[];
 947 };

Link: https://github.com/KSPP/linux/issues/160Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/41845ad3660ed4375f0c03fd36a67b2e12fafed5.1668548907.git.gustavoars@kernel.org

One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct brcmf_dload_data_le.

Important to mention is that doing a build before/after this patch results
in no binary output differences.

This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines
on memcpy() and help us make progress towards globally enabling
-fstrict-flex-arrays=3 [1].

Link: https://github.com/KSPP/linux/issues/230
Link: https://github.com/KSPP/linux/issues/79
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/905f5b68cf93c812360d081caae5b15221db09b6.1668548907.git.gustavoars@kernel.org

Prefer struct_size() over open-coded versions of idiom:

sizeof(struct-with-flex-array) + sizeof(typeof-flex-array-elements) * count

where count is the max number of items the flexible array is supposed to
contain.

Also, use array_size() in call to memcpy().

Link: https://github.com/KSPP/linux/issues/160Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/de0226a549c8d000d8974e207ede786220a3df1a.1668466470.git.gustavoars@kernel.org

One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct brcmf_gscan_config.

Important to mention is that doing a build before/after this patch results
in no binary output differences.

This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines
on memcpy() and help us make progress towards globally enabling
-fstrict-flex-arrays=3 [1].

Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/241
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/7694550aa9a2753a73a687f61af9441c8cf52fd7.1668466470.git.gustavoars@kernel.org

This argument of ath10k_htt_rx_h_frag_pn_check() is always set to 0 so
drop this.
Signed-off-by: NZhi-Jun You <hujy652@gmail.com>
Signed-off-by: NKalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221110164025.14418-1-hujy652@gmail.com

This driver is attempting to register to support two different buses.
if either of these is successful then ath10k_pci_init() should return 0
so that hardware attached to the successful bus can be probed and
supported. only if both of these are unsuccessful should ath10k_pci_init()
return an errno.

Fixes: 0b523ced ("ath10k: add basic skeleton to support ahb")
Signed-off-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Reviewed-by: NJeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: NKalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221110061926.18163-1-xiujianfeng@huawei.com

Switch the driver from legacy gpio API to the newer gpiod API.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221109224250.2885119-3-dmitry.torokhov@gmail.com

Remove support for configuring the device via platform data because
there are no users of wl1251_platform_data left in the mainline kernel.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221109224250.2885119-2-dmitry.torokhov@gmail.com

'ret' is not updated after a function call in rtw89_core_sta_assoc().
This prevent error handling from working.

Add the missing assignment.

Fixes: e3ec7017 ("rtw89: add Realtek 802.11ax driver")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/7b1d82594635e4406d3438f33d8da29eaa056c5a.1668354547.git.christophe.jaillet@wanadoo.fr

'ret' is not updated after several function calls in rtw89_wow_enable().
This prevent error handling from working.

Add the missing assignments.

Fixes: 19e28c7f ("wifi: rtw89: add WoWLAN function support")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/32320176eeff1c635baeea25ef0e87d116859e65.1668354083.git.christophe.jaillet@wanadoo.fr

When built with Control Flow Integrity, function prototypes between
caller and function declaration must match. These mismatches are visible
at compile time with the new -Wcast-function-type-strict in Clang[1].

Fix a total of 32 warnings like these:

../drivers/net/wireless/cisco/airo.c:7570:2: warning: cast from 'int (*)(struct net_device *, struct iw_request_info *, void *, char *)' to 'iw_handler' (aka 'int (*)(struct net_device *, struct iw_request_info *, union iwreq_data *, char *)') converts to incompatible function type [-Wcast-function-type-strict]
        (iw_handler) airo_config_commit,        /* SIOCSIWCOMMIT */
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The airo Wireless Extension handler callbacks (iw_handler) use a
union for the data argument. Actually use the union and perform explicit
member selection in the function body instead of having a function
prototype mismatch. There are no resulting binary differences
before/after changes.

These changes were made partly manually and partly with the help of
Coccinelle.

Link: https://github.com/KSPP/linux/issues/236
Link: https://reviews.llvm.org/D134831 [1]
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/820abf91d12809904696ddb8925ec5e1e0da3e4c.1667934775.git.gustavoars@kernel.org

When built with Control Flow Integrity, function prototypes between
caller and function declaration must match. These mismatches are visible
at compile time with the new -Wcast-function-type-strict in Clang[1].

Fix a total of 30 warnings like these:

../drivers/net/wireless/zydas/zd1201.c:1560:2: warning: cast from 'int (*)(struct net_device *, struct iw_request_info *, struct iw_freq *, char *)' to 'iw_handler' (aka 'int (*)(struct net_device *, struct iw_request_info *, union iwreq_data *, char *)') converts to incompatible function type [-Wcast-function-type-strict]
        (iw_handler) zd1201_set_freq,           /* SIOCSIWFREQ */
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

The zd1201 Wireless Extension handler callbacks (iw_handler) use a
union for the data argument. Actually use the union and perform explicit
member selection in the function body instead of having a function
prototype mismatch.There are no resulting binary differences
before/after changes.

These changes were made partly manually and partly with the help of
Coccinelle.

Link: https://github.com/KSPP/linux/issues/233
Link: https://reviews.llvm.org/D134831 [1]
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/5b7fbb1a22d5bfaa872263ca20297de9b431d1ec.1667934775.git.gustavoars@kernel.org

When built with Control Flow Integrity, function prototypes between
caller and function declaration must match. These mismatches are visible
at compile time with the new -Wcast-function-type-strict in Clang[1].

Fix a total of 42 warnings like these:

../drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3868:2: warning: cast from 'int (*)(struct net_device *, struct iw_request_info *, char *, char *)' to 'iw_handler' (aka 'int (*)(struct net_device *, struct iw_request_info *, union iwreq_data *, char *)') converts to incompatible function type [-Wcast-function-type-strict]
        (iw_handler) prism2_get_name,                   /* SIOCGIWNAME */
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

The hostap Wireless Extension handler callbacks (iw_handler) use a
union for the data argument. Actually use the union and perform explicit
member selection in the function body instead of having a function
prototype mismatch. There are no resulting binary differences
before/after changes.

These changes were made partly manually and partly with the help of
Coccinelle.

Link: https://github.com/KSPP/linux/issues/235
Link: https://reviews.llvm.org/D134831 [1]
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/e480e7713f1a4909ae011068c8d793cc4a638fbd.1667934775.git.gustavoars@kernel.org

When built with Control Flow Integrity, function prototypes between
caller and function declaration must match. These mismatches are visible
at compile time with the new -Wcast-function-type-strict in Clang[1].

Fix a total of 73 warnings like these:

drivers/net/wireless/intersil/orinoco/wext.c:1379:27: warning: cast from 'int (*)(struct net_device *, struct iw_request_info *, struct iw_param *, char *)' to 'iw_handler' (aka 'int (*)(struct net_device *, struct iw_request_info *, union iwreq_data *, char *)') converts to incompatible function type [-Wcast-function-type-strict]
        IW_HANDLER(SIOCGIWPOWER,        (iw_handler)orinoco_ioctl_getpower),
                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

../net/wireless/wext-compat.c:1607:33: warning: cast from 'int (*)(struct net_device *, struct iw_request_info *, struct iw_point *, char *)' to 'iw_handler' (aka 'int (*)(struct net_device *, struct iw_request_info *, union iwreq_data *, char *)') converts to incompatible function type [-Wcast-function-type-strict]
        [IW_IOCTL_IDX(SIOCSIWGENIE)]    = (iw_handler) cfg80211_wext_siwgenie,
                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

../drivers/net/wireless/intersil/orinoco/wext.c:1390:27: error: incompatible function pointer types initializing 'const iw_handler' (aka 'int (*const)(struct net_device *, struct iw_request_info *, union iwreq_data *, char *)') with an expression of type 'int (struct net_device *, struct iw_request_info *, struct iw_param *, char *)' [-Wincompatible-function-pointer-types]
        IW_HANDLER(SIOCGIWRETRY,        cfg80211_wext_giwretry),
                                        ^~~~~~~~~~~~~~~~~~~~~~

The cfg80211 Wireless Extension handler callbacks (iw_handler) use a
union for the data argument. Actually use the union and perform explicit
member selection in the function body instead of having a function
prototype mismatch. There are no resulting binary differences
before/after changes.

These changes were made partly manually and partly with the help of
Coccinelle.

Link: https://github.com/KSPP/linux/issues/234
Link: https://reviews.llvm.org/D134831 [1]
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/a68822bf8dd587988131bb6a295280cb4293f05d.1667934775.git.gustavoars@kernel.org

When built with Control Flow Integrity, function prototypes between
caller and function declaration must match. These mismatches are visible
at compile time with the new -Wcast-function-type-strict in Clang[1].

Fix a total of 43 warnings like these:

drivers/net/wireless/intersil/orinoco/wext.c:1379:27: warning: cast from 'int (*)(struct net_device *, struct iw_request_info *, struct iw_param *, char *)' to 'iw_handler' (aka 'int (*)(struct net_device *, struct iw_request_info *, union iwreq_data *, char *)') converts to incompatible function type [-Wcast-function-type-strict]
        IW_HANDLER(SIOCGIWPOWER,        (iw_handler)orinoco_ioctl_getpower),
                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The orinoco Wireless Extension handler callbacks (iw_handler) use a
union for the data argument. Actually use the union and perform explicit
member selection in the function body instead of having a function
prototype mismatch. No significant binary differences were seen
before/after changes.

These changes were made partly manually and partly with the help of
Coccinelle.

Link: https://github.com/KSPP/linux/issues/234
Link: https://reviews.llvm.org/D134831 [1]
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/e564003608a1f2ad86283370ef816805c92b30f6.1667934775.git.gustavoars@kernel.org

It simplifies the code a bit.
Suggested-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NBitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/68f94284-3728-7b75-2b7b-64fae8af6bc5@gmail.com