linux-stable.git/drivers/net/wireless/broadcom, branch v6.5.2

wifi: brcm80211: handle params_v1 allocation failure

2023-08-08T10:47:37+00:00

Return -ENOMEM from brcmf_run_escan() if kzalloc() fails for v1 params.

Fixes: 398ce273d6b1 ("wifi: brcmfmac: cfg80211: Add support for scan params v2")
Signed-off-by: Petr Tesarik 
Link: https://lore.kernel.org/r/20230802163430.1656-1-petrtesarik@huaweicloud.com
Signed-off-by: Johannes Berg

wifi: brcmfmac: Fix field-spanning write in brcmf_scan_params_v2_to_v1()

2023-08-02T10:34:16+00:00

Using brcmfmac with 6.5-rc3 on a brcmfmac43241b4-sdio triggers
a backtrace caused by the following field-spanning warning:

memcpy: detected field-spanning write (size 120) of single field
  "¶ms_le->channel_list[0]" at
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1072 (size 2)

The driver still works after this warning. The warning was introduced by the
new field-spanning write checks which were enabled recently.

Fix this by replacing the channel_list[1] declaration at the end of
the struct with a flexible array declaration.

Most users of struct brcmf_scan_params_le calculate the size to alloc
using the size of the non flex-array part of the struct + needed extra
space, so they do not care about sizeof(struct brcmf_scan_params_le).

brcmf_notify_escan_complete() however uses the struct on the stack,
expecting there to be room for at least 1 entry in the channel-list
to store the special -1 abort channel-id.

To make this work use an anonymous union with a padding member
added + the actual channel_list flexible array.

Cc: Kees Cook 
Signed-off-by: Hans de Goede 
Reviewed-by: Kees Cook 
Reviewed-by: Franky Lin 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230729140500.27892-1-hdegoede@redhat.com

wifi: brcmsmac: fix gnu_printf warnings

2023-06-16T09:24:15+00:00

With GCC 13.1 and W=1 brcmsmac has warnings like this:

./include/trace/stages/stage5_get_offsets.h:23:31: warning: function 'trace_event_get_offsets_brcms_dbg' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format]

Add a workaround which disables -Wsuggest-attribute=format in
brcms_trace_brcmsmac_msg.h. I see similar workarounds in other drivers as well.

Compile tested only.

Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230613140918.389690-3-kvalo@kernel.org

wifi: brcmfmac: fix gnu_printf warnings

2023-06-16T09:24:15+00:00

With GCC 13.1 and W=1 brcmfmac has warnings like this:

./include/trace/perf.h:26:16: warning: function 'perf_trace_brcmf_dbg' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format]

Add a workaround which disables -Wsuggest-attribute=format in tracepoint.h. I
see similar workarounds in other drivers as well.

Compile tested only.

Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230613140918.389690-2-kvalo@kernel.org

wifi: brcmfmac: Detect corner error case earlier with log

2023-06-08T16:00:00+00:00

In brcmf_chip_recognition(), the return value from an MMIO read is
interpreted as various fields without checking if it failed, which is
harmless today, as the interpreted fields are checked for validity a
few lines below.  However, in corner cases (on my MacbookPro 14,1,
sometimes after waking from sleep or soft reboot), when this happens,
it causes the logging to be misleading, because the message indicates
an unsupported chip type ("brcmfmac: brcmf_chip_recognition: chip
backplane type 15 is not supported").  This patch detects this case
slightly earlier and logs an appropriate message, with the same return
result as is the case today.

Signed-off-by: Neal Sidhwaney 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230603060021.57225-1-nealsid@gmail.com

Merge wireless into wireless-next

2023-06-07T17:49:36+00:00

There are a number of upcoming things in both the stack and
drivers that would otherwise conflict, so merge wireless to
wireless-next to be able to avoid those conflicts.

Signed-off-by: Johannes Berg

wifi: brcmutil: use helper function pktq_empty() instead of open code

2023-06-01T13:14:43+00:00

pktq_empty was added in commit 5b435de0d786 ("net: wireless: add brcm80211
drivers") but it is currently not being utilized in some areas. This commit
replaces the open code with the pktq_empty() function.

Signed-off-by: Juhee Kang 
Reviewed-by: Simon Horman 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230527114954.3281-2-claudiajkang@gmail.com

wifi: b43: fix incorrect __packed annotation

2023-05-17T06:24:09+00:00

clang warns about an unpacked structure inside of a packed one:

drivers/net/wireless/broadcom/b43/b43.h:654:4: error: field data within 'struct b43_iv' is less aligned than 'union (unnamed union at /home/arnd/arm-soc/drivers/net/wireless/broadcom/b43/b43.h:651:2)' and is usually due to 'struct b43_iv' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]

The problem here is that the anonymous union has the default alignment
from its members, apparently because the original author mixed up the
placement of the __packed attribute by placing it next to the struct
member rather than the union definition. As the struct itself is
also marked as __packed, there is no need to mark its members, so just
move the annotation to the inner type instead.

As Michael noted, the same problem is present in b43legacy, so
change both at the same time.

Acked-by: Michael Büsch 
Reported-by: kernel test robot 
Reviewed-by: Simon Horman 
Tested-by: Larry Finger 
Link: https://lore.kernel.org/oe-kbuild-all/202305160749.ay1HAoyP-lkp@intel.com/
Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230516183442.536589-1-arnd@kernel.org

wifi: brcmfmac: wcc: Add debug messages

2023-05-15T18:25:11+00:00

The message is attach and detach function are merly for debugging,
change them from pr_err to pr_debug.

Signed-off-by: Matthias Brugger 
Reviewed-by: Hans de Goede 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230509100420.26094-1-matthias.bgg@kernel.org

wifi: brcmfmac: Check for probe() id argument being NULL

2023-05-15T18:18:42+00:00

The probe() id argument may be NULL in 2 scenarios:

1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe
   the device.

2. If a user tries to manually bind the driver from sysfs then the sdio /
   pcie / usb probe() function gets called with NULL as id argument.

1. Is being hit by users causing the following oops on resume and causing
wifi to stop working:

BUG: kernel NULL pointer dereference, address: 0000000000000018

Hardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020
Workgueue: events_unbound async_run_entry_fn
RIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac]

Call Trace:
 
 brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887]
 ? pci_pm_resume+0x5b/0xf0
 ? pci_legacy_resume+0x80/0x80
 dpm_run_callback+0x47/0x150
 device_resume+0xa2/0x1f0
 async_resume+0x1d/0x30


Fix this by checking for id being NULL.

In the PCI and USB cases try a manual lookup of the id so that manually
binding the driver through sysfs and more importantly brcmf_pcie_probe()
on resume will work.

For the SDIO case there is no helper to do a manual sdio_device_id lookup,
so just directly error out on a NULL id there.

Fixes: da6d9c8ecd00 ("wifi: brcmfmac: add firmware vendor info in driver info")
Reported-by: Felix 
Link: https://lore.kernel.org/regressions/4ef3f252ff530cbfa336f5a0d80710020fc5cb1e.camel@gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede 
Reviewed-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230510141856.46532-1-hdegoede@redhat.com