Fix fallback path of brcmf_init_channel_info_provider#241
Closed
dberlin wants to merge 50 commits intoAsahiLinux:basefrom
Closed
Fix fallback path of brcmf_init_channel_info_provider#241dberlin wants to merge 50 commits intoAsahiLinux:basefrom
dberlin wants to merge 50 commits intoAsahiLinux:basefrom
Conversation
Using the WSEC command instead of sae_password seems to be the supported mechanism on newer firmware, and also how the brcmdhd driver does it. Signed-off-by: Hector Martin <marcan@marcan.st>
There are many newer flags and extended shared area fields used by newer firmwares that are not yet defined. Add them for future usage. Signed-off-by: Hector Martin <marcan@marcan.st>
On newer firmwares under at least certain conditions, MSI mode does not leave interrupt flags set (they are cleared by the firmware). Handle this by always checking for ring data when we get an MSI, regardless of whether any IRQ flags were set. Signed-off-by: Hector Martin <marcan@marcan.st>
While the other >PCIe r64 registers (which are apparently called DAR registers) are always used on newer revisions, which doorbell registers should be used depends only on flags set by firmware. Take them out of the reginfo struct and check the flag to decide instead. Signed-off-by: Hector Martin <marcan@marcan.st>
Interface versions 6 and above support having the host tell the dongle about what it supports via a host_cap field (it seems that if it is set to zero, some kind of unknown defaults are used). Explicitly support and set this. This also disables OOB deep sleep support; it doesn't look like deep sleep is properly supported yet at all (it needs more logic than merely acking requests, which is all pcie.c does right now). Signed-off-by: Hector Martin <marcan@marcan.st>
There are many newer msgbuf packet types that are not yet listed in the defines in msgbuf.c. Add them for future use. Signed-off-by: Hector Martin <marcan@marcan.st>
Newer firmware versions use the common ring for sending mailbox messages between the dongle and host, instead of the hardware mailboxes. This needs the protocol driver to call back into the bus driver, so add a callback for this to bus.h. Signed-off-by: Hector Martin <marcan@marcan.st>
Newer firmware versions use these to exchange mailbox data, instead of the hardware mailbox registers. Add handling for them to msgbuf.c. Signed-off-by: Hector Martin <marcan@marcan.st>
Newer firmwares have switched from using the hardware mailbox to commonring messages for power mailbox data. Implement this, which makes D3 work on WiFi chipsets in Apple devices. This is only enabled on v6 or newer, iff BRCMF_PCIE_SHARED_USE_MAILBOX is not set in the flags. Signed-off-by: Hector Martin <marcan@marcan.st>
People keep complaining about this and think their wifi is broken for some reason... Signed-off-by: Hector Martin <marcan@marcan.st>
This is the counterpart to b50255c. In MSI mode we can still get MSIs even with IRQs disabled, so add an explicit gate for it. Signed-off-by: Hector Martin <marcan@marcan.st>
SYSMEM corerev 12+ uses different coreinfo masks for the ROM/RAM sizes. The masks for cores <12 also look like they were wrong all along, since the register layout is not the same as for SOCRAM (even though it was sharing the defines). Plus we need to skip the ROM banks, which we weren't doing. So it looks like this was always wrong for SYSMEM chips. Fix it and add support for the new revisions. Signed-off-by: Hector Martin <marcan@marcan.st>
Beginning with BCM4388, Apple machines are using firmware signing. This requires a new firmware blob (as the signature is provided out-of-band) as well as an extension of the existing random seed upload mechanism to populate the data structures required for signature verification by the bootloader. To implement this, refactor the existing random seed code to be more generic, and use it to implement the signature upload. Drive-by changes: Remove two unused members of brcmf_pciedev_info (which are confusing as they are never initialized), and also zero out the unused portion of TCM to make TCM dumps less noisy. With this, the TCM contents are 1:1 identical to what the macOS driver ends up doing, except for the NVRAM which has the injected macaddr property at the end instead of at the start. Signed-off-by: Hector Martin <marcan@marcan.st>
New chips, bigger rings again. BCM4388 Apple firmware posts more than 1024 RX buffers, so we need to bump this up again. This also requires increasing the number of RX PKTIDs. Signed-off-by: Hector Martin <marcan@marcan.st>
BCM4388 supports more bands, so make space for them. Signed-off-by: Hector Martin <marcan@marcan.st>
…y number This is the ca7 version of 3c7c07c ("wifi: brcmfmac: chip: Only disable D11 cores; handle an arbitrary number"). Instead of the hack in resetcore to handle multiple 80211 cores, let's just iterate in set_passive. Signed-off-by: Hector Martin <marcan@marcan.st>
On newer cores, we need to explicitly set the subsystems to reset via the watchdog. Logic adapted from bcmdhd. Signed-off-by: Hector Martin <marcan@marcan.st>
Currently the pcie code multiplexes all register accesses through a single window. This isn't very efficient, and it creates race conditions when we access registers from multiple paths (e.g. in the interrupt handler). Since the chip has a dedicated window for the PCIe core registers, we can use that instead, avoid all the gratuitous window switching, and fix the IRQ race issues. Signed-off-by: Hector Martin <marcan@marcan.st>
Newer firmwares notify the host of boot completion via an MSI, so let's make sure that is initialized before booting the firmware. Signed-off-by: Hector Martin <marcan@marcan.st>
With secure boot, the vector is not accessible and trying to write it triggers PCIe errors. Skip it in that case. Signed-off-by: Hector Martin <marcan@marcan.st>
Make sure the firmware can't get any early notifications by masking all IRQs explicitly before loading the firmware. Signed-off-by: Hector Martin <marcan@marcan.st>
This is essentially identical to SCAN_V2 with an extra field where we had a padding byte, so don't bother duplicating the entire structure. Just add the field and the logic to set the version properly. Signed-off-by: Hector Martin <marcan@marcan.st>
This extended command supports bit set/clear operations, but we just use it like the old full mask set command. Signed-off-by: Hector Martin <marcan@marcan.st>
The structures are compatible and just add fields, so we can just treat it as always v112. If we start using new fields, that will have to be gated on the version. Signed-off-by: Hector Martin <marcan@marcan.st>
New firmware wants extra fields, hopefully old firmware ignores them. Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Hector Martin <marcan@marcan.st>
Fix access point mode by bringing firmware into appropriate state before setting up the device. Signed-off-by: Patrick Blass <patrickblass.dev@gmail.com>
This patch fixes the firmware memory map structure to be complete. Along the way, we fix a failure to align the heap memory start address, which causes failures with the newest apple wifi firmware. With this patch, we can load the latest (sonoma 14.0 as of right now) apple wifi firmware. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
This patch adds support for 6G chanspecs, as part of adding 6G and 802.11ax support. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
1. Correct VHT MCS settings to support as many tx/rx streams as chip does. 2. Correct VHT capabilities to support what all chips do. 3. Correct max AMPDU capabilities for VHT. 4. Support LDPC and STBC in VHT where available. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
…tructure. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
This patch adds support for using GCMP/etc during offload where supported by the firmware. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
We may just have had to clone a packet, and not actually have run out of headroom. Only issue warning about headroom when we actually ran out of headroom. This removes useless spam about needing 0 more bytes of headroom. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
This patch adds support for handling the scan flags that come from the 802.11 stack. This enables the stack to control whether we are doing high/low power scans, as well as other options. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
This patch adds support for 6G bands, along with HE capabilities, as they are required to register 6G bands with wiphy. This in turn, enables 802.11ax support for the other bands. Scanning is not updated in this patch, so the bands are unused except to be able to process what the firmware tells us. Existing code is updated to handle all the bands rather than just 2g and 5g channels. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Currently, we ignore the default country in the reg notifier. We also register a custom regulatory domain, which is set as the default. As a result, the chip is likely to be set to the correct country, but the regulatory domain will not match it. When the regulatory notifier is then called, we see the countries are the same and do not change anything, even though the domain is wrong. This patch forces us to reset the bands on the first country change even if the chip is already set to that country. We also restore the original band info before reconstructing channel info, as the new regdom power limits may be higher than what is currently set. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
This patch structurizes PNF scan handling, adding support for netinfo v3 and PNO v3 structures. This in turn, enables the chip to tell us about 6G scan results, as the results contain chanspecs and not just channels. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
To support new join parameter versions, we move to using a function pointer structure that knows how to deal with the different versions of structures Drive-by fix: Always count the assoc_params length even if no bssid is provided. It doesn't make sense to truncate it off, since we need to set the bssid to the broadcast addr anyway in that case. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
handle the interface versions we find. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
This adds support for more authentication types during roaming offload, enabling the firmware to handle roaming for ~all authentication types. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
We try to retrieve a newer sta_info structure that has both rx and tx ratespecs, but if we don't get the structure we are expecting we fall back to tx rate info only. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Newer firmware versions support a combined channel info and chanspec list structure, and listing more channels than is supported by "chanspecs". This patch adds support for this structure and uses it when it is available. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
This makes firmware-side interface creation structures private to interface creation, and commons out how creation is handled Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Previously this could try to free a provider that wasn't initialized. Signed-off-by: Hector Martin <marcan@marcan.st>
When we fallback to using chanspecs, we accidentally free the memory and then return, because we fall into the error path instead of returning 0. Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
|
Pulled in, thanks! |
jannau
pushed a commit
that referenced
this pull request
Mar 15, 2025
commit 3109d5f upstream. With ltp test case "testcases/bin/hugefork02", there is a dmesg error report message such as: kernel BUG at mm/hugetlb.c:5550! Oops - BUG[#1]: CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940 a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000 a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000 t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000 t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001 t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280 s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10 s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08 ra: 9000000000485538 unmap_vmas+0x130/0x218 ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0 PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64) Call Trace: [<90000000004eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0 [<9000000000485534>] unmap_vmas+0x12c/0x218 [<9000000000494068>] exit_mmap+0xe0/0x308 [<900000000025fdc4>] mmput+0x74/0x180 [<900000000026a284>] do_exit+0x294/0x898 [<900000000026aa30>] do_group_exit+0x30/0x98 [<900000000027bed4>] get_signal+0x83c/0x868 [<90000000002457b4>] arch_do_signal_or_restart+0x54/0xfa0 [<90000000015795e8>] irqentry_exit_to_user_mode+0xb8/0x138 [<90000000002572d0>] tlb_do_page_fault_1+0x114/0x1b4 The problem is that base address allocated from hugetlbfs is not aligned with pmd size. Here add a checking for hugetlbfs and align base address with pmd size. After this patch the test case "testcases/bin/hugefork02" passes to run. This is similar to the commit 7f24cbc ("mm/mmap: teach generic_get_unmapped_area{_topdown} to handle hugetlb mappings"). Cc: stable@vger.kernel.org # 6.13+ Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
chadmed
pushed a commit
to chadmed/linux
that referenced
this pull request
Mar 22, 2025
With ltp test case "testcases/bin/hugefork02", there is a dmesg error report message such as: kernel BUG at mm/hugetlb.c:5550! Oops - BUG[#1]: CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ AsahiLinux#241 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940 a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000 a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000 t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000 t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001 t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280 s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10 s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08 ra: 9000000000485538 unmap_vmas+0x130/0x218 ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0 PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64) Call Trace: [<90000000004eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0 [<9000000000485534>] unmap_vmas+0x12c/0x218 [<9000000000494068>] exit_mmap+0xe0/0x308 [<900000000025fdc4>] mmput+0x74/0x180 [<900000000026a284>] do_exit+0x294/0x898 [<900000000026aa30>] do_group_exit+0x30/0x98 [<900000000027bed4>] get_signal+0x83c/0x868 [<90000000002457b4>] arch_do_signal_or_restart+0x54/0xfa0 [<90000000015795e8>] irqentry_exit_to_user_mode+0xb8/0x138 [<90000000002572d0>] tlb_do_page_fault_1+0x114/0x1b4 The problem is that base address allocated from hugetlbfs is not aligned with pmd size. Here add a checking for hugetlbfs and align base address with pmd size. After this patch the test case "testcases/bin/hugefork02" passes to run. This is similar to the commit 7f24cbc ("mm/mmap: teach generic_get_unmapped_area{_topdown} to handle hugetlb mappings"). Cc: stable@vger.kernel.org # 6.13+ Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
jannau
pushed a commit
that referenced
this pull request
Apr 3, 2026
[ Upstream commit fecacfc ] iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the value could change in runtime, we should use num_tx_queues instead. Moreover iavf_get_ethtool_stats() uses num_active_queues while iavf_get_sset_count() and iavf_get_stat_strings() use real_num_tx_queues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1]. For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3: Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S) iavf_set_channels() ... iavf_alloc_queues() -> num_active_queues = 8 iavf_schedule_finish_config() iavf_get_sset_count() real_num_tx_queues: 1 -> buffer for 1 queue iavf_get_ethtool_stats() num_active_queues: 8 -> out-of-bounds! iavf_finish_config() -> real_num_tx_queues = 8 Use immutable num_tx_queues in all related functions to avoid the issue. [1] BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800 CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x180 iavf_add_one_ethtool_stat+0x200/0x270 iavf_get_ethtool_stats+0x14c/0x2e0 __dev_ethtool+0x3d0c/0x5830 dev_ethtool+0x12d/0x270 dev_ioctl+0x53c/0xe30 sock_do_ioctl+0x1a9/0x270 sock_ioctl+0x3d4/0x5e0 __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xf3/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... </TASK> The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fixes: 64430f7 ("iavf: Fix displaying queue statistics shown by ethtool") Signed-off-by: Kohei Enju <kohei@enjuk.jp> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This was crashing the m1's.