kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h, branch linux-6.2.y

wifi: brcmfmac: of: Fetch Apple properties

2022-09-19T09:59:34Z

On Apple ARM64 platforms, firmware selection requires two properties that come from system firmware: the module-instance (aka "island", a codename representing a given hardware platform) and the antenna-sku. We map Apple's module codenames to board_types in the form "apple,". The mapped board_type is added to the DTS file in that form, while the antenna-sku is forwarded by our bootloader from the Apple Device Tree into the FDT. Grab them from the DT so firmware selection can use them. Reviewed-by: Linus Walleij Signed-off-by: Hector Martin Reviewed-by: Alvin Šipraga Signed-off-by: Russell King (Oracle) Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/E1oZDnn-0077aS-NA@rmk-PC.armlinux.org.uk

wifi: brcmfmac: support brcm,ccode-map-trivial DT property

2022-07-28T09:58:42Z

Commit a21bf90e927f ("brcmfmac: use ISO3166 country code and 0 rev as fallback on some devices") introduced a fallback mechanism whereby a trivial mapping from ISO3166 country codes to firmware country code and revision is used on some devices. This fallback operates on the device level, so it is enabled only for certain supported chipsets. In general though, the firmware country codes are determined by the CLM blob, which is board-specific and may vary despite the underlying chipset being the same. The aforementioned commit is actually a refinement of a previous commit that was reverted in commit 151a7c12c4fc ("Revert "brcmfmac: use ISO3166 country code and 0 rev as fallback"") due to regressions with a BCM4359 device. The refinement restricted the fallback mechanism to specific chipsets such as the BCM4345. We use a chipset - CYW88359 - that the driver identifies as a BCM4359 too. But in our case, the CLM blob uses ISO3166 country codes internally, and all with revision 0. So the trivial mapping is exactly what is needed in order for the driver to sync the kernel regulatory domain to the firmware. This is just a matter of how the CLM blob was prepared by the hardware vendor. The same could hold for other boards too. Although the brcm,ccode-map device tree property is useful for cases where the mapping is more complex, the trivial case invites a much simpler specification. This patch adds support for parsing the brcm,ccode-map-trivial device tree property. Subordinate to the more specific brcm,ccode-map property, this new proprety simply informs the driver that the fallback method should be used in every case. In the absence of the new property in the device tree, expect no functional change. Signed-off-by: Alvin Šipraga Reviewed-by: Ahmad Fatoum Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220711123005.3055300-3-alvin@pqrs.dk

wifi: brcmfmac: Add brcmf_c_set_cur_etheraddr() helper

2022-07-28T09:58:11Z

Add a little helper to send "cur_etheraddr" commands to the interface and to handle the error reporting of it in a single place. Signed-off-by: Hans de Goede Acked-by: Arend van Spriel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220708133712.102179-1-hdegoede@redhat.com

brcmfmac: allow setting wlan MAC address using device tree

2022-05-11T05:27:14Z

This allows firmware to provide MAC address using device tree. Like in case there is no MAC burned in wlan NVRAM. Signed-off-by: Pavel Löbl Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220506044246.67146-1-pavel@loebl.cz

brcmfmac: map 802.1d priority to precedence level based on AP WMM params

2020-05-12T08:50:40Z

In WLAN, priority among various access categories of traffic is always set by the AP using WMM parameters and this may not always follow the standard 802.1d priority. In this change, priority is adjusted based on the AP WMM params received as part of the Assoc Response and the same is later used to map the priority of all incoming traffic. In a specific scenario where EDCA parameters are configured to be same for all ACs, use the default FW priority definition to avoid queuing packets of all ACs to the same priority queue. This change fixes the following 802.11 certification tests: * 11n - 5.2.31 ACM Bit Conformance test * 11n - 5.2.32 AC Parameter Modification test * 11ac - 5.2.33 TXOP Limit test Signed-off-by: Saravanan Shanmugham Signed-off-by: Justin Li Signed-off-by: Madhan Mohan R Signed-off-by: Chi-hsien Lin Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1588661487-21884-2-git-send-email-chi-hsien.lin@cypress.com

brcmfmac: switch source files to using SPDX license identifier

2019-05-28T12:24:12Z

With ISC license text in place under the LICENSES folder switch to using the SPDX license identifier to refer to the ISC license. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo

brcmfmac: Set board_type from DMI on x86 based machines

2018-11-06T16:50:17Z

For x86 based machines, set the board_type used for nvram file selection based on the DMI sys-vendor and product-name strings. Since on some models these strings are too generic, this commit also adds a quirk table overriding the strings for models listed in that table. The board_type setting is used to load the board-specific nvram file with a board-specific name so that we can ship files for each supported board in linux-firmware. Signed-off-by: Hans de Goede Signed-off-by: Kalle Valo

brcmfmac: Set board_type used for nvram file selection to machine-compatible

2018-11-06T16:50:16Z

For of/devicetree using machines, set the board_type used for nvram file selection to the first string listed in the top-level's node compatible string, aka the machine-compatible as used by of_machine_is_compatible(). The board_type setting is used to load the board-specific nvram file with a board-specific name so that we can ship files for each supported board in linux-firmware. Signed-off-by: Hans de Goede Signed-off-by: Kalle Valo

brcmfmac: move ALLFFMAC variable in flowring module

2018-05-23T15:51:47Z

The only user of ALLFFMAC is the flowring module so no need to expose it in a header file. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo

brcmfmac: drop Inter-Access Point Protocol packets by default

2018-03-16T13:00:24Z

Testing brcmfmac with more recent firmwares resulted in AP interfaces not working in some specific setups. Debugging resulted in discovering support for IAPP in Broadcom's firmwares. Older firmwares were only generating 802.11f frames. Newer ones like: 1) 10.10 (TOB) (r663589) 2) 10.10.122.20 (r683106) for 4366b1 and 4366c0 respectively seem to also /respect/ 802.11f frames in the Tx path by performing a STA disassociation. This obsoleted standard and its implementation is something that: 1) Most people don't need / want to use 2) Can allow local DoS attacks 3) Breaks AP interfaces in some specific bridge setups To solve issues it can cause this commit modifies brcmfmac to drop IAPP packets. If affects: 1) Rx path: driver won't be sending these unwanted packets up. 2) Tx path: driver will reject packets that would trigger STA disassociation perfromed by a firmware (possible local DoS attack). It appears there are some Broadcom's clients/users who care about this feature despite the drawbacks. They can switch it on using a new module param. This change results in only two more comparisons (check for module param and check for Ethernet packet length) for 99.9% of packets. Its overhead should be very minimal. Signed-off-by: Rafał Miłecki Acked-by: Arend van Spriel Signed-off-by: Kalle Valo