2021-12-26 15:36:43

by Hector Martin

[permalink] [raw]
Subject: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms

Hi everyone,

Merry Christmas! This year Santa brings us a 34-patch series to add
proper support for the Broadcom FullMAC chips used on Apple T2 and M1
platforms:

- BCM4355C1
- BCM4364B2/B3
- BCM4377B3
- BCM4378B1
- BCM4387C2

As usual for Apple, things are ever so slightly different on these
machines from every other Broadcom platform. In particular, besides
the normal device/firmware support changes, a large fraction of this
series deals with selecting and loading the correct firmware. These
platforms use multiple dimensions for firmware selection, and the values
for these dimensions are variously sourced from DT or OTP (see the
commit message for #9 for the gory details).

This is what is included:

# 01: DT bindings (M1 platforms)

On M1 platforms, we use the device tree to provide properties for PCIe
devices like these cards. This patch re-uses the existing SDIO binding
and adds the compatibles for these PCIe chips, plus the properties we
need to correctly instantiate them:

- apple,module-instance: A codename (seemingly always an island) that
identifies the specific platform/board. brcmfmac normally uses the
root node compatible for this on DT platforms, but Apple have their
own mapping/identifier here. This is prepended with `apple,` and
becomes the base board_name for firmware selection. An alternative
here might be to use something like brcm,board-name with the
`apple,`-prefixed value instead, which would be more general and allow
any DT platform to override the desired board name used when building
firmware filenames.

- apple,antenna-sku: Specifies the specific antenna configuration in a
produt. This would normally be filled in by the bootloader from
device-specific configuration data. On ACPI platforms, this is
provided via ACPI instead. This is used to build the funky Apple
firmware filenames. Note: it seems the antenna doesn't actually matter
for any of the above platforms (they are all aliases to the same files
and our firmware copier collapses down this dimension), but since
Apple do support having different firmware or NVRAM depending on
antenna SKU, we ough to support it in case it starts mattering on a
future platform.

- brcm,cal-blob: A calibration blob for the Wi-Fi module, specific to a
given unit. On most platforms, this is stored in SROM on the module,
and does not need to be provided externally, but Apple instead stores
this in platform configuration for M1 machines and the driver needs to
upload it to the device after initializing the firmware. This has a
generic brcm name, since a priori this mechanism shouldn't be
Apple-specific, although chances are only Apple do it like this so far.

# 02~09: Apple firmware selection (M1 platforms)

These patches add support for choosing firmwares (binaries, CLM blobs,
and NVRAM configs alike) using all the dimensions that Apple uses. The
firmware files are renamed to conform to the existing brcmfmac
convention. See the commit message for #9 for the gory details as to how
these filenames are constructed. The data to make the firmware selection
comes from the above DT properties and from an OTP ROM on the chips on
M1 platforms.

# 10~14: BCM4378 support (M1 T8103 platforms)

These patches make changes required to support the BCM4378 chip present
in Apple M1 (T8103) platforms. This includes adding support for passing
in the MAC address via the DT (this is standard on DT platforms) since
the chip does not have a burned-in MAC; adding support for PCIe core
revs >64 (which moved around some registers); tweaking ring buffer
sizes; and fixing a bug.

# 15~20: BCM4355/4364/4377 support (T2 platforms)

These patches add support for the chips found across T2 Mac platforms.
This includes ACPI support for fetching properties instead of using DT,
providing a buffer of entropy to the devices (required for some of the
firmwares), and adding the required IDs. This also fixes the BCM4364
firmware naming; it was added without consideration that there are two
incompatible chip revisions. To avoid this ambiguity in the future, all
the chips added by this series use firmware names ending in the revision
(apple/brcm style, that is letter+number), so that future revisions can
be added without creating confusion.

# 21~27: BCM4387 support (M1 Pro/Max T600x platforms)

These patches add support for the newer BCM4387 present in the recently
launched M1 Pro/Max platforms. This chip requires a few changes to D11
reset behavior and TCM size calculation to work properly, and it uses
newer firmware which needs support for newer firmware interfaces
in the cfg80211 support. Backwards compatibility is maintained via
feature flags discovered at runtime from information provided by the
firmware.

A note on #26: it seems this chip broke the old hack of passing the PMK
in hexdump form as a PSK, but it seems brcmfmac chips supported passing
it in binary all along. I'm not sure why it was done this way in the
Linux driver, but it seems OpenBSD always did it in binary and works
with older chips, so this should be reasonably well tested. Any further
insight as to why this was done this way would be appreciated.

# 28~31: Fixes

These are just random things I came across while developing this series.
#31 is required to avoid a compile warning in subsequent patches. None
of these are strictly required to support these chips/platforms.

# 32-34: TxCap and calibration blobs

These patches add support for uploading TxCap blobs, which are another
kind of firmware blob that Apple platforms use (T2 and M1), as well as
providing Wi-Fi calibration data from the device tree (M1).

I'm not sure what the TxCap blobs do. Given the stray function
prototype at [5], it would seem the Broadcom folks in charge of Linux
drivers also know all about Apple's fancy OTP for firmware selection
and the existence of TxCap blobs, so it would be great if you could
share any insight here ;-)

These patches are not required for the chips to function, but presumably
having proper per-device calibration data available matters, and I
assume the TxCap blobs aren't just for show either.

# On firmware

As you might expect, the firmware for these machines is not available
under a redistributable license; however, every owner of one of these
machines *is* implicitly licensed to posess the firmware, and the OS
packages containing it are available under well-known URLs on Apple's
CDN with no authentication.

Our plan to support this is to propose a platform firmware mechanism,
where platforms can provide a firmware package in the EFI system
partition along with a manifest, and distros will extract it to
/lib/firmware on boot or otherwise make it available to the kernel.

Then, on M1 platforms, our install script, which performs all the
bootloader installation steps required to run Linux on these machines in
the first place, will also take care of copying the firmware from the
base macOS image to the EFI partition. On T2 platforms, we'll provide an
analogous script that users can manually run prior to a normal EFI Linux
installation to just grab the firmware from /usr/share/firmware/wifi in
the running macOS.

There is an example firmware manifest at [1] which details the files
copied by our firmware rename script [2], as of macOS 12.0.1.

To test this series on a supported Mac today (T2 or M1), boot into macOS
and run:

$ git clone https://github.com/AsahiLinux/asahi-installer
$ cd asahi-installer/src
$ python -m firmware.wifi /usr/share/firmware/wifi firmware.tar

Then copy firmware.tar to Linux and extract it into /lib/firmware.

# Acknowledgements

This patch series was developed referencing the OpenBSD support for the
BCM4378 [3] and the bcmdhd-4359 GPL release [4], which contained some
interesting tidbits about newer chips, registers, OTP, etc.

[1] https://gist.github.com/marcan/5cfaad948e224279f09a4a79ccafd9b6
[2] https://github.com/AsahiLinux/asahi-installer/blob/main/src/firmware/wifi.py
[3] https://github.com/openbsd/src/blob/master/sys/dev/pci/if_bwfm_pci.c
[4] https://github.com/StreamUnlimited/broadcom-bcmdhd-4359/
[5] https://github.com/StreamUnlimited/broadcom-bcmdhd-4359/blob/master/dhd_pcie.h#L594

Hector Martin (34):
dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
brcmfmac: pcie: Declare missing firmware files in pcie.c
brcmfmac: firmware: Support having multiple alt paths
brcmfmac: firmware: Handle per-board clm_blob files
brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism
brcmfmac: firmware: Support passing in multiple board_types
brcmfmac: pcie: Read Apple OTP information
brcmfmac: of: Fetch Apple properties
brcmfmac: pcie: Perform firmware selection for Apple platforms
brcmfmac: firmware: Allow platform to override macaddr
brcmfmac: msgbuf: Increase RX ring sizes to 1024
brcmfmac: pcie: Fix crashes due to early IRQs
brcmfmac: pcie: Support PCIe core revisions >= 64
brcmfmac: pcie: Add IDs/properties for BCM4378
ACPI / property: Support strings in Apple _DSM props
brcmfmac: acpi: Add support for fetching Apple ACPI properties
brcmfmac: pcie: Provide a buffer of random bytes to the device
brcmfmac: pcie: Add IDs/properties for BCM4355
brcmfmac: pcie: Add IDs/properties for BCM4377
brcmfmac: pcie: Perform correct BCM4364 firmware selection
brcmfmac: chip: Only disable D11 cores; handle an arbitrary number
brcmfmac: chip: Handle 1024-unit sizes for TCM blocks
brcmfmac: cfg80211: Add support for scan params v2
brcmfmac: feature: Add support for setting feats based on WLC version
brcmfmac: cfg80211: Add support for PMKID_V3 operations
brcmfmac: cfg80211: Pass the PMK in binary instead of hex
brcmfmac: pcie: Add IDs/properties for BCM4387
brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio
brcmfmac: pcie: Read the console on init and shutdown
brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path
brcmfmac: fwil: Constify iovar name arguments
brcmfmac: common: Add support for downloading TxCap blobs
brcmfmac: pcie: Load and provide TxCap blobs
brcmfmac: common: Add support for external calibration blobs

.../net/wireless/brcm,bcm4329-fmac.yaml | 32 +-
drivers/acpi/x86/apple.c | 11 +-
.../broadcom/brcm80211/brcmfmac/Makefile | 2 +
.../broadcom/brcm80211/brcmfmac/acpi.c | 51 ++
.../broadcom/brcm80211/brcmfmac/bus.h | 20 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 175 ++++-
.../broadcom/brcm80211/brcmfmac/chip.c | 36 +-
.../broadcom/brcm80211/brcmfmac/common.c | 130 +++-
.../broadcom/brcm80211/brcmfmac/common.h | 12 +
.../broadcom/brcm80211/brcmfmac/feature.c | 49 ++
.../broadcom/brcm80211/brcmfmac/feature.h | 6 +-
.../broadcom/brcm80211/brcmfmac/firmware.c | 140 +++-
.../broadcom/brcm80211/brcmfmac/firmware.h | 2 +-
.../broadcom/brcm80211/brcmfmac/fwil.c | 34 +-
.../broadcom/brcm80211/brcmfmac/fwil.h | 28 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 157 ++++-
.../broadcom/brcm80211/brcmfmac/msgbuf.h | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/of.c | 27 +-
.../broadcom/brcm80211/brcmfmac/pcie.c | 606 +++++++++++++++---
.../broadcom/brcm80211/brcmfmac/sdio.c | 41 +-
.../broadcom/brcm80211/brcmfmac/sdio.h | 2 +
.../broadcom/brcm80211/brcmfmac/usb.c | 23 +-
.../broadcom/brcm80211/include/brcm_hw_ids.h | 8 +
include/linux/bcma/bcma_driver_chipcommon.h | 1 +
24 files changed, 1327 insertions(+), 270 deletions(-)
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c

--
2.33.0



2021-12-26 15:36:55

by Hector Martin

[permalink] [raw]
Subject: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

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.

Signed-off-by: Hector Martin <[email protected]>
---
.../net/wireless/brcm,bcm4329-fmac.yaml | 32 +++++++++++++++++--
1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
index c11f23b20c4c..2530ff3e7b90 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/wireless/brcm,bcm4329-fmac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

-title: Broadcom BCM4329 family fullmac wireless SDIO devices
+title: Broadcom BCM4329 family fullmac wireless SDIO/PCIE devices

maintainers:
- Arend van Spriel <[email protected]>
@@ -36,16 +36,22 @@ properties:
- brcm,bcm43455-fmac
- brcm,bcm43456-fmac
- brcm,bcm4354-fmac
+ - brcm,bcm4355c1-fmac
- brcm,bcm4356-fmac
- brcm,bcm4359-fmac
+ - brcm,bcm4364b2-fmac
+ - brcm,bcm4364b3-fmac
+ - brcm,bcm4377b3-fmac
+ - brcm,bcm4378b1-fmac
+ - brcm,bcm4387c2-fmac
- cypress,cyw4373-fmac
- cypress,cyw43012-fmac
- const: brcm,bcm4329-fmac
- const: brcm,bcm4329-fmac

reg:
- description: SDIO function number for the device, for most cases
- this will be 1.
+ description: SDIO function number for the device (for most cases
+ this will be 1) or PCI device identifier.

interrupts:
maxItems: 1
@@ -75,6 +81,26 @@ properties:
items:
pattern: '^[A-Z][A-Z]-[A-Z][0-9A-Z]-[0-9]+$'

+ brcm,cal-blob:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: A per-device calibration blob for the Wi-Fi radio. This
+ should be filled in by the bootloader from platform configuration
+ data, if necessary, and will be uploaded to the device if present.
+
+ apple,module-instance:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Module codename used to identify a specific board on
+ Apple platforms. This is used to build the firmware filenames, to allow
+ different platforms to have different firmware and/or NVRAM config.
+
+ apple,antenna-sku:
+ $def: /schemas/types.yaml#/definitions/string
+ description: Antenna SKU used to identify a specific antenna configuration
+ on Apple platforms. This is use to build firmware filenames, to allow
+ platforms with different antenna configs to have different firmware and/or
+ NVRAM. This would normally be filled in by the bootloader from platform
+ configuration data.
+
required:
- compatible
- reg
--
2.33.0


2021-12-26 15:37:02

by Hector Martin

[permalink] [raw]
Subject: [PATCH 02/34] brcmfmac: pcie: Declare missing firmware files in pcie.c

Move one of the declarations from sdio.c to pcie.c, since it makes no
sense in the former (SDIO support is optional), and add missing ones.

Signed-off-by: Hector Martin <[email protected]>
Fixes: 75729e110e68 ("brcmfmac: expose firmware config files through modinfo")
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 7 +++++++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 -
2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 8b149996fc00..aed49416c434 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -59,6 +59,13 @@ BRCMF_FW_DEF(4366B, "brcmfmac4366b-pcie");
BRCMF_FW_DEF(4366C, "brcmfmac4366c-pcie");
BRCMF_FW_DEF(4371, "brcmfmac4371-pcie");

+/* firmware config files */
+MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.txt");
+MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.txt");
+
+/* per-board firmware binaries */
+MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.bin");
+
static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFF, 43602),
BRCMF_FW_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C),
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 8effeb7a7269..5d156e591b35 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -629,7 +629,6 @@ BRCMF_FW_CLM_DEF(43752, "brcmfmac43752-sdio");

/* firmware config files */
MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-sdio.*.txt");
-MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.txt");

/* per-board firmware binaries */
MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-sdio.*.bin");
--
2.33.0


2021-12-26 15:37:06

by Hector Martin

[permalink] [raw]
Subject: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

Apple platforms have firmware and config files identified with multiple
dimensions. We want to be able to find the most specific firmware
available for any given platform, progressively trying more general
firmwares.

First, add support for having multiple alternate firmware paths.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/firmware.c | 73 ++++++++++++++-----
1 file changed, 55 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 0eb13e5df517..cc97cd1da44d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -427,6 +427,8 @@ void brcmf_fw_nvram_free(void *nvram)
struct brcmf_fw {
struct device *dev;
struct brcmf_fw_request *req;
+ const char **alt_paths;
+ int alt_index;
u32 curpos;
void (*done)(struct device *dev, int err, struct brcmf_fw_request *req);
};
@@ -592,9 +594,10 @@ static int brcmf_fw_complete_request(const struct firmware *fw,
return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
}

-static char *brcm_alt_fw_path(const char *path, const char *board_type)
+static const char **brcm_alt_fw_paths(const char *path, const char *board_type)
{
char alt_path[BRCMF_FW_NAME_LEN];
+ char **alt_paths;
char suffix[5];

strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
@@ -609,27 +612,46 @@ static char *brcm_alt_fw_path(const char *path, const char *board_type)
strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);

- return kstrdup(alt_path, GFP_KERNEL);
+ alt_paths = kzalloc(sizeof(char *) * 2, GFP_KERNEL);
+ alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
+
+ return (const char **)alt_paths;
+}
+
+static void brcm_free_alt_fw_paths(const char **alt_paths)
+{
+ int i;
+
+ if (!alt_paths)
+ return;
+
+ for (i = 0; alt_paths[i]; i++)
+ kfree(alt_paths[i]);
+
+ kfree(alt_paths);
}

static int brcmf_fw_request_firmware(const struct firmware **fw,
struct brcmf_fw *fwctx)
{
struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
- int ret;
+ int ret, i;

/* Files can be board-specific, first try a board-specific path */
if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
- char *alt_path;
+ const char **alt_paths = brcm_alt_fw_paths(cur->path, fwctx);

- alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);
- if (!alt_path)
+ if (!alt_paths)
goto fallback;

- ret = request_firmware(fw, alt_path, fwctx->dev);
- kfree(alt_path);
- if (ret == 0)
- return ret;
+ for (i = 0; alt_paths[i]; i++) {
+ ret = firmware_request_nowarn(fw, alt_paths[i], fwctx->dev);
+ if (ret == 0) {
+ brcm_free_alt_fw_paths(alt_paths);
+ return ret;
+ }
+ }
+ brcm_free_alt_fw_paths(alt_paths);
}

fallback:
@@ -641,6 +663,9 @@ static void brcmf_fw_request_done(const struct firmware *fw, void *ctx)
struct brcmf_fw *fwctx = ctx;
int ret;

+ brcm_free_alt_fw_paths(fwctx->alt_paths);
+ fwctx->alt_paths = NULL;
+
ret = brcmf_fw_complete_request(fw, fwctx);

while (ret == 0 && ++fwctx->curpos < fwctx->req->n_items) {
@@ -662,13 +687,26 @@ static void brcmf_fw_request_done_alt_path(const struct firmware *fw, void *ctx)
struct brcmf_fw_item *first = &fwctx->req->items[0];
int ret = 0;

- /* Fall back to canonical path if board firmware not found */
- if (!fw)
+ if (fw) {
+ brcmf_fw_request_done(fw, ctx);
+ return;
+ }
+
+ fwctx->alt_index++;
+ if (fwctx->alt_paths[fwctx->alt_index]) {
+ /* Try the next alt firmware */
+ ret = request_firmware_nowait(THIS_MODULE, true,
+ fwctx->alt_paths[fwctx->alt_index],
+ fwctx->dev, GFP_KERNEL, fwctx,
+ brcmf_fw_request_done_alt_path);
+ } else {
+ /* Fall back to canonical path if board firmware not found */
ret = request_firmware_nowait(THIS_MODULE, true, first->path,
fwctx->dev, GFP_KERNEL, fwctx,
brcmf_fw_request_done);
+ }

- if (fw || ret < 0)
+ if (ret < 0)
brcmf_fw_request_done(fw, ctx);
}

@@ -693,7 +731,6 @@ int brcmf_fw_get_firmwares(struct device *dev, struct brcmf_fw_request *req,
{
struct brcmf_fw_item *first = &req->items[0];
struct brcmf_fw *fwctx;
- char *alt_path;
int ret;

brcmf_dbg(TRACE, "enter: dev=%s\n", dev_name(dev));
@@ -712,12 +749,12 @@ int brcmf_fw_get_firmwares(struct device *dev, struct brcmf_fw_request *req,
fwctx->done = fw_cb;

/* First try alternative board-specific path if any */
- alt_path = brcm_alt_fw_path(first->path, fwctx->req->board_type);
- if (alt_path) {
- ret = request_firmware_nowait(THIS_MODULE, true, alt_path,
+ fwctx->alt_paths = brcm_alt_fw_paths(first->path, fwctx);
+ if (fwctx->alt_paths) {
+ fwctx->alt_index = 0;
+ ret = request_firmware_nowait(THIS_MODULE, true, fwctx->alt_paths[0],
fwctx->dev, GFP_KERNEL, fwctx,
brcmf_fw_request_done_alt_path);
- kfree(alt_path);
} else {
ret = request_firmware_nowait(THIS_MODULE, true, first->path,
fwctx->dev, GFP_KERNEL, fwctx,
--
2.33.0


2021-12-26 15:37:17

by Hector Martin

[permalink] [raw]
Subject: [PATCH 04/34] brcmfmac: firmware: Handle per-board clm_blob files

Teach brcm_alt_fw_paths to correctly split off variable length
extensions, and enable alt firmware lookups for the CLM blob firmware
requests.

Apple platforms have per-board CLM blob files.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/firmware.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index cc97cd1da44d..eca5a6df1058 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -598,16 +598,16 @@ static const char **brcm_alt_fw_paths(const char *path, const char *board_type)
{
char alt_path[BRCMF_FW_NAME_LEN];
char **alt_paths;
- char suffix[5];
+ const char *suffix;

- strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
- /* At least one character + suffix */
- if (strlen(alt_path) < 5)
+ suffix = strrchr(path, '.');
+ if (!suffix || suffix == path)
return NULL;

- /* strip .txt or .bin at the end */
- strscpy(suffix, alt_path + strlen(alt_path) - 4, 5);
- alt_path[strlen(alt_path) - 4] = 0;
+ /* strip extension at the end */
+ strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
+ alt_path[suffix - path] = 0;
+
strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);
strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
@@ -638,7 +638,7 @@ static int brcmf_fw_request_firmware(const struct firmware **fw,
int ret, i;

/* Files can be board-specific, first try a board-specific path */
- if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
+ if (fwctx->req->board_type) {
const char **alt_paths = brcm_alt_fw_paths(cur->path, fwctx);

if (!alt_paths)
--
2.33.0


2021-12-26 15:37:28

by Hector Martin

[permalink] [raw]
Subject: [PATCH 05/34] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism

Now that the firmware fetcher can handle per-board CLM files, load the
CLM blob alongside the other firmware files and change the bus API to
just return the existing blob, instead of fetching the filename.

This enables per-board CLM blobs, which are required on Apple platforms.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/bus.h | 19 ++++++---
.../broadcom/brcm80211/brcmfmac/common.c | 12 +-----
.../broadcom/brcm80211/brcmfmac/pcie.c | 39 ++++++++++++-------
.../broadcom/brcm80211/brcmfmac/sdio.c | 36 ++++++++++-------
.../broadcom/brcm80211/brcmfmac/sdio.h | 2 +
.../broadcom/brcm80211/brcmfmac/usb.c | 23 +++--------
6 files changed, 69 insertions(+), 62 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
index 3f5da3bb6aa5..b13af8f631f3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
@@ -7,6 +7,8 @@
#define BRCMFMAC_BUS_H

#include "debug.h"
+#include <linux/kernel.h>
+#include <linux/firmware.h>

/* IDs of the 6 default common rings of msgbuf protocol */
#define BRCMF_H2D_MSGRING_CONTROL_SUBMIT 0
@@ -34,6 +36,11 @@ enum brcmf_bus_protocol_type {
BRCMF_PROTO_MSGBUF
};

+/* Firmware blobs that may be available */
+enum brcmf_blob_type {
+ BRCMF_BLOB_CLM,
+};
+
struct brcmf_mp_device;

struct brcmf_bus_dcmd {
@@ -60,7 +67,7 @@ struct brcmf_bus_dcmd {
* @wowl_config: specify if dongle is configured for wowl when going to suspend
* @get_ramsize: obtain size of device memory.
* @get_memdump: obtain device memory dump in provided buffer.
- * @get_fwname: obtain firmware name.
+ * @get_blob: obtain a firmware blob.
*
* This structure provides an abstract interface towards the
* bus specific driver. For control messages to common driver
@@ -77,8 +84,8 @@ struct brcmf_bus_ops {
void (*wowl_config)(struct device *dev, bool enabled);
size_t (*get_ramsize)(struct device *dev);
int (*get_memdump)(struct device *dev, void *data, size_t len);
- int (*get_fwname)(struct device *dev, const char *ext,
- unsigned char *fw_name);
+ int (*get_blob)(struct device *dev, const struct firmware **fw,
+ enum brcmf_blob_type type);
void (*debugfs_create)(struct device *dev);
int (*reset)(struct device *dev);
};
@@ -220,10 +227,10 @@ int brcmf_bus_get_memdump(struct brcmf_bus *bus, void *data, size_t len)
}

static inline
-int brcmf_bus_get_fwname(struct brcmf_bus *bus, const char *ext,
- unsigned char *fw_name)
+int brcmf_bus_get_blob(struct brcmf_bus *bus, const struct firmware **fw,
+ enum brcmf_blob_type type)
{
- return bus->ops->get_fwname(bus->dev, ext, fw_name);
+ return bus->ops->get_blob(bus->dev, fw, type);
}

static inline
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index e3758bd86acf..b8ed851129b4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -123,7 +123,6 @@ static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
struct brcmf_bus *bus = drvr->bus_if;
struct brcmf_dload_data_le *chunk_buf;
const struct firmware *clm = NULL;
- u8 clm_name[BRCMF_FW_NAME_LEN];
u32 chunk_len;
u32 datalen;
u32 cumulative_len;
@@ -133,15 +132,8 @@ static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)

brcmf_dbg(TRACE, "Enter\n");

- memset(clm_name, 0, sizeof(clm_name));
- err = brcmf_bus_get_fwname(bus, ".clm_blob", clm_name);
- if (err) {
- bphy_err(drvr, "get CLM blob file name failed (%d)\n", err);
- return err;
- }
-
- err = firmware_request_nowarn(&clm, clm_name, bus->dev);
- if (err) {
+ err = brcmf_bus_get_blob(bus, &clm, BRCMF_BLOB_CLM);
+ if (err || !clm) {
brcmf_info("no clm_blob available (err=%d), device may have limited channels available\n",
err);
return 0;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index aed49416c434..591f870d1e47 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -65,6 +65,7 @@ MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.txt");

/* per-board firmware binaries */
MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.bin");
+MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.clm_blob");

static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFF, 43602),
@@ -260,6 +261,8 @@ struct brcmf_pciedev_info {
struct pci_dev *pdev;
char fw_name[BRCMF_FW_NAME_LEN];
char nvram_name[BRCMF_FW_NAME_LEN];
+ char clm_name[BRCMF_FW_NAME_LEN];
+ const struct firmware *clm_fw;
void __iomem *regs;
void __iomem *tcm;
u32 ram_base;
@@ -1408,23 +1411,25 @@ static int brcmf_pcie_get_memdump(struct device *dev, void *data, size_t len)
return 0;
}

-static
-int brcmf_pcie_get_fwname(struct device *dev, const char *ext, u8 *fw_name)
+static int brcmf_pcie_get_blob(struct device *dev, const struct firmware **fw,
+ enum brcmf_blob_type type)
{
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
- struct brcmf_fw_request *fwreq;
- struct brcmf_fw_name fwnames[] = {
- { ext, fw_name },
- };
+ struct brcmf_pciedev *buspub = bus_if->bus_priv.pcie;
+ struct brcmf_pciedev_info *devinfo = buspub->devinfo;

- fwreq = brcmf_fw_alloc_request(bus_if->chip, bus_if->chiprev,
- brcmf_pcie_fwnames,
- ARRAY_SIZE(brcmf_pcie_fwnames),
- fwnames, ARRAY_SIZE(fwnames));
- if (!fwreq)
- return -ENOMEM;
+ switch (type) {
+ case BRCMF_BLOB_CLM:
+ *fw = devinfo->clm_fw;
+ devinfo->clm_fw = NULL;
+ break;
+ default:
+ return -ENOENT;
+ }
+
+ if (!*fw)
+ return -ENOENT;

- kfree(fwreq);
return 0;
}

@@ -1470,7 +1475,7 @@ static const struct brcmf_bus_ops brcmf_pcie_bus_ops = {
.wowl_config = brcmf_pcie_wowl_config,
.get_ramsize = brcmf_pcie_get_ramsize,
.get_memdump = brcmf_pcie_get_memdump,
- .get_fwname = brcmf_pcie_get_fwname,
+ .get_blob = brcmf_pcie_get_blob,
.reset = brcmf_pcie_reset,
};

@@ -1755,6 +1760,7 @@ static const struct brcmf_buscore_ops brcmf_pcie_buscore_ops = {

#define BRCMF_PCIE_FW_CODE 0
#define BRCMF_PCIE_FW_NVRAM 1
+#define BRCMF_PCIE_FW_CLM 2

static void brcmf_pcie_setup(struct device *dev, int ret,
struct brcmf_fw_request *fwreq)
@@ -1779,6 +1785,7 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
fw = fwreq->items[BRCMF_PCIE_FW_CODE].binary;
nvram = fwreq->items[BRCMF_PCIE_FW_NVRAM].nv_data.data;
nvram_len = fwreq->items[BRCMF_PCIE_FW_NVRAM].nv_data.len;
+ devinfo->clm_fw = fwreq->items[BRCMF_PCIE_FW_CLM].binary;
kfree(fwreq);

ret = brcmf_chip_get_raminfo(devinfo->ci);
@@ -1855,6 +1862,7 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo)
struct brcmf_fw_name fwnames[] = {
{ ".bin", devinfo->fw_name },
{ ".txt", devinfo->nvram_name },
+ { ".clm_blob", devinfo->clm_name },
};

fwreq = brcmf_fw_alloc_request(devinfo->ci->chip, devinfo->ci->chiprev,
@@ -1867,6 +1875,8 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo)
fwreq->items[BRCMF_PCIE_FW_CODE].type = BRCMF_FW_TYPE_BINARY;
fwreq->items[BRCMF_PCIE_FW_NVRAM].type = BRCMF_FW_TYPE_NVRAM;
fwreq->items[BRCMF_PCIE_FW_NVRAM].flags = BRCMF_FW_REQF_OPTIONAL;
+ fwreq->items[BRCMF_PCIE_FW_CLM].type = BRCMF_FW_TYPE_BINARY;
+ fwreq->items[BRCMF_PCIE_FW_CLM].flags = BRCMF_FW_REQF_OPTIONAL;
fwreq->board_type = devinfo->settings->board_type;
/* NVRAM reserves PCI domain 0 for Broadcom's SDK faked bus */
fwreq->domain_nr = pci_domain_nr(devinfo->pdev->bus) + 1;
@@ -2005,6 +2015,7 @@ brcmf_pcie_remove(struct pci_dev *pdev)
brcmf_pcie_release_ringbuffers(devinfo);
brcmf_pcie_reset_device(devinfo);
brcmf_pcie_release_resource(devinfo);
+ release_firmware(devinfo->clm_fw);

if (devinfo->ci)
brcmf_chip_detach(devinfo->ci);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 5d156e591b35..7466e6fd6eca 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4129,23 +4129,24 @@ brcmf_sdio_watchdog(struct timer_list *t)
}
}

-static
-int brcmf_sdio_get_fwname(struct device *dev, const char *ext, u8 *fw_name)
+static int brcmf_sdio_get_blob(struct device *dev, const struct firmware **fw,
+ enum brcmf_blob_type type)
{
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
- struct brcmf_fw_request *fwreq;
- struct brcmf_fw_name fwnames[] = {
- { ext, fw_name },
- };
+ struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;

- fwreq = brcmf_fw_alloc_request(bus_if->chip, bus_if->chiprev,
- brcmf_sdio_fwnames,
- ARRAY_SIZE(brcmf_sdio_fwnames),
- fwnames, ARRAY_SIZE(fwnames));
- if (!fwreq)
- return -ENOMEM;
+ switch (type) {
+ case BRCMF_BLOB_CLM:
+ *fw = sdiodev->clm_fw;
+ sdiodev->clm_fw = NULL;
+ break;
+ default:
+ return -ENOENT;
+ }
+
+ if (!*fw)
+ return -ENOENT;

- kfree(fwreq);
return 0;
}

@@ -4188,13 +4189,14 @@ static const struct brcmf_bus_ops brcmf_sdio_bus_ops = {
.wowl_config = brcmf_sdio_wowl_config,
.get_ramsize = brcmf_sdio_bus_get_ramsize,
.get_memdump = brcmf_sdio_bus_get_memdump,
- .get_fwname = brcmf_sdio_get_fwname,
+ .get_blob = brcmf_sdio_get_blob,
.debugfs_create = brcmf_sdio_debugfs_create,
.reset = brcmf_sdio_bus_reset
};

#define BRCMF_SDIO_FW_CODE 0
#define BRCMF_SDIO_FW_NVRAM 1
+#define BRCMF_SDIO_FW_CLM 2

static void brcmf_sdio_firmware_callback(struct device *dev, int err,
struct brcmf_fw_request *fwreq)
@@ -4217,6 +4219,7 @@ static void brcmf_sdio_firmware_callback(struct device *dev, int err,
code = fwreq->items[BRCMF_SDIO_FW_CODE].binary;
nvram = fwreq->items[BRCMF_SDIO_FW_NVRAM].nv_data.data;
nvram_len = fwreq->items[BRCMF_SDIO_FW_NVRAM].nv_data.len;
+ sdiod->clm_fw = fwreq->items[BRCMF_SDIO_FW_CLM].binary;
kfree(fwreq);

/* try to download image and nvram to the dongle */
@@ -4415,6 +4418,7 @@ brcmf_sdio_prepare_fw_request(struct brcmf_sdio *bus)
struct brcmf_fw_name fwnames[] = {
{ ".bin", bus->sdiodev->fw_name },
{ ".txt", bus->sdiodev->nvram_name },
+ { ".clm_blob", bus->sdiodev->clm_name },
};

fwreq = brcmf_fw_alloc_request(bus->ci->chip, bus->ci->chiprev,
@@ -4426,6 +4430,8 @@ brcmf_sdio_prepare_fw_request(struct brcmf_sdio *bus)

fwreq->items[BRCMF_SDIO_FW_CODE].type = BRCMF_FW_TYPE_BINARY;
fwreq->items[BRCMF_SDIO_FW_NVRAM].type = BRCMF_FW_TYPE_NVRAM;
+ fwreq->items[BRCMF_SDIO_FW_CLM].type = BRCMF_FW_TYPE_BINARY;
+ fwreq->items[BRCMF_SDIO_FW_CLM].flags = BRCMF_FW_REQF_OPTIONAL;
fwreq->board_type = bus->sdiodev->settings->board_type;

return fwreq;
@@ -4582,6 +4588,8 @@ void brcmf_sdio_remove(struct brcmf_sdio *bus)
if (bus->sdiodev->settings)
brcmf_release_module_param(bus->sdiodev->settings);

+ release_firmware(bus->sdiodev->clm_fw);
+ bus->sdiodev->clm_fw = NULL;
kfree(bus->rxbuf);
kfree(bus->hdrbuf);
kfree(bus);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
index 15d2c02fa3ec..7b74c295e4c9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
@@ -186,9 +186,11 @@ struct brcmf_sdio_dev {
struct sg_table sgtable;
char fw_name[BRCMF_FW_NAME_LEN];
char nvram_name[BRCMF_FW_NAME_LEN];
+ char clm_name[BRCMF_FW_NAME_LEN];
bool wowl_enabled;
enum brcmf_sdiod_state state;
struct brcmf_sdiod_freezer *freezer;
+ const struct firmware *clm_fw;
};

/* sdio core registers */
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 9fb68c2dc7e3..85e18fb9c497 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -1154,24 +1154,11 @@ struct brcmf_usbdev *brcmf_usb_attach(struct brcmf_usbdev_info *devinfo,
return NULL;
}

-static
-int brcmf_usb_get_fwname(struct device *dev, const char *ext, u8 *fw_name)
+static int brcmf_usb_get_blob(struct device *dev, const struct firmware **fw,
+ enum brcmf_blob_type type)
{
- struct brcmf_bus *bus = dev_get_drvdata(dev);
- struct brcmf_fw_request *fwreq;
- struct brcmf_fw_name fwnames[] = {
- { ext, fw_name },
- };
-
- fwreq = brcmf_fw_alloc_request(bus->chip, bus->chiprev,
- brcmf_usb_fwnames,
- ARRAY_SIZE(brcmf_usb_fwnames),
- fwnames, ARRAY_SIZE(fwnames));
- if (!fwreq)
- return -ENOMEM;
-
- kfree(fwreq);
- return 0;
+ /* No blobs for USB devices... */
+ return -ENOENT;
}

static const struct brcmf_bus_ops brcmf_usb_bus_ops = {
@@ -1180,7 +1167,7 @@ static const struct brcmf_bus_ops brcmf_usb_bus_ops = {
.txdata = brcmf_usb_tx,
.txctl = brcmf_usb_tx_ctlpkt,
.rxctl = brcmf_usb_rx_ctlpkt,
- .get_fwname = brcmf_usb_get_fwname,
+ .get_blob = brcmf_usb_get_blob,
};

#define BRCMF_USB_FW_CODE 0
--
2.33.0


2021-12-26 15:37:32

by Hector Martin

[permalink] [raw]
Subject: [PATCH 06/34] brcmfmac: firmware: Support passing in multiple board_types

In order to make use of the multiple alt_path functionality, change
board_type to an array. Bus drivers can pass in a NULL-terminated list
of board type strings to try for the firmware fetch.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/firmware.c | 35 +++++++++++++------
.../broadcom/brcm80211/brcmfmac/firmware.h | 2 +-
.../broadcom/brcm80211/brcmfmac/pcie.c | 7 +++-
.../broadcom/brcm80211/brcmfmac/sdio.c | 4 ++-
4 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index eca5a6df1058..51d5d2b88ee6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -594,26 +594,41 @@ static int brcmf_fw_complete_request(const struct firmware *fw,
return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
}

-static const char **brcm_alt_fw_paths(const char *path, const char *board_type)
+static const char **brcm_alt_fw_paths(const char *path, struct brcmf_fw *fwctx)
{
+ const char **board_types = fwctx->req->board_types;
+ int board_type_count = 0;
+ int i;
char alt_path[BRCMF_FW_NAME_LEN];
char **alt_paths;
const char *suffix;

+ if (!board_types || !board_types[0])
+ return NULL;
+
+ while (*board_types++)
+ board_type_count++;
+
suffix = strrchr(path, '.');
if (!suffix || suffix == path)
return NULL;

- /* strip extension at the end */
- strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
- alt_path[suffix - path] = 0;
+ alt_paths = kzalloc(sizeof(char *) * (board_type_count + 1),
+ GFP_KERNEL);
+
+ board_types = fwctx->req->board_types;
+ for (i = 0; i < board_type_count; i++) {
+ /* strip extension at the end */
+ strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
+ alt_path[suffix - path] = 0;

- strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);
- strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
- strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
+ strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);
+ strlcat(alt_path, board_types[i], BRCMF_FW_NAME_LEN);
+ strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);

- alt_paths = kzalloc(sizeof(char *) * 2, GFP_KERNEL);
- alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
+ alt_paths[i] = kstrdup(alt_path, GFP_KERNEL);
+ brcmf_dbg(TRACE, "FW alt path: %s\n", alt_paths[i]);
+ }

return (const char **)alt_paths;
}
@@ -638,7 +653,7 @@ static int brcmf_fw_request_firmware(const struct firmware **fw,
int ret, i;

/* Files can be board-specific, first try a board-specific path */
- if (fwctx->req->board_type) {
+ if (fwctx->req->board_types) {
const char **alt_paths = brcm_alt_fw_paths(cur->path, fwctx);

if (!alt_paths)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
index e290dec9c53d..d94a1d5be517 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
@@ -66,7 +66,7 @@ struct brcmf_fw_request {
u16 domain_nr;
u16 bus_nr;
u32 n_items;
- const char *board_type;
+ const char **board_types;
struct brcmf_fw_item items[];
};

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 591f870d1e47..8888d6acb7f2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1877,11 +1877,16 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo)
fwreq->items[BRCMF_PCIE_FW_NVRAM].flags = BRCMF_FW_REQF_OPTIONAL;
fwreq->items[BRCMF_PCIE_FW_CLM].type = BRCMF_FW_TYPE_BINARY;
fwreq->items[BRCMF_PCIE_FW_CLM].flags = BRCMF_FW_REQF_OPTIONAL;
- fwreq->board_type = devinfo->settings->board_type;
/* NVRAM reserves PCI domain 0 for Broadcom's SDK faked bus */
fwreq->domain_nr = pci_domain_nr(devinfo->pdev->bus) + 1;
fwreq->bus_nr = devinfo->pdev->bus->number;

+ brcmf_dbg(PCIE, "Board: %s\n", devinfo->settings->board_type);
+ fwreq->board_types = devm_kzalloc(&devinfo->pdev->dev,
+ sizeof(const char *) * 2,
+ GFP_KERNEL);
+ fwreq->board_types[0] = devinfo->settings->board_type;
+
return fwreq;
}

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 7466e6fd6eca..32f457bf02d1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4432,7 +4432,9 @@ brcmf_sdio_prepare_fw_request(struct brcmf_sdio *bus)
fwreq->items[BRCMF_SDIO_FW_NVRAM].type = BRCMF_FW_TYPE_NVRAM;
fwreq->items[BRCMF_SDIO_FW_CLM].type = BRCMF_FW_TYPE_BINARY;
fwreq->items[BRCMF_SDIO_FW_CLM].flags = BRCMF_FW_REQF_OPTIONAL;
- fwreq->board_type = bus->sdiodev->settings->board_type;
+ fwreq->board_types = devm_kzalloc(bus->sdiodev->dev,
+ sizeof(const char *) * 2, GFP_KERNEL);
+ fwreq->board_types[0] = bus->sdiodev->settings->board_type;

return fwreq;
}
--
2.33.0


2021-12-26 15:37:44

by Hector Martin

[permalink] [raw]
Subject: [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information

On Apple platforms, the One Time Programmable ROM in the Broadcom chips
contains information about the specific board design (module, vendor,
version) that is required to select the correct NVRAM file. Parse this
OTP ROM and extract the required strings.

Note that the user OTP offset/size is per-chip. This patch does not add
any chips yet.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/pcie.c | 219 ++++++++++++++++++
include/linux/bcma/bcma_driver_chipcommon.h | 1 +
2 files changed, 220 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 8888d6acb7f2..49cb5254fa6e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -255,6 +255,15 @@ struct brcmf_pcie_core_info {
u32 wrapbase;
};

+#define BRCMF_OTP_MAX_PARAM_LEN 16
+
+struct brcmf_otp_params {
+ char module[BRCMF_OTP_MAX_PARAM_LEN];
+ char vendor[BRCMF_OTP_MAX_PARAM_LEN];
+ char version[BRCMF_OTP_MAX_PARAM_LEN];
+ bool valid;
+};
+
struct brcmf_pciedev_info {
enum brcmf_pcie_state state;
bool in_irq;
@@ -282,6 +291,7 @@ struct brcmf_pciedev_info {
void (*write_ptr)(struct brcmf_pciedev_info *devinfo, u32 mem_offset,
u16 value);
struct brcmf_mp_device *settings;
+ struct brcmf_otp_params otp;
};

struct brcmf_pcie_ringbuf {
@@ -353,6 +363,14 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
static struct brcmf_fw_request *
brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo);

+static u16
+brcmf_pcie_read_reg16(struct brcmf_pciedev_info *devinfo, u32 reg_offset)
+{
+ void __iomem *address = devinfo->regs + reg_offset;
+
+ return ioread16(address);
+}
+
static u32
brcmf_pcie_read_reg32(struct brcmf_pciedev_info *devinfo, u32 reg_offset)
{
@@ -539,6 +557,8 @@ brcmf_pcie_copy_dev_tomem(struct brcmf_pciedev_info *devinfo, u32 mem_offset,
}


+#define READCC32(devinfo, reg) brcmf_pcie_read_reg32(devinfo, \
+ CHIPCREGOFFS(reg))
#define WRITECC32(devinfo, reg, value) brcmf_pcie_write_reg32(devinfo, \
CHIPCREGOFFS(reg), value)

@@ -1758,6 +1778,199 @@ static const struct brcmf_buscore_ops brcmf_pcie_buscore_ops = {
.write32 = brcmf_pcie_buscore_write32,
};

+#define BRCMF_OTP_SYS_VENDOR 0x15
+#define BRCMF_OTP_BRCM_CIS 0x80
+
+#define BRCMF_OTP_VENDOR_HDR 0x00000008
+
+static int
+brcmf_pcie_parse_otp_sys_vendor(struct brcmf_pciedev_info *devinfo,
+ u8 *data, size_t size)
+{
+ int idx = 4;
+ const char *chip_params;
+ const char *module_params;
+ const char *p;
+
+ /* 4-byte header and two empty strings */
+ if (size < 6)
+ return -EINVAL;
+
+ if (get_unaligned_le32(data) != BRCMF_OTP_VENDOR_HDR)
+ return -EINVAL;
+
+ chip_params = &data[idx];
+
+ /* Skip first string, including terminator */
+ idx += strnlen(chip_params, size - idx) + 1;
+ if (idx >= size)
+ return -EINVAL;
+
+ module_params = &data[idx];
+
+ /* Skip to terminator of second string */
+ idx += strnlen(module_params, size - idx);
+ if (idx >= size)
+ return -EINVAL;
+
+ /* At this point both strings are guaranteed NUL-terminated */
+ brcmf_dbg(PCIE, "OTP: chip_params='%s' module_params='%s'\n",
+ chip_params, module_params);
+
+ p = module_params;
+ while (*p) {
+ char tag = *p++;
+ const char *end;
+ size_t len;
+
+ if (tag == ' ') /* Skip extra spaces */
+ continue;
+
+ if (*p++ != '=') /* implicit NUL check */
+ return -EINVAL;
+
+ /* *p might be NUL here, if so end == p and len == 0 */
+ end = strchrnul(p, ' ');
+ len = end - p;
+
+ /* leave 1 byte for NUL in destination string */
+ if (len > (BRCMF_OTP_MAX_PARAM_LEN - 1))
+ return -EINVAL;
+
+ /* Copy len characters plus a NUL terminator */
+ switch (tag) {
+ case 'M':
+ strscpy(devinfo->otp.module, p, len + 1);
+ break;
+ case 'V':
+ strscpy(devinfo->otp.vendor, p, len + 1);
+ break;
+ case 'm':
+ strscpy(devinfo->otp.version, p, len + 1);
+ break;
+ }
+
+ /* Skip to space separator or NUL */
+ p = end;
+ }
+
+ brcmf_dbg(PCIE, "OTP: module=%s vendor=%s version=%s\n",
+ devinfo->otp.module, devinfo->otp.vendor,
+ devinfo->otp.version);
+
+ if (!devinfo->otp.module ||
+ !devinfo->otp.vendor ||
+ !devinfo->otp.version)
+ return -EINVAL;
+
+ devinfo->otp.valid = true;
+ return 0;
+}
+
+static int
+brcmf_pcie_parse_otp(struct brcmf_pciedev_info *devinfo, u8 *otp, size_t size)
+{
+ int p = 0;
+ int ret = -1;
+
+ brcmf_dbg(PCIE, "parse_otp size=%ld\n", size);
+
+ while (p < (size - 1)) {
+ u8 type = otp[p];
+ u8 length = otp[p + 1];
+
+ if (type == 0)
+ break;
+
+ if ((p + 2 + length) > size)
+ break;
+
+ switch (type) {
+ case BRCMF_OTP_SYS_VENDOR:
+ brcmf_dbg(PCIE, "OTP @ 0x%x (0x%x): SYS_VENDOR\n",
+ p, length);
+ ret = brcmf_pcie_parse_otp_sys_vendor(devinfo,
+ &otp[p + 2],
+ length);
+ break;
+ case BRCMF_OTP_BRCM_CIS:
+ brcmf_dbg(PCIE, "OTP @ 0x%x (0x%x): BRCM_CIS\n",
+ p, length);
+ break;
+ default:
+ brcmf_dbg(PCIE, "OTP @ 0x%x (0x%x): Unknown type 0x%x\n",
+ p, length, type);
+ break;
+ }
+
+ p += 2 + length;
+ }
+
+ return ret;
+}
+
+static int brcmf_pcie_read_otp(struct brcmf_pciedev_info *devinfo)
+{
+ const struct pci_dev *pdev = devinfo->pdev;
+ struct brcmf_bus *bus = dev_get_drvdata(&pdev->dev);
+ u32 coreid, base, words, idx, sromctl;
+ u16 *otp;
+ struct brcmf_core *core;
+ int ret;
+
+ switch (devinfo->ci->chip) {
+ default:
+ /* OTP not supported on this chip */
+ return 0;
+ }
+
+ core = brcmf_chip_get_core(devinfo->ci, coreid);
+ if (!core) {
+ brcmf_err(bus, "No OTP core\n");
+ return -ENODEV;
+ }
+
+ if (coreid == BCMA_CORE_CHIPCOMMON) {
+ /* Chips with OTP accessed via ChipCommon need additional
+ * handling to access the OTP
+ */
+ brcmf_pcie_select_core(devinfo, coreid);
+ sromctl = READCC32(devinfo, sromcontrol);
+
+ if (!(sromctl & BCMA_CC_SROM_CONTROL_OTP_PRESENT)) {
+ /* Chip lacks OTP, try without it... */
+ brcmf_err(bus,
+ "OTP unavailable, using default firmware\n");
+ return 0;
+ }
+
+ /* Map OTP to shadow area */
+ WRITECC32(devinfo, sromcontrol,
+ sromctl | BCMA_CC_SROM_CONTROL_OTPSEL);
+ }
+
+ otp = kzalloc(sizeof(u16) * words, GFP_KERNEL);
+
+ /* Map bus window to SROM/OTP shadow area in core */
+ base = brcmf_pcie_buscore_prep_addr(devinfo->pdev, base + core->base);
+
+ brcmf_dbg(PCIE, "OTP data:\n");
+ for (idx = 0; idx < words; idx++) {
+ otp[idx] = brcmf_pcie_read_reg16(devinfo, base + 2 * idx);
+ brcmf_dbg(PCIE, "[%8x] 0x%04x\n", base + 2 * idx, otp[idx]);
+ }
+
+ if (coreid == BCMA_CORE_CHIPCOMMON) {
+ brcmf_pcie_select_core(devinfo, coreid);
+ WRITECC32(devinfo, sromcontrol, sromctl);
+ }
+
+ ret = brcmf_pcie_parse_otp(devinfo, (u8 *)otp, 2 * words);
+ kfree(otp);
+
+ return ret;
+}
+
#define BRCMF_PCIE_FW_CODE 0
#define BRCMF_PCIE_FW_NVRAM 1
#define BRCMF_PCIE_FW_CLM 2
@@ -1958,6 +2171,12 @@ brcmf_pcie_probe(struct pci_dev *pdev, const struct pci_device_id *id)
if (ret)
goto fail_bus;

+ ret = brcmf_pcie_read_otp(devinfo);
+ if (ret) {
+ brcmf_err(bus, "failed to parse OTP\n");
+ goto fail_brcmf;
+ }
+
fwreq = brcmf_pcie_prepare_fw_request(devinfo);
if (!fwreq) {
ret = -ENOMEM;
diff --git a/include/linux/bcma/bcma_driver_chipcommon.h b/include/linux/bcma/bcma_driver_chipcommon.h
index d35b9206096d..c91db7460190 100644
--- a/include/linux/bcma/bcma_driver_chipcommon.h
+++ b/include/linux/bcma/bcma_driver_chipcommon.h
@@ -270,6 +270,7 @@
#define BCMA_CC_SROM_CONTROL_OP_WRDIS 0x40000000
#define BCMA_CC_SROM_CONTROL_OP_WREN 0x60000000
#define BCMA_CC_SROM_CONTROL_OTPSEL 0x00000010
+#define BCMA_CC_SROM_CONTROL_OTP_PRESENT 0x00000020
#define BCMA_CC_SROM_CONTROL_LOCK 0x00000008
#define BCMA_CC_SROM_CONTROL_SIZE_MASK 0x00000006
#define BCMA_CC_SROM_CONTROL_SIZE_1K 0x00000000
--
2.33.0


2021-12-26 15:37:54

by Hector Martin

[permalink] [raw]
Subject: [PATCH 08/34] brcmfmac: of: Fetch Apple properties

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.

The module-instance is hard-coded in per-board DTS files, 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.

The module-instance is used to construct a board_type by prepending it
with "apple,".

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/common.h | 1 +
.../wireless/broadcom/brcm80211/brcmfmac/of.c | 19 ++++++++++++++++++-
2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
index 8b5f49997c8b..d4aa25d646fe 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
@@ -50,6 +50,7 @@ struct brcmf_mp_device {
bool ignore_probe_fail;
struct brcmfmac_pd_cc *country_codes;
const char *board_type;
+ const char *antenna_sku;
union {
struct brcmfmac_sdio_pd sdio;
} bus;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index 513c7e6421b2..453a6cda5abb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -63,14 +63,31 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
{
struct brcmfmac_sdio_pd *sdio = &settings->bus.sdio;
struct device_node *root, *np = dev->of_node;
+ const char *prop;
int irq;
int err;
u32 irqf;
u32 val;

+ /* Apple ARM64 platforms have their own idea of board type, passed in
+ * via the device tree. They also have an antenna SKU parameter
+ */
+ if (!of_property_read_string(np, "apple,module-instance", &prop)) {
+ const char *prefix = "apple,";
+ int len = strlen(prefix) + strlen(prop) + 1;
+ char *board_type = devm_kzalloc(dev, len, GFP_KERNEL);
+
+ strscpy(board_type, prefix, len);
+ strlcat(board_type, prop, len);
+ settings->board_type = board_type;
+ }
+
+ if (!of_property_read_string(np, "apple,antenna-sku", &prop))
+ settings->antenna_sku = devm_kstrdup(dev, prop, GFP_KERNEL);
+
/* Set board-type to the first string of the machine compatible prop */
root = of_find_node_by_path("/");
- if (root) {
+ if (root && !settings->board_type) {
int i, len;
char *board_type;
const char *tmp;
--
2.33.0


2021-12-26 15:38:05

by Hector Martin

[permalink] [raw]
Subject: [PATCH 09/34] brcmfmac: pcie: Perform firmware selection for Apple platforms

On Apple platforms, firmware selection uses the following elements:

Property Example Source
============== ======= ========================
* Chip name 4378 Device ID
* Chip revision B1 OTP
* Platform shikoku DT (ARM64) or ACPI (x86)
* Module type RASP OTP
* Module vendor m OTP
* Module version 6.11 OTP
* Antenna SKU X3 DT (ARM64) or ??? (x86)

In macOS, these firmwares are stored using filenames in this format
under /usr/share/firmware/wifi:

C-4378__s-B1/P-shikoku-X3_M-RASP_V-m__m-6.11.txt

To prepare firmwares for Linux, we rename these to a scheme following
the existing brcmfmac convention:

brcmfmac<chip><lower(rev)>-pcie.apple,<platform>-<mod_type>-\
<mod_vendor>-<mod_version>-<antenna_sku>.txt

The NVRAM uses all the components, while the firmware and CLM blob only
use the chip/revision/platform/antenna_sku:

brcmfmac<chip><lower(rev)>-pcie.apple,<platform>-<antenna_sku>.bin

e.g.

brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11-X3.txt
brcm/brcmfmac4378b1-pcie.apple,shikoku-X3.bin

In addition, since there are over 1000 files in total, many of which are
symlinks or outright duplicates, we deduplicate and prune the firmware
tree to reduce firmware filenames to fewer dimensions. For example, the
shikoku platform (MacBook Air M1 2020) simplifies to just 4 files:

brcm/brcmfmac4378b1-pcie.apple,shikoku.clm_blob
brcm/brcmfmac4378b1-pcie.apple,shikoku.bin
brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m.txt
brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-u.txt

This reduces the total file count to around 170, of which 75 are
symlinks and 95 are regular files: 7 firmware blobs, 27 CLM blobs, and
61 NVRAM config files. We also slightly process NVRAM files to correct
some formatting issues and add a missing default macaddr= property.

To handle this, the driver must try the following path formats when
looking for firmware files:

brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11-X3.txt
brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11.txt
brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m.txt
brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP.txt
brcm/brcmfmac4378b1-pcie.apple,shikoku-X3.txt *
brcm/brcmfmac4378b1-pcie.apple,shikoku.txt

* Not relevant for NVRAM, only for firmware/CLM.

The chip revision nominally comes from OTP on Apple platforms, but it
can be mapped to the PCI revision number, so we ignore the OTP revision
and continue to use the existing PCI revision mechanism to identify chip
revisions, as the driver already does for other chips. Unfortunately,
the mapping is not consistent between different chip types, so this has
to be determined experimentally.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/pcie.c | 68 +++++++++++++++++--
1 file changed, 63 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 49cb5254fa6e..d31f5a668cec 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -2094,11 +2094,69 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo)
fwreq->domain_nr = pci_domain_nr(devinfo->pdev->bus) + 1;
fwreq->bus_nr = devinfo->pdev->bus->number;

- brcmf_dbg(PCIE, "Board: %s\n", devinfo->settings->board_type);
- fwreq->board_types = devm_kzalloc(&devinfo->pdev->dev,
- sizeof(const char *) * 2,
- GFP_KERNEL);
- fwreq->board_types[0] = devinfo->settings->board_type;
+ /* Apple platforms with fancy firmware/NVRAM selection */
+ if (devinfo->settings->board_type &&
+ devinfo->settings->antenna_sku &&
+ devinfo->otp.valid) {
+ char *buf;
+ int len;
+
+ brcmf_dbg(PCIE, "Apple board: %s\n",
+ devinfo->settings->board_type);
+
+ /* Example: apple,shikoku-RASP-m-6.11-X3 */
+ len = (strlen(devinfo->settings->board_type) + 1 +
+ strlen(devinfo->otp.module) + 1 +
+ strlen(devinfo->otp.vendor) + 1 +
+ strlen(devinfo->otp.version) + 1 +
+ strlen(devinfo->settings->antenna_sku) + 1);
+
+ fwreq->board_types = devm_kzalloc(&devinfo->pdev->dev,
+ sizeof(const char *) * 7,
+ GFP_KERNEL);
+
+ /* apple,shikoku */
+ fwreq->board_types[5] = devinfo->settings->board_type;
+
+ buf = devm_kzalloc(&devinfo->pdev->dev, len, GFP_KERNEL);
+
+ strscpy(buf, devinfo->settings->board_type, len);
+ strlcat(buf, "-", len);
+ strlcat(buf, devinfo->settings->antenna_sku, len);
+ /* apple,shikoku-X3 */
+ fwreq->board_types[4] = devm_kstrdup(&devinfo->pdev->dev, buf,
+ GFP_KERNEL);
+
+ strscpy(buf, devinfo->settings->board_type, len);
+ strlcat(buf, "-", len);
+ strlcat(buf, devinfo->otp.module, len);
+ /* apple,shikoku-RASP */
+ fwreq->board_types[3] = devm_kstrdup(&devinfo->pdev->dev, buf,
+ GFP_KERNEL);
+
+ strlcat(buf, "-", len);
+ strlcat(buf, devinfo->otp.vendor, len);
+ /* apple,shikoku-RASP-m */
+ fwreq->board_types[2] = devm_kstrdup(&devinfo->pdev->dev, buf,
+ GFP_KERNEL);
+
+ strlcat(buf, "-", len);
+ strlcat(buf, devinfo->otp.version, len);
+ /* apple,shikoku-RASP-m-6.11 */
+ fwreq->board_types[1] = devm_kstrdup(&devinfo->pdev->dev, buf,
+ GFP_KERNEL);
+
+ strlcat(buf, "-", len);
+ strlcat(buf, devinfo->settings->antenna_sku, len);
+ /* apple,shikoku-RASP-m-6.11-X3 */
+ fwreq->board_types[0] = buf;
+ } else {
+ brcmf_dbg(PCIE, "Board: %s\n", devinfo->settings->board_type);
+ fwreq->board_types = devm_kzalloc(&devinfo->pdev->dev,
+ sizeof(const char *) * 2,
+ GFP_KERNEL);
+ fwreq->board_types[0] = devinfo->settings->board_type;
+ }

return fwreq;
}
--
2.33.0


2021-12-26 15:38:10

by Hector Martin

[permalink] [raw]
Subject: [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr

On Device Tree platforms, it is customary to be able to set the MAC
address via the Device Tree, as it is often stored in system firmware.
This is particularly relevant for Apple ARM64 platforms, where this
information comes from system configuration and passed through by the
bootloader into the DT.

Implement support for this by fetching the platform MAC address and
adding or replacing the macaddr= property in nvram. This becomes the
dongle's default MAC address.

On platforms with an SROM MAC address, this overrides it. On platforms
without one, such as Apple ARM64 devices, this is required for the
firmware to boot (it will fail if it does not have a valid MAC at all).

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/firmware.c | 30 +++++++++++++++++--
1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 51d5d2b88ee6..d3834d5bc9ea 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -21,6 +21,8 @@
#define BRCMF_FW_NVRAM_DEVPATH_LEN 19 /* devpath0=pcie/1/4/ */
#define BRCMF_FW_NVRAM_PCIEDEV_LEN 10 /* pcie/1/4/ + \0 */
#define BRCMF_FW_DEFAULT_BOARDREV "boardrev=0xff"
+#define BRCMF_FW_MACADDR_FMT "macaddr=%pM"
+#define BRCMF_FW_MACADDR_LEN (7 + ETH_ALEN * 3)

enum nvram_parser_state {
IDLE,
@@ -57,6 +59,7 @@ struct nvram_parser {
bool multi_dev_v1;
bool multi_dev_v2;
bool boardrev_found;
+ bool strip_mac;
};

/*
@@ -121,6 +124,10 @@ static enum nvram_parser_state brcmf_nvram_handle_key(struct nvram_parser *nvp)
nvp->multi_dev_v2 = true;
if (strncmp(&nvp->data[nvp->entry], "boardrev", 8) == 0)
nvp->boardrev_found = true;
+ /* strip macaddr if platform MAC overrides */
+ if (nvp->strip_mac &&
+ strncmp(&nvp->data[nvp->entry], "macaddr", 7) == 0)
+ st = COMMENT;
} else if (!is_nvram_char(c) || c == ' ') {
brcmf_dbg(INFO, "warning: ln=%d:col=%d: '=' expected, skip invalid key entry\n",
nvp->line, nvp->column);
@@ -207,6 +214,9 @@ static int brcmf_init_nvram_parser(struct nvram_parser *nvp,
size = BRCMF_FW_MAX_NVRAM_SIZE;
else
size = data_len;
+ /* Add space for properties we may add */
+ size += strlen(BRCMF_FW_DEFAULT_BOARDREV) + 1;
+ size += BRCMF_FW_MACADDR_LEN + 1;
/* Alloc for extra 0 byte + roundup by 4 + length field */
size += 1 + 3 + sizeof(u32);
nvp->nvram = kzalloc(size, GFP_KERNEL);
@@ -366,22 +376,34 @@ static void brcmf_fw_add_defaults(struct nvram_parser *nvp)
nvp->nvram_len++;
}

+static void brcmf_fw_add_macaddr(struct nvram_parser *nvp, u8 *mac)
+{
+ snprintf(&nvp->nvram[nvp->nvram_len], BRCMF_FW_MACADDR_LEN + 1,
+ BRCMF_FW_MACADDR_FMT, mac);
+ nvp->nvram_len += BRCMF_FW_MACADDR_LEN + 1;
+}
+
/* brcmf_nvram_strip :Takes a buffer of "<var>=<value>\n" lines read from a fil
* and ending in a NUL. Removes carriage returns, empty lines, comment lines,
* and converts newlines to NULs. Shortens buffer as needed and pads with NULs.
* End of buffer is completed with token identifying length of buffer.
*/
static void *brcmf_fw_nvram_strip(const u8 *data, size_t data_len,
- u32 *new_length, u16 domain_nr, u16 bus_nr)
+ u32 *new_length, u16 domain_nr, u16 bus_nr,
+ struct device *dev)
{
struct nvram_parser nvp;
u32 pad;
u32 token;
__le32 token_le;
+ u8 mac[ETH_ALEN];

if (brcmf_init_nvram_parser(&nvp, data, data_len) < 0)
return NULL;

+ if (eth_platform_get_mac_address(dev, mac) == 0)
+ nvp.strip_mac = true;
+
while (nvp.pos < data_len) {
nvp.state = nv_parser_states[nvp.state](&nvp);
if (nvp.state == END)
@@ -402,6 +424,9 @@ static void *brcmf_fw_nvram_strip(const u8 *data, size_t data_len,

brcmf_fw_add_defaults(&nvp);

+ if (nvp.strip_mac)
+ brcmf_fw_add_macaddr(&nvp, mac);
+
pad = nvp.nvram_len;
*new_length = roundup(nvp.nvram_len + 1, 4);
while (pad != *new_length) {
@@ -546,7 +571,8 @@ static int brcmf_fw_request_nvram_done(const struct firmware *fw, void *ctx)
if (data)
nvram = brcmf_fw_nvram_strip(data, data_len, &nvram_length,
fwctx->req->domain_nr,
- fwctx->req->bus_nr);
+ fwctx->req->bus_nr,
+ fwctx->dev);

if (free_bcm47xx_nvram)
bcm47xx_nvram_release_contents(data);
--
2.33.0


2021-12-26 15:38:15

by Hector Martin

[permalink] [raw]
Subject: [PATCH 11/34] brcmfmac: msgbuf: Increase RX ring sizes to 1024

Newer chips used on Apple platforms have more than max_rxbufpost greater
than 512, which causes warnings when brcmf_msgbuf_rxbuf_data_fill tries
to put more in the ring than fit. Increase the ring sizes to 1024.

Signed-off-by: Hector Martin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h
index 2e322edbb907..6a849f4a94dd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h
@@ -8,10 +8,10 @@
#ifdef CONFIG_BRCMFMAC_PROTO_MSGBUF

#define BRCMF_H2D_MSGRING_CONTROL_SUBMIT_MAX_ITEM 64
-#define BRCMF_H2D_MSGRING_RXPOST_SUBMIT_MAX_ITEM 512
+#define BRCMF_H2D_MSGRING_RXPOST_SUBMIT_MAX_ITEM 1024
#define BRCMF_D2H_MSGRING_CONTROL_COMPLETE_MAX_ITEM 64
#define BRCMF_D2H_MSGRING_TX_COMPLETE_MAX_ITEM 1024
-#define BRCMF_D2H_MSGRING_RX_COMPLETE_MAX_ITEM 512
+#define BRCMF_D2H_MSGRING_RX_COMPLETE_MAX_ITEM 1024
#define BRCMF_H2D_TXFLOWRING_MAX_ITEM 512

#define BRCMF_H2D_MSGRING_CONTROL_SUBMIT_ITEMSIZE 40
--
2.33.0


2021-12-26 15:38:24

by Hector Martin

[permalink] [raw]
Subject: [PATCH 12/34] brcmfmac: pcie: Fix crashes due to early IRQs

The driver was enabling IRQs before the message processing was
initialized. This could cause IRQs to come in too early and crash the
driver. Instead, move the IRQ enable and hostready to a bus preinit
function, at which point everything is properly initialized.

Fixes: 9e37f045d5e7 ("brcmfmac: Adding PCIe bus layer support.")
Signed-off-by: Hector Martin <[email protected]>
---
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index d31f5a668cec..ffb01872c6a3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1378,6 +1378,18 @@ static void brcmf_pcie_down(struct device *dev)
{
}

+static int brcmf_pcie_preinit(struct device *dev)
+{
+ struct brcmf_bus *bus_if = dev_get_drvdata(dev);
+ struct brcmf_pciedev *buspub = bus_if->bus_priv.pcie;
+
+ brcmf_dbg(PCIE, "Enter\n");
+
+ brcmf_pcie_intr_enable(buspub->devinfo);
+ brcmf_pcie_hostready(buspub->devinfo);
+
+ return 0;
+}

static int brcmf_pcie_tx(struct device *dev, struct sk_buff *skb)
{
@@ -1488,6 +1500,7 @@ static int brcmf_pcie_reset(struct device *dev)
}

static const struct brcmf_bus_ops brcmf_pcie_bus_ops = {
+ .preinit = brcmf_pcie_preinit,
.txdata = brcmf_pcie_tx,
.stop = brcmf_pcie_down,
.txctl = brcmf_pcie_tx_ctlpkt,
@@ -2053,9 +2066,6 @@ static void brcmf_pcie_setup(struct device *dev, int ret,

init_waitqueue_head(&devinfo->mbdata_resp_wait);

- brcmf_pcie_intr_enable(devinfo);
- brcmf_pcie_hostready(devinfo);
-
ret = brcmf_attach(&devinfo->pdev->dev);
if (ret)
goto fail;
--
2.33.0


2021-12-26 15:38:44

by Hector Martin

[permalink] [raw]
Subject: [PATCH 13/34] brcmfmac: pcie: Support PCIe core revisions >= 64

These newer PCIe core revisions include new sets of registers that must
be used instead of the legacy ones. Introduce a brcmf_pcie_reginfo to
hold the specific register offsets and values to use for a given
platform, and change all the register accesses to indirect through it.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/pcie.c | 125 +++++++++++++++---
1 file changed, 105 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index ffb01872c6a3..520de2531e30 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -118,6 +118,12 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
#define BRCMF_PCIE_PCIE2REG_H2D_MAILBOX_0 0x140
#define BRCMF_PCIE_PCIE2REG_H2D_MAILBOX_1 0x144

+#define BRCMF_PCIE_64_PCIE2REG_INTMASK 0xC14
+#define BRCMF_PCIE_64_PCIE2REG_MAILBOXINT 0xC30
+#define BRCMF_PCIE_64_PCIE2REG_MAILBOXMASK 0xC34
+#define BRCMF_PCIE_64_PCIE2REG_H2D_MAILBOX_0 0xA20
+#define BRCMF_PCIE_64_PCIE2REG_H2D_MAILBOX_1 0xA24
+
#define BRCMF_PCIE2_INTA 0x01
#define BRCMF_PCIE2_INTB 0x02

@@ -137,6 +143,8 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
#define BRCMF_PCIE_MB_INT_D2H3_DB0 0x400000
#define BRCMF_PCIE_MB_INT_D2H3_DB1 0x800000

+#define BRCMF_PCIE_MB_INT_FN0 (BRCMF_PCIE_MB_INT_FN0_0 | \
+ BRCMF_PCIE_MB_INT_FN0_1)
#define BRCMF_PCIE_MB_INT_D2H_DB (BRCMF_PCIE_MB_INT_D2H0_DB0 | \
BRCMF_PCIE_MB_INT_D2H0_DB1 | \
BRCMF_PCIE_MB_INT_D2H1_DB0 | \
@@ -146,6 +154,40 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_PCIE_MB_INT_D2H3_DB0 | \
BRCMF_PCIE_MB_INT_D2H3_DB1)

+#define BRCMF_PCIE_64_MB_INT_D2H0_DB0 0x1
+#define BRCMF_PCIE_64_MB_INT_D2H0_DB1 0x2
+#define BRCMF_PCIE_64_MB_INT_D2H1_DB0 0x4
+#define BRCMF_PCIE_64_MB_INT_D2H1_DB1 0x8
+#define BRCMF_PCIE_64_MB_INT_D2H2_DB0 0x10
+#define BRCMF_PCIE_64_MB_INT_D2H2_DB1 0x20
+#define BRCMF_PCIE_64_MB_INT_D2H3_DB0 0x40
+#define BRCMF_PCIE_64_MB_INT_D2H3_DB1 0x80
+#define BRCMF_PCIE_64_MB_INT_D2H4_DB0 0x100
+#define BRCMF_PCIE_64_MB_INT_D2H4_DB1 0x200
+#define BRCMF_PCIE_64_MB_INT_D2H5_DB0 0x400
+#define BRCMF_PCIE_64_MB_INT_D2H5_DB1 0x800
+#define BRCMF_PCIE_64_MB_INT_D2H6_DB0 0x1000
+#define BRCMF_PCIE_64_MB_INT_D2H6_DB1 0x2000
+#define BRCMF_PCIE_64_MB_INT_D2H7_DB0 0x4000
+#define BRCMF_PCIE_64_MB_INT_D2H7_DB1 0x8000
+
+#define BRCMF_PCIE_64_MB_INT_D2H_DB (BRCMF_PCIE_64_MB_INT_D2H0_DB0 | \
+ BRCMF_PCIE_64_MB_INT_D2H0_DB1 | \
+ BRCMF_PCIE_64_MB_INT_D2H1_DB0 | \
+ BRCMF_PCIE_64_MB_INT_D2H1_DB1 | \
+ BRCMF_PCIE_64_MB_INT_D2H2_DB0 | \
+ BRCMF_PCIE_64_MB_INT_D2H2_DB1 | \
+ BRCMF_PCIE_64_MB_INT_D2H3_DB0 | \
+ BRCMF_PCIE_64_MB_INT_D2H3_DB1 | \
+ BRCMF_PCIE_64_MB_INT_D2H4_DB0 | \
+ BRCMF_PCIE_64_MB_INT_D2H4_DB1 | \
+ BRCMF_PCIE_64_MB_INT_D2H5_DB0 | \
+ BRCMF_PCIE_64_MB_INT_D2H5_DB1 | \
+ BRCMF_PCIE_64_MB_INT_D2H6_DB0 | \
+ BRCMF_PCIE_64_MB_INT_D2H6_DB1 | \
+ BRCMF_PCIE_64_MB_INT_D2H7_DB0 | \
+ BRCMF_PCIE_64_MB_INT_D2H7_DB1)
+
#define BRCMF_PCIE_SHARED_VERSION_7 7
#define BRCMF_PCIE_MIN_SHARED_VERSION 5
#define BRCMF_PCIE_MAX_SHARED_VERSION BRCMF_PCIE_SHARED_VERSION_7
@@ -272,6 +314,7 @@ struct brcmf_pciedev_info {
char nvram_name[BRCMF_FW_NAME_LEN];
char clm_name[BRCMF_FW_NAME_LEN];
const struct firmware *clm_fw;
+ const struct brcmf_pcie_reginfo *reginfo;
void __iomem *regs;
void __iomem *tcm;
u32 ram_base;
@@ -358,6 +401,36 @@ static const u32 brcmf_ring_itemsize[BRCMF_NROF_COMMON_MSGRINGS] = {
BRCMF_D2H_MSGRING_RX_COMPLETE_ITEMSIZE
};

+struct brcmf_pcie_reginfo {
+ u32 intmask;
+ u32 mailboxint;
+ u32 mailboxmask;
+ u32 h2d_mailbox_0;
+ u32 h2d_mailbox_1;
+ u32 int_d2h_db;
+ u32 int_fn0;
+};
+
+static const struct brcmf_pcie_reginfo brcmf_reginfo_default = {
+ .intmask = BRCMF_PCIE_PCIE2REG_INTMASK,
+ .mailboxint = BRCMF_PCIE_PCIE2REG_MAILBOXINT,
+ .mailboxmask = BRCMF_PCIE_PCIE2REG_MAILBOXMASK,
+ .h2d_mailbox_0 = BRCMF_PCIE_PCIE2REG_H2D_MAILBOX_0,
+ .h2d_mailbox_1 = BRCMF_PCIE_PCIE2REG_H2D_MAILBOX_1,
+ .int_d2h_db = BRCMF_PCIE_MB_INT_D2H_DB,
+ .int_fn0 = BRCMF_PCIE_MB_INT_FN0,
+};
+
+static const struct brcmf_pcie_reginfo brcmf_reginfo_64 = {
+ .intmask = BRCMF_PCIE_64_PCIE2REG_INTMASK,
+ .mailboxint = BRCMF_PCIE_64_PCIE2REG_MAILBOXINT,
+ .mailboxmask = BRCMF_PCIE_64_PCIE2REG_MAILBOXMASK,
+ .h2d_mailbox_0 = BRCMF_PCIE_64_PCIE2REG_H2D_MAILBOX_0,
+ .h2d_mailbox_1 = BRCMF_PCIE_64_PCIE2REG_H2D_MAILBOX_1,
+ .int_d2h_db = BRCMF_PCIE_64_MB_INT_D2H_DB,
+ .int_fn0 = 0,
+};
+
static void brcmf_pcie_setup(struct device *dev, int ret,
struct brcmf_fw_request *fwreq);
static struct brcmf_fw_request *
@@ -840,30 +913,29 @@ static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info *devinfo,

static void brcmf_pcie_intr_disable(struct brcmf_pciedev_info *devinfo)
{
- brcmf_pcie_write_reg32(devinfo, BRCMF_PCIE_PCIE2REG_MAILBOXMASK, 0);
+ brcmf_pcie_write_reg32(devinfo, devinfo->reginfo->mailboxmask, 0);
}


static void brcmf_pcie_intr_enable(struct brcmf_pciedev_info *devinfo)
{
- brcmf_pcie_write_reg32(devinfo, BRCMF_PCIE_PCIE2REG_MAILBOXMASK,
- BRCMF_PCIE_MB_INT_D2H_DB |
- BRCMF_PCIE_MB_INT_FN0_0 |
- BRCMF_PCIE_MB_INT_FN0_1);
+ brcmf_pcie_write_reg32(devinfo, devinfo->reginfo->mailboxmask,
+ devinfo->reginfo->int_d2h_db |
+ devinfo->reginfo->int_fn0);
}

static void brcmf_pcie_hostready(struct brcmf_pciedev_info *devinfo)
{
if (devinfo->shared.flags & BRCMF_PCIE_SHARED_HOSTRDY_DB1)
brcmf_pcie_write_reg32(devinfo,
- BRCMF_PCIE_PCIE2REG_H2D_MAILBOX_1, 1);
+ devinfo->reginfo->h2d_mailbox_1, 1);
}

static irqreturn_t brcmf_pcie_quick_check_isr(int irq, void *arg)
{
struct brcmf_pciedev_info *devinfo = (struct brcmf_pciedev_info *)arg;

- if (brcmf_pcie_read_reg32(devinfo, BRCMF_PCIE_PCIE2REG_MAILBOXINT)) {
+ if (brcmf_pcie_read_reg32(devinfo, devinfo->reginfo->mailboxint)) {
brcmf_pcie_intr_disable(devinfo);
brcmf_dbg(PCIE, "Enter\n");
return IRQ_WAKE_THREAD;
@@ -878,15 +950,14 @@ static irqreturn_t brcmf_pcie_isr_thread(int irq, void *arg)
u32 status;

devinfo->in_irq = true;
- status = brcmf_pcie_read_reg32(devinfo, BRCMF_PCIE_PCIE2REG_MAILBOXINT);
+ status = brcmf_pcie_read_reg32(devinfo, devinfo->reginfo->mailboxint);
brcmf_dbg(PCIE, "Enter %x\n", status);
if (status) {
- brcmf_pcie_write_reg32(devinfo, BRCMF_PCIE_PCIE2REG_MAILBOXINT,
+ brcmf_pcie_write_reg32(devinfo, devinfo->reginfo->mailboxint,
status);
- if (status & (BRCMF_PCIE_MB_INT_FN0_0 |
- BRCMF_PCIE_MB_INT_FN0_1))
+ if (status & devinfo->reginfo->int_fn0)
brcmf_pcie_handle_mb_data(devinfo);
- if (status & BRCMF_PCIE_MB_INT_D2H_DB) {
+ if (status & devinfo->reginfo->int_d2h_db) {
if (devinfo->state == BRCMFMAC_PCIE_STATE_UP)
brcmf_proto_msgbuf_rx_trigger(
&devinfo->pdev->dev);
@@ -945,8 +1016,8 @@ static void brcmf_pcie_release_irq(struct brcmf_pciedev_info *devinfo)
if (devinfo->in_irq)
brcmf_err(bus, "Still in IRQ (processing) !!!\n");

- status = brcmf_pcie_read_reg32(devinfo, BRCMF_PCIE_PCIE2REG_MAILBOXINT);
- brcmf_pcie_write_reg32(devinfo, BRCMF_PCIE_PCIE2REG_MAILBOXINT, status);
+ status = brcmf_pcie_read_reg32(devinfo, devinfo->reginfo->mailboxint);
+ brcmf_pcie_write_reg32(devinfo, devinfo->reginfo->mailboxint, status);

devinfo->irq_allocated = false;
}
@@ -998,7 +1069,7 @@ static int brcmf_pcie_ring_mb_ring_bell(void *ctx)

brcmf_dbg(PCIE, "RING !\n");
/* Any arbitrary value will do, lets use 1 */
- brcmf_pcie_write_reg32(devinfo, BRCMF_PCIE_PCIE2REG_H2D_MAILBOX_0, 1);
+ brcmf_pcie_write_reg32(devinfo, devinfo->reginfo->h2d_mailbox_0, 1);

return 0;
}
@@ -1760,15 +1831,22 @@ static int brcmf_pcie_buscoreprep(void *ctx)
static int brcmf_pcie_buscore_reset(void *ctx, struct brcmf_chip *chip)
{
struct brcmf_pciedev_info *devinfo = (struct brcmf_pciedev_info *)ctx;
- u32 val;
+ struct brcmf_core *core;
+ u32 val, reg;

devinfo->ci = chip;
brcmf_pcie_reset_device(devinfo);

- val = brcmf_pcie_read_reg32(devinfo, BRCMF_PCIE_PCIE2REG_MAILBOXINT);
+ /* reginfo is not ready yet */
+ core = brcmf_chip_get_core(chip, BCMA_CORE_PCIE2);
+ if (core->rev >= 64)
+ reg = BRCMF_PCIE_64_PCIE2REG_MAILBOXINT;
+ else
+ reg = BRCMF_PCIE_PCIE2REG_MAILBOXINT;
+
+ val = brcmf_pcie_read_reg32(devinfo, reg);
if (val != 0xffffffff)
- brcmf_pcie_write_reg32(devinfo, BRCMF_PCIE_PCIE2REG_MAILBOXINT,
- val);
+ brcmf_pcie_write_reg32(devinfo, reg, val);

return 0;
}
@@ -2179,6 +2257,7 @@ brcmf_pcie_probe(struct pci_dev *pdev, const struct pci_device_id *id)
struct brcmf_pciedev_info *devinfo;
struct brcmf_pciedev *pcie_bus_dev;
struct brcmf_bus *bus;
+ struct brcmf_core *core;

brcmf_dbg(PCIE, "Enter %x:%x\n", pdev->vendor, pdev->device);

@@ -2197,6 +2276,12 @@ brcmf_pcie_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto fail;
}

+ core = brcmf_chip_get_core(devinfo->ci, BCMA_CORE_PCIE2);
+ if (core->rev >= 64)
+ devinfo->reginfo = &brcmf_reginfo_64;
+ else
+ devinfo->reginfo = &brcmf_reginfo_default;
+
pcie_bus_dev = kzalloc(sizeof(*pcie_bus_dev), GFP_KERNEL);
if (pcie_bus_dev == NULL) {
ret = -ENOMEM;
@@ -2365,7 +2450,7 @@ static int brcmf_pcie_pm_leave_D3(struct device *dev)
brcmf_dbg(PCIE, "Enter, dev=%p, bus=%p\n", dev, bus);

/* Check if device is still up and running, if so we are ready */
- if (brcmf_pcie_read_reg32(devinfo, BRCMF_PCIE_PCIE2REG_INTMASK) != 0) {
+ if (brcmf_pcie_read_reg32(devinfo, devinfo->reginfo->intmask) != 0) {
brcmf_dbg(PCIE, "Try to wakeup device....\n");
if (brcmf_pcie_send_mb_data(devinfo, BRCMF_H2D_HOST_D0_INFORM))
goto cleanup;
--
2.33.0


2021-12-26 15:38:50

by Hector Martin

[permalink] [raw]
Subject: [PATCH 14/34] brcmfmac: pcie: Add IDs/properties for BCM4378

This chip is present on Apple M1 (t8103) platforms:

* atlantisb (apple,j274): Mac mini (M1, 2020)
* honshu (apple,j293): MacBook Pro (13-inch, M1, 2020)
* shikoku (apple,j313): MacBook Air (M1, 2020)
* capri (apple,j456): iMac (24-inch, 4x USB-C, M1, 2020)
* santorini (apple,j457): iMac (24-inch, 2x USB-C, M1, 2020)

Signed-off-by: Hector Martin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 8 ++++++++
.../net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 2 ++
3 files changed, 12 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 1ee49f9e325d..56a6f41685c1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -731,6 +731,8 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv *ci)
return 0x160000;
case CY_CC_43752_CHIP_ID:
return 0x170000;
+ case BRCM_CC_4378_CHIP_ID:
+ return 0x352000;
default:
brcmf_err("unknown chip: %s\n", ci->pub.name);
break;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 520de2531e30..40d0fc6fa9ce 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -58,6 +58,7 @@ BRCMF_FW_DEF(4365C, "brcmfmac4365c-pcie");
BRCMF_FW_DEF(4366B, "brcmfmac4366b-pcie");
BRCMF_FW_DEF(4366C, "brcmfmac4366c-pcie");
BRCMF_FW_DEF(4371, "brcmfmac4371-pcie");
+BRCMF_FW_CLM_DEF(4378B1, "brcmfmac4378b1-pcie");

/* firmware config files */
MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.txt");
@@ -87,6 +88,7 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43664_CHIP_ID, 0xFFFFFFF0, 4366C),
BRCMF_FW_ENTRY(BRCM_CC_43666_CHIP_ID, 0xFFFFFFF0, 4366C),
BRCMF_FW_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371),
+ BRCMF_FW_ENTRY(BRCM_CC_4378_CHIP_ID, 0xFFFFFFFF, 4378B1), /* 3 */
};

#define BRCMF_PCIE_FW_UP_TIMEOUT 5000 /* msec */
@@ -2010,6 +2012,11 @@ static int brcmf_pcie_read_otp(struct brcmf_pciedev_info *devinfo)
int ret;

switch (devinfo->ci->chip) {
+ case BRCM_CC_4378_CHIP_ID:
+ coreid = BCMA_CORE_GCI;
+ base = 0x1120;
+ words = 0x170;
+ break;
default:
/* OTP not supported on this chip */
return 0;
@@ -2516,6 +2523,7 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_2G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_5G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4371_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_4378_DEVICE_ID),
{ /* end: all zeroes */ }
};

diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index 9d81320164ce..8f552b53f3bc 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -50,6 +50,7 @@
#define BRCM_CC_43664_CHIP_ID 43664
#define BRCM_CC_43666_CHIP_ID 43666
#define BRCM_CC_4371_CHIP_ID 0x4371
+#define BRCM_CC_4378_CHIP_ID 0x4378
#define CY_CC_4373_CHIP_ID 0x4373
#define CY_CC_43012_CHIP_ID 43012
#define CY_CC_43752_CHIP_ID 43752
@@ -85,6 +86,7 @@
#define BRCM_PCIE_4366_2G_DEVICE_ID 0x43c4
#define BRCM_PCIE_4366_5G_DEVICE_ID 0x43c5
#define BRCM_PCIE_4371_DEVICE_ID 0x440d
+#define BRCM_PCIE_4378_DEVICE_ID 0x4425


/* brcmsmac IDs */
--
2.33.0


2021-12-26 15:39:01

by Hector Martin

[permalink] [raw]
Subject: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties

On DT platforms, the module-instance and antenna-sku-info properties
are passed in the DT. On ACPI platforms, module-instance is passed via
the analogous Apple device property mechanism, while the antenna SKU
info is instead obtained via an ACPI method that grabs it from
non-volatile storage.

Add support for this, to allow proper firmware selection on Apple
platforms.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/Makefile | 2 +
.../broadcom/brcm80211/brcmfmac/acpi.c | 51 +++++++++++++++++++
.../broadcom/brcm80211/brcmfmac/common.c | 1 +
.../broadcom/brcm80211/brcmfmac/common.h | 9 ++++
4 files changed, 63 insertions(+)
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
index 13c13504a6e8..19009eb9db93 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
@@ -47,3 +47,5 @@ brcmfmac-$(CONFIG_OF) += \
of.o
brcmfmac-$(CONFIG_DMI) += \
dmi.o
+brcmfmac-$(CONFIG_ACPI) += \
+ acpi.o
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
new file mode 100644
index 000000000000..3e56dc7a8db2
--- /dev/null
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: ISC
+/*
+ * Copyright The Asahi Linux Contributors
+ */
+
+#include <linux/acpi.h>
+#include "debug.h"
+#include "core.h"
+#include "common.h"
+
+void brcmf_acpi_probe(struct device *dev, enum brcmf_bus_type bus_type,
+ struct brcmf_mp_device *settings)
+{
+ acpi_status status;
+ struct acpi_device *adev = ACPI_COMPANION(dev);
+ const union acpi_object *o;
+ struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL};
+
+ if (!adev)
+ return;
+
+ if (!ACPI_FAILURE(acpi_dev_get_property(adev, "module-instance",
+ ACPI_TYPE_STRING, &o))) {
+ const char *prefix = "apple,";
+ int len = strlen(prefix) + o->string.length + 1;
+ char *board_type = devm_kzalloc(dev, len, GFP_KERNEL);
+
+ strscpy(board_type, prefix, len);
+ strlcat(board_type, o->string.pointer, len);
+ brcmf_dbg(INFO, "ACPI module-instance=%s\n", o->string.pointer);
+ settings->board_type = board_type;
+ } else {
+ brcmf_dbg(INFO, "No ACPI module-instance\n");
+ }
+
+ status = acpi_evaluate_object(adev->handle, "RWCV", NULL, &buf);
+ o = buf.pointer;
+ if (!ACPI_FAILURE(status) && o && o->type == ACPI_TYPE_BUFFER &&
+ o->buffer.length >= 2) {
+ char *antenna_sku = devm_kzalloc(dev, 3, GFP_KERNEL);
+
+ memcpy(antenna_sku, o->buffer.pointer, 2);
+ brcmf_dbg(INFO, "ACPI RWCV data=%*phN antenna-sku=%s\n",
+ (int)o->buffer.length, o->buffer.pointer,
+ antenna_sku);
+
+ settings->antenna_sku = antenna_sku;
+ } else {
+ brcmf_dbg(INFO, "No ACPI antenna-sku\n");
+ }
+}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index b8ed851129b4..c84c48e49fde 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -437,6 +437,7 @@ struct brcmf_mp_device *brcmf_get_module_param(struct device *dev,
/* No platform data for this device, try OF and DMI data */
brcmf_dmi_probe(settings, chip, chiprev);
brcmf_of_probe(dev, bus_type, settings);
+ brcmf_acpi_probe(dev, bus_type, settings);
}
return settings;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
index d4aa25d646fe..a88c4a9310f3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
@@ -73,6 +73,15 @@ static inline void
brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev) {}
#endif

+#ifdef CONFIG_ACPI
+void brcmf_acpi_probe(struct device *dev, enum brcmf_bus_type bus_type,
+ struct brcmf_mp_device *settings);
+#else
+static inline void brcmf_acpi_probe(struct device *dev,
+ enum brcmf_bus_type bus_type,
+ struct brcmf_mp_device *settings) {}
+#endif
+
u8 brcmf_map_prio_to_prec(void *cfg, u8 prio);

u8 brcmf_map_prio_to_aci(void *cfg, u8 prio);
--
2.33.0


2021-12-26 15:39:03

by Hector Martin

[permalink] [raw]
Subject: [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props

The Wi-Fi module in Apple machines has a "module-instance" device
property that specifies the platform type and is used for firmware
selection. Its value is a string, so add support for string values in
acpi_extract_apple_properties().

Signed-off-by: Hector Martin <[email protected]>
---
drivers/acpi/x86/apple.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/x86/apple.c b/drivers/acpi/x86/apple.c
index c285c91a5e9c..71b8f103ab0f 100644
--- a/drivers/acpi/x86/apple.c
+++ b/drivers/acpi/x86/apple.c
@@ -70,13 +70,16 @@ void acpi_extract_apple_properties(struct acpi_device *adev)

if ( key->type != ACPI_TYPE_STRING ||
(val->type != ACPI_TYPE_INTEGER &&
- val->type != ACPI_TYPE_BUFFER))
+ val->type != ACPI_TYPE_BUFFER &&
+ val->type != ACPI_TYPE_STRING))
continue; /* skip invalid properties */

__set_bit(i, valid);
newsize += key->string.length + 1;
if ( val->type == ACPI_TYPE_BUFFER)
newsize += val->buffer.length;
+ else if (val->type == ACPI_TYPE_STRING)
+ newsize += val->string.length + 1;
}

numvalid = bitmap_weight(valid, numprops);
@@ -118,6 +121,12 @@ void acpi_extract_apple_properties(struct acpi_device *adev)
newprops[v].type = val->type;
if (val->type == ACPI_TYPE_INTEGER) {
newprops[v].integer.value = val->integer.value;
+ } else if (val->type == ACPI_TYPE_STRING) {
+ newprops[v].string.length = val->string.length;
+ newprops[v].string.pointer = free_space;
+ memcpy(free_space, val->string.pointer,
+ val->string.length);
+ free_space += val->string.length + 1;
} else {
newprops[v].buffer.length = val->buffer.length;
newprops[v].buffer.pointer = free_space;
--
2.33.0


2021-12-26 15:39:04

by Hector Martin

[permalink] [raw]
Subject: [PATCH 17/34] brcmfmac: pcie: Provide a buffer of random bytes to the device

Newer Apple firmwares on chipsets without a hardware RNG require the
host to provide a buffer of 256 random bytes to the device on
initialization. This buffer is present immediately before NVRAM,
suffixed by a footer containing a magic number and the buffer length.

This won't affect chips/firmwares that do not use this feature, so do it
unconditionally.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/pcie.c | 30 +++++++++++++++++++
1 file changed, 30 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 40d0fc6fa9ce..feeaa3e06853 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -12,6 +12,7 @@
#include <linux/interrupt.h>
#include <linux/bcma/bcma.h>
#include <linux/sched.h>
+#include <linux/random.h>
#include <asm/unaligned.h>

#include <soc.h>
@@ -1662,6 +1663,13 @@ brcmf_pcie_init_share_ram_info(struct brcmf_pciedev_info *devinfo,
return 0;
}

+struct brcmf_random_seed_footer {
+ __le32 length;
+ __le32 magic;
+};
+
+#define BRCMF_RANDOM_SEED_MAGIC 0xfeedc0de
+#define BRCMF_RANDOM_SEED_LENGTH 0x100

static int brcmf_pcie_download_fw_nvram(struct brcmf_pciedev_info *devinfo,
const struct firmware *fw, void *nvram,
@@ -1693,11 +1701,33 @@ static int brcmf_pcie_download_fw_nvram(struct brcmf_pciedev_info *devinfo,
brcmf_pcie_write_ram32(devinfo, devinfo->ci->ramsize - 4, 0);

if (nvram) {
+ size_t rand_len = BRCMF_RANDOM_SEED_LENGTH;
+ struct brcmf_random_seed_footer footer = {
+ .length = cpu_to_le32(rand_len),
+ .magic = cpu_to_le32(BRCMF_RANDOM_SEED_MAGIC),
+ };
+ void *randbuf;
+
brcmf_dbg(PCIE, "Download NVRAM %s\n", devinfo->nvram_name);
address = devinfo->ci->rambase + devinfo->ci->ramsize -
nvram_len;
brcmf_pcie_copy_mem_todev(devinfo, address, nvram, nvram_len);
brcmf_fw_nvram_free(nvram);
+
+ /* Some Apple chips/firmwares expect a buffer of random data
+ * to be present before NVRAM
+ */
+ brcmf_dbg(PCIE, "Download random seed\n");
+
+ address -= sizeof(footer);
+ brcmf_pcie_copy_mem_todev(devinfo, address, &footer,
+ sizeof(footer));
+
+ address -= rand_len;
+ randbuf = kzalloc(rand_len, GFP_KERNEL);
+ get_random_bytes(randbuf, rand_len);
+ brcmf_pcie_copy_mem_todev(devinfo, address, randbuf, rand_len);
+ kfree(randbuf);
} else {
brcmf_dbg(PCIE, "No matching NVRAM file found %s\n",
devinfo->nvram_name);
--
2.33.0


2021-12-26 15:39:17

by Hector Martin

[permalink] [raw]
Subject: [PATCH 18/34] brcmfmac: pcie: Add IDs/properties for BCM4355

This chip is present on at least these Apple T2 Macs:

* hawaii: MacBook Air 13" (Late 2018)
* hawaii: MacBook Air 13" (True Tone, 2019)

Signed-off-by: Hector Martin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 8 ++++++++
.../net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 2 ++
3 files changed, 11 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 56a6f41685c1..fdff7f5fc34e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -726,6 +726,7 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv *ci)
return 0x200000;
case BRCM_CC_4359_CHIP_ID:
return (ci->pub.chiprev < 9) ? 0x180000 : 0x160000;
+ case BRCM_CC_4355_CHIP_ID:
case BRCM_CC_4364_CHIP_ID:
case CY_CC_4373_CHIP_ID:
return 0x160000;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index feeaa3e06853..ce61b78bd42d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -49,6 +49,7 @@ enum brcmf_pcie_state {
BRCMF_FW_DEF(43602, "brcmfmac43602-pcie");
BRCMF_FW_DEF(4350, "brcmfmac4350-pcie");
BRCMF_FW_DEF(4350C, "brcmfmac4350c2-pcie");
+BRCMF_FW_CLM_DEF(4355C1, "brcmfmac4355c1-pcie");
BRCMF_FW_CLM_DEF(4356, "brcmfmac4356-pcie");
BRCMF_FW_CLM_DEF(43570, "brcmfmac43570-pcie");
BRCMF_FW_DEF(4358, "brcmfmac4358-pcie");
@@ -75,6 +76,7 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C),
BRCMF_FW_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350),
BRCMF_FW_ENTRY(BRCM_CC_43525_CHIP_ID, 0xFFFFFFF0, 4365C),
+ BRCMF_FW_ENTRY(BRCM_CC_4355_CHIP_ID, 0xFFFFFFFF, 4355C1), /* 12 */
BRCMF_FW_ENTRY(BRCM_CC_4356_CHIP_ID, 0xFFFFFFFF, 4356),
BRCMF_FW_ENTRY(BRCM_CC_43567_CHIP_ID, 0xFFFFFFFF, 43570),
BRCMF_FW_ENTRY(BRCM_CC_43569_CHIP_ID, 0xFFFFFFFF, 43570),
@@ -2042,6 +2044,11 @@ static int brcmf_pcie_read_otp(struct brcmf_pciedev_info *devinfo)
int ret;

switch (devinfo->ci->chip) {
+ case BRCM_CC_4355_CHIP_ID:
+ coreid = BCMA_CORE_CHIPCOMMON;
+ base = 0x8c0;
+ words = 0xb2;
+ break;
case BRCM_CC_4378_CHIP_ID:
coreid = BCMA_CORE_GCI;
base = 0x1120;
@@ -2535,6 +2542,7 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_4350_DEVICE_ID),
BRCMF_PCIE_DEVICE_SUB(0x4355, BRCM_PCIE_VENDOR_ID_BROADCOM, 0x4355),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4354_RAW_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_4355_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4356_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43567_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_DEVICE_ID),
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index 8f552b53f3bc..9636ab4dd17f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -36,6 +36,7 @@
#define BRCM_CC_4350_CHIP_ID 0x4350
#define BRCM_CC_43525_CHIP_ID 43525
#define BRCM_CC_4354_CHIP_ID 0x4354
+#define BRCM_CC_4355_CHIP_ID 0x4355
#define BRCM_CC_4356_CHIP_ID 0x4356
#define BRCM_CC_43566_CHIP_ID 43566
#define BRCM_CC_43567_CHIP_ID 43567
@@ -69,6 +70,7 @@
#define BRCM_PCIE_4350_DEVICE_ID 0x43a3
#define BRCM_PCIE_4354_DEVICE_ID 0x43df
#define BRCM_PCIE_4354_RAW_DEVICE_ID 0x4354
+#define BRCM_PCIE_4355_DEVICE_ID 0x43dc
#define BRCM_PCIE_4356_DEVICE_ID 0x43ec
#define BRCM_PCIE_43567_DEVICE_ID 0x43d3
#define BRCM_PCIE_43570_DEVICE_ID 0x43d9
--
2.33.0


2021-12-26 15:39:28

by Hector Martin

[permalink] [raw]
Subject: [PATCH 19/34] brcmfmac: pcie: Add IDs/properties for BCM4377

This chip is present on at least these Apple T2 Macs:

* tahiti: MacBook Pro 13" (2020, 2 TB3)
* formosa: MacBook Pro 13" (Touch/2019)
* fiji: MacBook Air 13" (Scissor, 2020)

Signed-off-by: Hector Martin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 ++++
drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 2 ++
3 files changed, 7 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index fdff7f5fc34e..73ab96968ac6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -731,6 +731,7 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv *ci)
case CY_CC_4373_CHIP_ID:
return 0x160000;
case CY_CC_43752_CHIP_ID:
+ case BRCM_CC_4377_CHIP_ID:
return 0x170000;
case BRCM_CC_4378_CHIP_ID:
return 0x352000;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index ce61b78bd42d..a89973c0ee79 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -60,6 +60,7 @@ BRCMF_FW_DEF(4365C, "brcmfmac4365c-pcie");
BRCMF_FW_DEF(4366B, "brcmfmac4366b-pcie");
BRCMF_FW_DEF(4366C, "brcmfmac4366c-pcie");
BRCMF_FW_DEF(4371, "brcmfmac4371-pcie");
+BRCMF_FW_CLM_DEF(4377B3, "brcmfmac4377b3-pcie");
BRCMF_FW_CLM_DEF(4378B1, "brcmfmac4378b1-pcie");

/* firmware config files */
@@ -91,6 +92,7 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43664_CHIP_ID, 0xFFFFFFF0, 4366C),
BRCMF_FW_ENTRY(BRCM_CC_43666_CHIP_ID, 0xFFFFFFF0, 4366C),
BRCMF_FW_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371),
+ BRCMF_FW_ENTRY(BRCM_CC_4377_CHIP_ID, 0xFFFFFFFF, 4377B3), /* 4 */
BRCMF_FW_ENTRY(BRCM_CC_4378_CHIP_ID, 0xFFFFFFFF, 4378B1), /* 3 */
};

@@ -2049,6 +2051,7 @@ static int brcmf_pcie_read_otp(struct brcmf_pciedev_info *devinfo)
base = 0x8c0;
words = 0xb2;
break;
+ case BRCM_CC_4377_CHIP_ID:
case BRCM_CC_4378_CHIP_ID:
coreid = BCMA_CORE_GCI;
base = 0x1120;
@@ -2561,6 +2564,7 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_2G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_5G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4371_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_4377_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4378_DEVICE_ID),
{ /* end: all zeroes */ }
};
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index 9636ab4dd17f..54d7ec515e1d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -51,6 +51,7 @@
#define BRCM_CC_43664_CHIP_ID 43664
#define BRCM_CC_43666_CHIP_ID 43666
#define BRCM_CC_4371_CHIP_ID 0x4371
+#define BRCM_CC_4377_CHIP_ID 0x4377
#define BRCM_CC_4378_CHIP_ID 0x4378
#define CY_CC_4373_CHIP_ID 0x4373
#define CY_CC_43012_CHIP_ID 43012
@@ -88,6 +89,7 @@
#define BRCM_PCIE_4366_2G_DEVICE_ID 0x43c4
#define BRCM_PCIE_4366_5G_DEVICE_ID 0x43c5
#define BRCM_PCIE_4371_DEVICE_ID 0x440d
+#define BRCM_PCIE_4377_DEVICE_ID 0x4488
#define BRCM_PCIE_4378_DEVICE_ID 0x4425


--
2.33.0


2021-12-26 15:39:37

by Hector Martin

[permalink] [raw]
Subject: [PATCH 20/34] brcmfmac: pcie: Perform correct BCM4364 firmware selection

This chip exists in two revisions (B2=r3 and B3=r4) on different
platforms, and was added without regard to doing proper firmware
selection or differentiating between them. Fix this to have proper
per-revision firmwares and support Apple NVRAM selection.

Revision B2 is present on at least these Apple T2 Macs:

kauai: MacBook Pro 15" (Touch/2018-2019)
maui: MacBook Pro 13" (Touch/2018-2019)
lanai: Mac mini (Late 2018)
ekans: iMac Pro 27" (5K, Late 2017)

And these non-T2 Macs:

nihau: iMac 27" (5K, 2019)

Revision B3 is present on at least these Apple T2 Macs:

bali: MacBook Pro 16" (2019)
trinidad: MacBook Pro 13" (2020, 4 TB3)
borneo: MacBook Pro 16" (2019, 5600M)
kahana: Mac Pro (2019)
kahana: Mac Pro (2019, Rack)
hanauma: iMac 27" (5K, 2020)
kure: iMac 27" (5K, 2020, 5700/XT)

Fixes: 24f0bd136264 ("brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2")
Signed-off-by: Hector Martin <[email protected]>
---
.../net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index a89973c0ee79..b94c68bf9d28 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -54,7 +54,8 @@ BRCMF_FW_CLM_DEF(4356, "brcmfmac4356-pcie");
BRCMF_FW_CLM_DEF(43570, "brcmfmac43570-pcie");
BRCMF_FW_DEF(4358, "brcmfmac4358-pcie");
BRCMF_FW_DEF(4359, "brcmfmac4359-pcie");
-BRCMF_FW_DEF(4364, "brcmfmac4364-pcie");
+BRCMF_FW_CLM_DEF(4364B2, "brcmfmac4364b2-pcie");
+BRCMF_FW_CLM_DEF(4364B3, "brcmfmac4364b3-pcie");
BRCMF_FW_DEF(4365B, "brcmfmac4365b-pcie");
BRCMF_FW_DEF(4365C, "brcmfmac4365c-pcie");
BRCMF_FW_DEF(4366B, "brcmfmac4366b-pcie");
@@ -84,7 +85,8 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43570_CHIP_ID, 0xFFFFFFFF, 43570),
BRCMF_FW_ENTRY(BRCM_CC_4358_CHIP_ID, 0xFFFFFFFF, 4358),
BRCMF_FW_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359),
- BRCMF_FW_ENTRY(BRCM_CC_4364_CHIP_ID, 0xFFFFFFFF, 4364),
+ BRCMF_FW_ENTRY(BRCM_CC_4364_CHIP_ID, 0x0000000F, 4364B2), /* 3 */
+ BRCMF_FW_ENTRY(BRCM_CC_4364_CHIP_ID, 0xFFFFFFF0, 4364B3), /* 4 */
BRCMF_FW_ENTRY(BRCM_CC_4365_CHIP_ID, 0x0000000F, 4365B),
BRCMF_FW_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFFFFFF0, 4365C),
BRCMF_FW_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366B),
@@ -2051,6 +2053,11 @@ static int brcmf_pcie_read_otp(struct brcmf_pciedev_info *devinfo)
base = 0x8c0;
words = 0xb2;
break;
+ case BRCM_CC_4364_CHIP_ID:
+ coreid = BCMA_CORE_CHIPCOMMON;
+ base = 0x8c0;
+ words = 0x1a0;
+ break;
case BRCM_CC_4377_CHIP_ID:
case BRCM_CC_4378_CHIP_ID:
coreid = BCMA_CORE_GCI;
--
2.33.0


2021-12-26 15:39:51

by Hector Martin

[permalink] [raw]
Subject: [PATCH 22/34] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks

BCM4387 has trailing odd-sized blocks as part of TCM which have
their size described as a multiple of 1024 instead of 8192. Handle this
so we can compute the TCM size properly.

Signed-off-by: Hector Martin <[email protected]>
---
.../wireless/broadcom/brcm80211/brcmfmac/chip.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 713546cebd5a..cfa93e3ef1a1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -212,8 +212,8 @@ struct sbsocramregs {
#define ARMCR4_TCBANB_MASK 0xf
#define ARMCR4_TCBANB_SHIFT 0

-#define ARMCR4_BSZ_MASK 0x3f
-#define ARMCR4_BSZ_MULT 8192
+#define ARMCR4_BSZ_MASK 0x7f
+#define ARMCR4_BLK_1K_MASK 0x200

struct brcmf_core_priv {
struct brcmf_core pub;
@@ -675,7 +675,8 @@ static u32 brcmf_chip_sysmem_ramsize(struct brcmf_core_priv *sysmem)
}

/** Return the TCM-RAM size of the ARMCR4 core. */
-static u32 brcmf_chip_tcm_ramsize(struct brcmf_core_priv *cr4)
+static u32 brcmf_chip_tcm_ramsize(struct brcmf_chip_priv *ci,
+ struct brcmf_core_priv *cr4)
{
u32 corecap;
u32 memsize = 0;
@@ -683,6 +684,7 @@ static u32 brcmf_chip_tcm_ramsize(struct brcmf_core_priv *cr4)
u32 nbb;
u32 totb;
u32 bxinfo;
+ u32 blksize;
u32 idx;

corecap = brcmf_chip_core_read32(cr4, ARMCR4_CAP);
@@ -694,7 +696,12 @@ static u32 brcmf_chip_tcm_ramsize(struct brcmf_core_priv *cr4)
for (idx = 0; idx < totb; idx++) {
brcmf_chip_core_write32(cr4, ARMCR4_BANKIDX, idx);
bxinfo = brcmf_chip_core_read32(cr4, ARMCR4_BANKINFO);
- memsize += ((bxinfo & ARMCR4_BSZ_MASK) + 1) * ARMCR4_BSZ_MULT;
+ if (bxinfo & ARMCR4_BLK_1K_MASK)
+ blksize = 1024;
+ else
+ blksize = 8192;
+
+ memsize += ((bxinfo & ARMCR4_BSZ_MASK) + 1) * blksize;
}

return memsize;
@@ -752,7 +759,7 @@ int brcmf_chip_get_raminfo(struct brcmf_chip *pub)
mem = brcmf_chip_get_core(&ci->pub, BCMA_CORE_ARM_CR4);
if (mem) {
mem_core = container_of(mem, struct brcmf_core_priv, pub);
- ci->pub.ramsize = brcmf_chip_tcm_ramsize(mem_core);
+ ci->pub.ramsize = brcmf_chip_tcm_ramsize(ci, mem_core);
ci->pub.rambase = brcmf_chip_tcm_rambase(ci);
if (ci->pub.rambase == INVALID_RAMBASE) {
brcmf_err("RAM base not provided with ARM CR4 core\n");
--
2.33.0


2021-12-26 15:39:55

by Hector Martin

[permalink] [raw]
Subject: [PATCH 23/34] brcmfmac: cfg80211: Add support for scan params v2

This new API version is required for at least the BCM4387 firmware. Add
support for it, with a fallback to the v1 API.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 113 ++++++++++++++----
.../broadcom/brcm80211/brcmfmac/feature.c | 1 +
.../broadcom/brcm80211/brcmfmac/feature.h | 4 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 49 +++++++-
4 files changed, 145 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index fb727778312c..71e932a8302c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -769,12 +769,50 @@ void brcmf_set_mpc(struct brcmf_if *ifp, int mpc)
}
}

+static void brcmf_escan_prep(struct brcmf_cfg80211_info *cfg,
+ struct brcmf_scan_params_v2_le *params_le,
+ struct cfg80211_scan_request *request);
+
+static void brcmf_scan_params_v2_to_v1(struct brcmf_scan_params_v2_le *params_v2_le,
+ struct brcmf_scan_params_le *params_le)
+{
+ size_t params_size;
+ u32 ch;
+ int n_channels, n_ssids;
+
+ memcpy(&params_le->ssid_le, &params_v2_le->ssid_le,
+ sizeof(params_le->ssid_le));
+ memcpy(&params_le->bssid, &params_v2_le->bssid,
+ sizeof(params_le->bssid));
+
+ params_le->bss_type = params_v2_le->bss_type;
+ params_le->scan_type = params_v2_le->scan_type;
+ params_le->nprobes = params_v2_le->nprobes;
+ params_le->active_time = params_v2_le->active_time;
+ params_le->passive_time = params_v2_le->passive_time;
+ params_le->home_time = params_v2_le->home_time;
+ params_le->channel_num = params_v2_le->channel_num;
+
+ ch = le32_to_cpu(params_v2_le->channel_num);
+ n_channels = ch & BRCMF_SCAN_PARAMS_COUNT_MASK;
+ n_ssids = ch >> BRCMF_SCAN_PARAMS_NSSID_SHIFT;
+
+ params_size = sizeof(u16) * n_channels;
+ if (n_ssids > 0) {
+ params_size = roundup(params_size, sizeof(u32));
+ params_size += sizeof(struct brcmf_ssid_le) * n_ssids;
+ }
+
+ memcpy(&params_le->channel_list[0],
+ &params_v2_le->channel_list[0], params_size);
+}
+
s32 brcmf_notify_escan_complete(struct brcmf_cfg80211_info *cfg,
struct brcmf_if *ifp, bool aborted,
bool fw_abort)
{
struct brcmf_pub *drvr = cfg->pub;
- struct brcmf_scan_params_le params_le;
+ struct brcmf_scan_params_v2_le params_v2_le;
struct cfg80211_scan_request *scan_request;
u64 reqid;
u32 bucket;
@@ -793,20 +831,23 @@ s32 brcmf_notify_escan_complete(struct brcmf_cfg80211_info *cfg,
if (fw_abort) {
/* Do a scan abort to stop the driver's scan engine */
brcmf_dbg(SCAN, "ABORT scan in firmware\n");
- memset(&params_le, 0, sizeof(params_le));
- eth_broadcast_addr(params_le.bssid);
- params_le.bss_type = DOT11_BSSTYPE_ANY;
- params_le.scan_type = 0;
- params_le.channel_num = cpu_to_le32(1);
- params_le.nprobes = cpu_to_le32(1);
- params_le.active_time = cpu_to_le32(-1);
- params_le.passive_time = cpu_to_le32(-1);
- params_le.home_time = cpu_to_le32(-1);
- /* Scan is aborted by setting channel_list[0] to -1 */
- params_le.channel_list[0] = cpu_to_le16(-1);
+
+ brcmf_escan_prep(cfg, &params_v2_le, NULL);
+
/* E-Scan (or anyother type) can be aborted by SCAN */
- err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SCAN,
- &params_le, sizeof(params_le));
+ if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_SCAN_V2)) {
+ err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SCAN,
+ &params_v2_le,
+ sizeof(params_v2_le));
+ } else {
+ struct brcmf_scan_params_le params_le;
+
+ brcmf_scan_params_v2_to_v1(&params_v2_le, &params_le);
+ err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SCAN,
+ &params_le,
+ sizeof(params_le));
+ }
+
if (err)
bphy_err(drvr, "Scan abort failed\n");
}
@@ -1026,7 +1067,7 @@ brcmf_cfg80211_change_iface(struct wiphy *wiphy, struct net_device *ndev,
}

static void brcmf_escan_prep(struct brcmf_cfg80211_info *cfg,
- struct brcmf_scan_params_le *params_le,
+ struct brcmf_scan_params_v2_le *params_le,
struct cfg80211_scan_request *request)
{
u32 n_ssids;
@@ -1035,9 +1076,14 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info *cfg,
s32 offset;
u16 chanspec;
char *ptr;
+ int length;
struct brcmf_ssid_le ssid_le;

eth_broadcast_addr(params_le->bssid);
+
+ length = BRCMF_SCAN_PARAMS_V2_FIXED_SIZE;
+
+ params_le->version = BRCMF_SCAN_PARAMS_VERSION_V2;
params_le->bss_type = DOT11_BSSTYPE_ANY;
params_le->scan_type = BRCMF_SCANTYPE_ACTIVE;
params_le->channel_num = 0;
@@ -1047,6 +1093,15 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info *cfg,
params_le->home_time = cpu_to_le32(-1);
memset(&params_le->ssid_le, 0, sizeof(params_le->ssid_le));

+ /* Scan abort */
+ if (!request) {
+ length += sizeof(u16);
+ params_le->channel_num = cpu_to_le32(1);
+ params_le->channel_list[0] = cpu_to_le16(-1);
+ params_le->length = cpu_to_le16(length);
+ return;
+ }
+
n_ssids = request->n_ssids;
n_channels = request->n_channels;

@@ -1054,6 +1109,7 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info *cfg,
brcmf_dbg(SCAN, "### List of channelspecs to scan ### %d\n",
n_channels);
if (n_channels > 0) {
+ length += roundup(sizeof(u16) * n_channels, sizeof(u32));
for (i = 0; i < n_channels; i++) {
chanspec = channel_to_chanspec(&cfg->d11inf,
request->channels[i]);
@@ -1064,12 +1120,14 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info *cfg,
} else {
brcmf_dbg(SCAN, "Scanning all channels\n");
}
+
/* Copy ssid array if applicable */
brcmf_dbg(SCAN, "### List of SSIDs to scan ### %d\n", n_ssids);
if (n_ssids > 0) {
- offset = offsetof(struct brcmf_scan_params_le, channel_list) +
+ offset = offsetof(struct brcmf_scan_params_v2_le, channel_list) +
n_channels * sizeof(u16);
offset = roundup(offset, sizeof(u32));
+ length += sizeof(ssid_le) * n_ssids,
ptr = (char *)params_le + offset;
for (i = 0; i < n_ssids; i++) {
memset(&ssid_le, 0, sizeof(ssid_le));
@@ -1089,6 +1147,7 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info *cfg,
brcmf_dbg(SCAN, "Performing passive scan\n");
params_le->scan_type = BRCMF_SCANTYPE_PASSIVE;
}
+ params_le->length = cpu_to_le16(length);
/* Adding mask to channel numbers */
params_le->channel_num =
cpu_to_le32((n_ssids << BRCMF_SCAN_PARAMS_NSSID_SHIFT) |
@@ -1100,8 +1159,8 @@ brcmf_run_escan(struct brcmf_cfg80211_info *cfg, struct brcmf_if *ifp,
struct cfg80211_scan_request *request)
{
struct brcmf_pub *drvr = cfg->pub;
- s32 params_size = BRCMF_SCAN_PARAMS_FIXED_SIZE +
- offsetof(struct brcmf_escan_params_le, params_le);
+ s32 params_size = BRCMF_SCAN_PARAMS_V2_FIXED_SIZE +
+ offsetof(struct brcmf_escan_params_le, params_v2_le);
struct brcmf_escan_params_le *params;
s32 err = 0;

@@ -1121,8 +1180,22 @@ brcmf_run_escan(struct brcmf_cfg80211_info *cfg, struct brcmf_if *ifp,
goto exit;
}
BUG_ON(params_size + sizeof("escan") >= BRCMF_DCMD_MEDLEN);
- brcmf_escan_prep(cfg, &params->params_le, request);
- params->version = cpu_to_le32(BRCMF_ESCAN_REQ_VERSION);
+ brcmf_escan_prep(cfg, &params->params_v2_le, request);
+
+ params->version = cpu_to_le32(BRCMF_ESCAN_REQ_VERSION_V2);
+
+ if (!brcmf_feat_is_enabled(ifp, BRCMF_FEAT_SCAN_V2)) {
+ struct brcmf_escan_params_le *params_v1;
+
+ params_size -= BRCMF_SCAN_PARAMS_V2_FIXED_SIZE;
+ params_size += BRCMF_SCAN_PARAMS_FIXED_SIZE;
+ params_v1 = kzalloc(params_size, GFP_KERNEL);
+ params_v1->version = cpu_to_le32(BRCMF_ESCAN_REQ_VERSION);
+ brcmf_scan_params_v2_to_v1(&params->params_v2_le, &params_v1->params_le);
+ kfree(params);
+ params = params_v1;
+ }
+
params->action = cpu_to_le16(WL_ESCAN_ACTION_START);
params->sync_id = cpu_to_le16(0x1234);

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index 7c68d9849324..d0fada88f0f0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -287,6 +287,7 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
ifp->drvr->feat_flags |= BIT(BRCMF_FEAT_SCAN_RANDOM_MAC);

brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_FWSUP, "sup_wpa");
+ brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_SCAN_V2, "scan_ver");

if (drvr->settings->feature_disable) {
brcmf_dbg(INFO, "Features: 0x%02x, disable: 0x%02x\n",
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
index d1f4257af696..9d098a068d13 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
@@ -29,6 +29,7 @@
* DOT11H: firmware supports 802.11h
* SAE: simultaneous authentication of equals
* FWAUTH: Firmware authenticator
+ * SCAN_V2: Version 2 scan params
*/
#define BRCMF_FEAT_LIST \
BRCMF_FEAT_DEF(MBSS) \
@@ -51,7 +52,8 @@
BRCMF_FEAT_DEF(MONITOR_FMT_HW_RX_HDR) \
BRCMF_FEAT_DEF(DOT11H) \
BRCMF_FEAT_DEF(SAE) \
- BRCMF_FEAT_DEF(FWAUTH)
+ BRCMF_FEAT_DEF(FWAUTH) \
+ BRCMF_FEAT_DEF(SCAN_V2)

/*
* Quirks:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index ff2ef557f0ea..2ef3fcbb00b9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -48,6 +48,10 @@

/* size of brcmf_scan_params not including variable length array */
#define BRCMF_SCAN_PARAMS_FIXED_SIZE 64
+#define BRCMF_SCAN_PARAMS_V2_FIXED_SIZE 72
+
+/* version of brcmf_scan_params structure */
+#define BRCMF_SCAN_PARAMS_VERSION_V2 2

/* masks for channel and ssid count */
#define BRCMF_SCAN_PARAMS_COUNT_MASK 0x0000ffff
@@ -67,6 +71,7 @@
#define BRCMF_PRIMARY_KEY (1 << 1)
#define DOT11_BSSTYPE_ANY 2
#define BRCMF_ESCAN_REQ_VERSION 1
+#define BRCMF_ESCAN_REQ_VERSION_V2 2

#define BRCMF_MAXRATES_IN_SET 16 /* max # of rates in rateset */

@@ -386,6 +391,45 @@ struct brcmf_scan_params_le {
__le16 channel_list[1]; /* list of chanspecs */
};

+struct brcmf_scan_params_v2_le {
+ __le16 version; /* structure version */
+ __le16 length; /* structure length */
+ struct brcmf_ssid_le ssid_le; /* default: {0, ""} */
+ u8 bssid[ETH_ALEN]; /* default: bcast */
+ s8 bss_type; /* default: any,
+ * DOT11_BSSTYPE_ANY/INFRASTRUCTURE/INDEPENDENT
+ */
+ u8 pad;
+ __le32 scan_type; /* flags, 0 use default */
+ __le32 nprobes; /* -1 use default, number of probes per channel */
+ __le32 active_time; /* -1 use default, dwell time per channel for
+ * active scanning
+ */
+ __le32 passive_time; /* -1 use default, dwell time per channel
+ * for passive scanning
+ */
+ __le32 home_time; /* -1 use default, dwell time for the
+ * home channel between channel scans
+ */
+ __le32 channel_num; /* count of channels and ssids that follow
+ *
+ * low half is count of channels in
+ * channel_list, 0 means default (use all
+ * available channels)
+ *
+ * high half is entries in struct brcmf_ssid
+ * array that follows channel_list, aligned for
+ * s32 (4 bytes) meaning an odd channel count
+ * implies a 2-byte pad between end of
+ * channel_list and first ssid
+ *
+ * if ssid count is zero, single ssid in the
+ * fixed parameter portion is assumed, otherwise
+ * ssid in the fixed portion is ignored
+ */
+ __le16 channel_list[1]; /* list of chanspecs */
+};
+
struct brcmf_scan_results {
u32 buflen;
u32 version;
@@ -397,7 +441,10 @@ struct brcmf_escan_params_le {
__le32 version;
__le16 action;
__le16 sync_id;
- struct brcmf_scan_params_le params_le;
+ union {
+ struct brcmf_scan_params_le params_le;
+ struct brcmf_scan_params_v2_le params_v2_le;
+ };
};

struct brcmf_escan_result_le {
--
2.33.0


2021-12-26 15:40:07

by Hector Martin

[permalink] [raw]
Subject: [PATCH 25/34] brcmfmac: cfg80211: Add support for PMKID_V3 operations

Add support for the new PMKID_V3 API, which allows performing PMKID
mutations individually, instead of requiring the driver to keep track of
the full list. This new API is required by at least BCM4387.

Note that PMKID_V2 is not implemented yet.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 49 ++++++++++-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 83 +++++++++++++++++++
2 files changed, 129 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 71e932a8302c..fd2b8b822f8c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4029,6 +4029,34 @@ static s32 brcmf_cfg80211_suspend(struct wiphy *wiphy,
return 0;
}

+static s32
+brcmf_pmksa_v3_op(struct brcmf_if *ifp, struct cfg80211_pmksa *pmksa,
+ bool alive)
+{
+ struct brcmf_pmk_op_v3_le pmk_op;
+ int length = offsetof(struct brcmf_pmk_op_v3_le, pmk);
+
+ memset(&pmk_op, 0, sizeof(pmk_op));
+ pmk_op.version = cpu_to_le16(BRCMF_PMKSA_VER_3);
+
+ if (!pmksa) {
+ /* Flush operation, operate on entire list */
+ pmk_op.count = cpu_to_le16(0);
+ } else {
+ /* Single PMK operation */
+ pmk_op.count = cpu_to_le16(1);
+ length += sizeof(struct brcmf_pmksa_v3);
+ memcpy(pmk_op.pmk[0].bssid, pmksa->bssid, ETH_ALEN);
+ memcpy(pmk_op.pmk[0].pmkid, pmksa->pmkid, WLAN_PMKID_LEN);
+ pmk_op.pmk[0].pmkid_len = WLAN_PMKID_LEN;
+ pmk_op.pmk[0].time_left = alive ? BRCMF_PMKSA_NO_EXPIRY : 0;
+ }
+
+ pmk_op.length = cpu_to_le16(length);
+
+ return brcmf_fil_iovar_data_set(ifp, "pmkid_info", &pmk_op, sizeof(pmk_op));
+}
+
static __used s32
brcmf_update_pmklist(struct brcmf_cfg80211_info *cfg, struct brcmf_if *ifp)
{
@@ -4065,6 +4093,14 @@ brcmf_cfg80211_set_pmksa(struct wiphy *wiphy, struct net_device *ndev,
if (!check_vif_up(ifp->vif))
return -EIO;

+ brcmf_dbg(CONN, "set_pmksa - PMK bssid: %pM =\n", pmksa->bssid);
+ brcmf_dbg(CONN, "%*ph\n", WLAN_PMKID_LEN, pmksa->pmkid);
+
+ if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PMKID_V3))
+ return brcmf_pmksa_v3_op(ifp, pmksa, true);
+
+ /* TODO: implement PMKID_V2 */
+
npmk = le32_to_cpu(cfg->pmk_list.npmk);
for (i = 0; i < npmk; i++)
if (!memcmp(pmksa->bssid, pmk[i].bssid, ETH_ALEN))
@@ -4081,9 +4117,6 @@ brcmf_cfg80211_set_pmksa(struct wiphy *wiphy, struct net_device *ndev,
return -EINVAL;
}

- brcmf_dbg(CONN, "set_pmksa - PMK bssid: %pM =\n", pmk[npmk].bssid);
- brcmf_dbg(CONN, "%*ph\n", WLAN_PMKID_LEN, pmk[npmk].pmkid);
-
err = brcmf_update_pmklist(cfg, ifp);

brcmf_dbg(TRACE, "Exit\n");
@@ -4107,6 +4140,11 @@ brcmf_cfg80211_del_pmksa(struct wiphy *wiphy, struct net_device *ndev,

brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", pmksa->bssid);

+ if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PMKID_V3))
+ return brcmf_pmksa_v3_op(ifp, pmksa, false);
+
+ /* TODO: implement PMKID_V2 */
+
npmk = le32_to_cpu(cfg->pmk_list.npmk);
for (i = 0; i < npmk; i++)
if (!memcmp(pmksa->bssid, pmk[i].bssid, ETH_ALEN))
@@ -4143,6 +4181,11 @@ brcmf_cfg80211_flush_pmksa(struct wiphy *wiphy, struct net_device *ndev)
if (!check_vif_up(ifp->vif))
return -EIO;

+ if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PMKID_V3))
+ return brcmf_pmksa_v3_op(ifp, NULL, false);
+
+ /* TODO: implement PMKID_V2 */
+
memset(&cfg->pmk_list, 0, sizeof(cfg->pmk_list));
err = brcmf_update_pmklist(cfg, ifp);

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index 19d300dadc28..2c8063a546b6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -174,6 +174,10 @@

#define BRCMF_HE_CAP_MCS_MAP_NSS_MAX 8

+#define BRCMF_PMKSA_VER_2 2
+#define BRCMF_PMKSA_VER_3 3
+#define BRCMF_PMKSA_NO_EXPIRY 0xffffffff
+
/* MAX_CHUNK_LEN is the maximum length for data passing to firmware in each
* ioctl. It is relatively small because firmware has small maximum size input
* playload restriction for ioctls.
@@ -355,6 +359,12 @@ struct brcmf_ssid_le {
unsigned char SSID[IEEE80211_MAX_SSID_LEN];
};

+/* Alternate SSID structure used in some places... */
+struct brcmf_ssid8_le {
+ u8 SSID_len;
+ unsigned char SSID[IEEE80211_MAX_SSID_LEN];
+};
+
struct brcmf_scan_params_le {
struct brcmf_ssid_le ssid_le; /* default: {0, ""} */
u8 bssid[ETH_ALEN]; /* default: bcast */
@@ -875,6 +885,51 @@ struct brcmf_pmksa {
u8 pmkid[WLAN_PMKID_LEN];
};

+/**
+ * struct brcmf_pmksa_v2 - PMK Security Association
+ *
+ * @length: Length of the structure.
+ * @bssid: The AP's BSSID.
+ * @pmkid: The PMK ID.
+ * @pmk: PMK material for FILS key derivation.
+ * @pmk_len: Length of PMK data.
+ * @ssid: The AP's SSID.
+ * @fils_cache_id: FILS cache identifier
+ */
+struct brcmf_pmksa_v2 {
+ __le16 length;
+ u8 bssid[ETH_ALEN];
+ u8 pmkid[WLAN_PMKID_LEN];
+ u8 pmk[WLAN_PMK_LEN_SUITE_B_192];
+ __le16 pmk_len;
+ struct brcmf_ssid8_le ssid;
+ u16 fils_cache_id;
+};
+
+/**
+ * struct brcmf_pmksa_v3 - PMK Security Association
+ *
+ * @bssid: The AP's BSSID.
+ * @pmkid: The PMK ID.
+ * @pmkid_len: The length of the PMK ID.
+ * @pmk: PMK material for FILS key derivation.
+ * @pmk_len: Length of PMK data.
+ * @fils_cache_id: FILS cache identifier
+ * @ssid: The AP's SSID.
+ * @time_left: Remaining time until expiry. 0 = expired, ~0 = no expiry.
+ */
+struct brcmf_pmksa_v3 {
+ u8 bssid[ETH_ALEN];
+ u8 pmkid[WLAN_PMKID_LEN];
+ u8 pmkid_len;
+ u8 pmk[WLAN_PMK_LEN_SUITE_B_192];
+ u8 pmk_len;
+ __le16 fils_cache_id;
+ u8 pad;
+ struct brcmf_ssid8_le ssid;
+ __le32 time_left;
+};
+
/**
* struct brcmf_pmk_list_le - List of pmksa's.
*
@@ -886,6 +941,34 @@ struct brcmf_pmk_list_le {
struct brcmf_pmksa pmk[BRCMF_MAXPMKID];
};

+/**
+ * struct brcmf_pmk_list_v2_le - List of pmksa's.
+ *
+ * @version: Request version.
+ * @length: Length of this structure.
+ * @pmk: PMK SA information.
+ */
+struct brcmf_pmk_list_v2_le {
+ __le16 version;
+ __le16 length;
+ struct brcmf_pmksa_v2 pmk[BRCMF_MAXPMKID];
+};
+
+/**
+ * struct brcmf_pmk_op_v3_le - Operation on PMKSA list.
+ *
+ * @version: Request version.
+ * @length: Length of this structure.
+ * @pmk: PMK SA information.
+ */
+struct brcmf_pmk_op_v3_le {
+ __le16 version;
+ __le16 length;
+ __le16 count;
+ __le16 pad;
+ struct brcmf_pmksa_v3 pmk[BRCMF_MAXPMKID];
+};
+
/**
* struct brcmf_pno_param_le - PNO scan configuration parameters
*
--
2.33.0


2021-12-26 15:40:15

by Hector Martin

[permalink] [raw]
Subject: [PATCH 24/34] brcmfmac: feature: Add support for setting feats based on WLC version

The "wlc_ver" iovar returns information on the WLC and EPI versions.
This can be used to determine whether the PMKID_V2 and _V3 features are
supported.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/feature.c | 48 +++++++++++++++++++
.../broadcom/brcm80211/brcmfmac/feature.h | 4 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 25 ++++++++++
3 files changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index d0fada88f0f0..def4c9648645 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -126,6 +126,53 @@ static void brcmf_feat_firmware_overrides(struct brcmf_pub *drv)
drv->feat_flags |= feat_flags;
}

+struct brcmf_feat_wlcfeat {
+ u16 min_ver_major;
+ u16 min_ver_minor;
+ u32 feat_flags;
+};
+
+static const struct brcmf_feat_wlcfeat brcmf_feat_wlcfeat_map[] = {
+ { 12, 0, BIT(BRCMF_FEAT_PMKID_V2) },
+ { 13, 0, BIT(BRCMF_FEAT_PMKID_V3) },
+};
+
+static void brcmf_feat_wlc_version_overrides(struct brcmf_pub *drv)
+{
+ struct brcmf_if *ifp = brcmf_get_ifp(drv, 0);
+ const struct brcmf_feat_wlcfeat *e;
+ struct brcmf_wlc_version_le ver;
+ u32 feat_flags = 0;
+ int i, err, major, minor;
+
+ err = brcmf_fil_iovar_data_get(ifp, "wlc_ver", &ver, sizeof(ver));
+ if (err)
+ return;
+
+ major = le16_to_cpu(ver.wlc_ver_major);
+ minor = le16_to_cpu(ver.wlc_ver_minor);
+
+ brcmf_dbg(INFO, "WLC version: %d.%d\n", major, minor);
+
+ for (i = 0; i < ARRAY_SIZE(brcmf_feat_wlcfeat_map); i++) {
+ e = &brcmf_feat_wlcfeat_map[i];
+ if (major > e->min_ver_major ||
+ (major == e->min_ver_major &&
+ minor >= e->min_ver_minor)) {
+ feat_flags |= e->feat_flags;
+ }
+ }
+
+ if (!feat_flags)
+ return;
+
+ for (i = 0; i < BRCMF_FEAT_LAST; i++)
+ if (feat_flags & BIT(i))
+ brcmf_dbg(INFO, "enabling firmware feature: %s\n",
+ brcmf_feat_names[i]);
+ drv->feat_flags |= feat_flags;
+}
+
/**
* brcmf_feat_iovar_int_get() - determine feature through iovar query.
*
@@ -296,6 +343,7 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
ifp->drvr->feat_flags &= ~drvr->settings->feature_disable;
}

+ brcmf_feat_wlc_version_overrides(drvr);
brcmf_feat_firmware_overrides(drvr);

/* set chip related quirks */
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
index 9d098a068d13..becbcc50d57a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
@@ -53,7 +53,9 @@
BRCMF_FEAT_DEF(DOT11H) \
BRCMF_FEAT_DEF(SAE) \
BRCMF_FEAT_DEF(FWAUTH) \
- BRCMF_FEAT_DEF(SCAN_V2)
+ BRCMF_FEAT_DEF(SCAN_V2) \
+ BRCMF_FEAT_DEF(PMKID_V2) \
+ BRCMF_FEAT_DEF(PMKID_V3)

/*
* Quirks:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index 2ef3fcbb00b9..19d300dadc28 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -788,6 +788,31 @@ struct brcmf_rev_info_le {
__le32 nvramrev;
};

+/**
+ * struct brcmf_wlc_version_le - firmware revision info.
+ *
+ * @version: structure version.
+ * @length: structure length.
+ * @epi_ver_major: EPI major version
+ * @epi_ver_minor: EPI minor version
+ * @epi_ver_rc: EPI rc version
+ * @epi_ver_incr: EPI increment version
+ * @wlc_ver_major: WLC major version
+ * @wlc_ver_minor: WLC minor version
+ */
+struct brcmf_wlc_version_le {
+ __le16 version;
+ __le16 length;
+
+ __le16 epi_ver_major;
+ __le16 epi_ver_minor;
+ __le16 epi_ver_rc;
+ __le16 epi_ver_incr;
+
+ __le16 wlc_ver_major;
+ __le16 wlc_ver_minor;
+};
+
/**
* struct brcmf_assoclist_le - request assoc list.
*
--
2.33.0


2021-12-26 15:40:22

by Hector Martin

[permalink] [raw]
Subject: [PATCH 26/34] brcmfmac: cfg80211: Pass the PMK in binary instead of hex

Apparently the hex passphrase mechanism does not work on newer
chips/firmware (e.g. BCM4387). It seems there was a simple way of
passing it in binary all along, so use that and avoid the hexification.

OpenBSD has been doing it like this from the beginning, so this should
work on all chips.

Also clear the structure before setting the PMK. This was leaking
uninitialized stack contents to the device.

Signed-off-by: Hector Martin <[email protected]>
---
.../wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index fd2b8b822f8c..863349877933 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1420,13 +1420,14 @@ static int brcmf_set_pmk(struct brcmf_if *ifp, const u8 *pmk_data, u16 pmk_len)
{
struct brcmf_pub *drvr = ifp->drvr;
struct brcmf_wsec_pmk_le pmk;
- int i, err;
+ int err;
+
+ memset(&pmk, 0, sizeof(pmk));

- /* convert to firmware key format */
- pmk.key_len = cpu_to_le16(pmk_len << 1);
- pmk.flags = cpu_to_le16(BRCMF_WSEC_PASSPHRASE);
- for (i = 0; i < pmk_len; i++)
- snprintf(&pmk.key[2 * i], 3, "%02x", pmk_data[i]);
+ /* pass pmk directly */
+ pmk.key_len = cpu_to_le16(pmk_len);
+ pmk.flags = cpu_to_le16(0);
+ memcpy(pmk.key, pmk_data, pmk_len);

/* store psk in firmware */
err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SET_WSEC_PMK,
--
2.33.0


2021-12-26 15:40:28

by Hector Martin

[permalink] [raw]
Subject: [PATCH 27/34] brcmfmac: pcie: Add IDs/properties for BCM4387

This chip is present on Apple M1 Pro/Max (t600x) platforms:

* maldives (apple,j314s): MacBook Pro (14-inch, M1 Pro, 2021)
* maldives (apple,j314c): MacBook Pro (14-inch, M1 Max, 2021)
* madagascar (apple,j316s): MacBook Pro (16-inch, M1 Pro, 2021)
* madagascar (apple,j316c): MacBook Pro (16-inch, M1 Max, 2021)

Signed-off-by: Hector Martin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 8 ++++++++
.../net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 2 ++
3 files changed, 12 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index cfa93e3ef1a1..3958fc4450ca 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -742,6 +742,8 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv *ci)
return 0x170000;
case BRCM_CC_4378_CHIP_ID:
return 0x352000;
+ case BRCM_CC_4387_CHIP_ID:
+ return 0x740000;
default:
brcmf_err("unknown chip: %s\n", ci->pub.name);
break;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index b94c68bf9d28..0d073087b01b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -63,6 +63,7 @@ BRCMF_FW_DEF(4366C, "brcmfmac4366c-pcie");
BRCMF_FW_DEF(4371, "brcmfmac4371-pcie");
BRCMF_FW_CLM_DEF(4377B3, "brcmfmac4377b3-pcie");
BRCMF_FW_CLM_DEF(4378B1, "brcmfmac4378b1-pcie");
+BRCMF_FW_CLM_DEF(4387C2, "brcmfmac4387c2-pcie");

/* firmware config files */
MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.txt");
@@ -96,6 +97,7 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371),
BRCMF_FW_ENTRY(BRCM_CC_4377_CHIP_ID, 0xFFFFFFFF, 4377B3), /* 4 */
BRCMF_FW_ENTRY(BRCM_CC_4378_CHIP_ID, 0xFFFFFFFF, 4378B1), /* 3 */
+ BRCMF_FW_ENTRY(BRCM_CC_4387_CHIP_ID, 0xFFFFFFFF, 4387C2), /* 7 */
};

#define BRCMF_PCIE_FW_UP_TIMEOUT 5000 /* msec */
@@ -2064,6 +2066,11 @@ static int brcmf_pcie_read_otp(struct brcmf_pciedev_info *devinfo)
base = 0x1120;
words = 0x170;
break;
+ case BRCM_CC_4387_CHIP_ID:
+ coreid = BCMA_CORE_GCI;
+ base = 0x113c;
+ words = 0x170;
+ break;
default:
/* OTP not supported on this chip */
return 0;
@@ -2573,6 +2580,7 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_4371_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4377_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4378_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_4387_DEVICE_ID),
{ /* end: all zeroes */ }
};

diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index 54d7ec515e1d..3d6c803fbec5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -53,6 +53,7 @@
#define BRCM_CC_4371_CHIP_ID 0x4371
#define BRCM_CC_4377_CHIP_ID 0x4377
#define BRCM_CC_4378_CHIP_ID 0x4378
+#define BRCM_CC_4387_CHIP_ID 0x4387
#define CY_CC_4373_CHIP_ID 0x4373
#define CY_CC_43012_CHIP_ID 43012
#define CY_CC_43752_CHIP_ID 43752
@@ -91,6 +92,7 @@
#define BRCM_PCIE_4371_DEVICE_ID 0x440d
#define BRCM_PCIE_4377_DEVICE_ID 0x4488
#define BRCM_PCIE_4378_DEVICE_ID 0x4425
+#define BRCM_PCIE_4387_DEVICE_ID 0x4433


/* brcmsmac IDs */
--
2.33.0


2021-12-26 15:40:39

by Hector Martin

[permalink] [raw]
Subject: [PATCH 28/34] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio

The alignment check was wrong (e.g. & 4 instead of & 3), and the logic
was also inefficient if the length was not a multiple of 4, since it
would needlessly fall back to copying the entire buffer bytewise.

We already have a perfectly good memcpy_toio function, so just call that
instead of rolling our own copy logic here. brcmf_pcie_init_ringbuffers
was already using it anyway.

Fixes: 9e37f045d5e7 ("brcmfmac: Adding PCIe bus layer support.")
Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/pcie.c | 53 +++----------------
1 file changed, 6 insertions(+), 47 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 0d073087b01b..6cf55027e0d7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -13,6 +13,7 @@
#include <linux/bcma/bcma.h>
#include <linux/sched.h>
#include <linux/random.h>
+#include <linux/io.h>
#include <asm/unaligned.h>

#include <soc.h>
@@ -559,47 +560,6 @@ brcmf_pcie_write_ram32(struct brcmf_pciedev_info *devinfo, u32 mem_offset,
}


-static void
-brcmf_pcie_copy_mem_todev(struct brcmf_pciedev_info *devinfo, u32 mem_offset,
- void *srcaddr, u32 len)
-{
- void __iomem *address = devinfo->tcm + mem_offset;
- __le32 *src32;
- __le16 *src16;
- u8 *src8;
-
- if (((ulong)address & 4) || ((ulong)srcaddr & 4) || (len & 4)) {
- if (((ulong)address & 2) || ((ulong)srcaddr & 2) || (len & 2)) {
- src8 = (u8 *)srcaddr;
- while (len) {
- iowrite8(*src8, address);
- address++;
- src8++;
- len--;
- }
- } else {
- len = len / 2;
- src16 = (__le16 *)srcaddr;
- while (len) {
- iowrite16(le16_to_cpu(*src16), address);
- address += 2;
- src16++;
- len--;
- }
- }
- } else {
- len = len / 4;
- src32 = (__le32 *)srcaddr;
- while (len) {
- iowrite32(le32_to_cpu(*src32), address);
- address += 4;
- src32++;
- len--;
- }
- }
-}
-
-
static void
brcmf_pcie_copy_dev_tomem(struct brcmf_pciedev_info *devinfo, u32 mem_offset,
void *dstaddr, u32 len)
@@ -1697,8 +1657,8 @@ static int brcmf_pcie_download_fw_nvram(struct brcmf_pciedev_info *devinfo,
return err;

brcmf_dbg(PCIE, "Download FW %s\n", devinfo->fw_name);
- brcmf_pcie_copy_mem_todev(devinfo, devinfo->ci->rambase,
- (void *)fw->data, fw->size);
+ memcpy_toio(devinfo->tcm + devinfo->ci->rambase,
+ (void *)fw->data, fw->size);

resetintr = get_unaligned_le32(fw->data);
release_firmware(fw);
@@ -1719,7 +1679,7 @@ static int brcmf_pcie_download_fw_nvram(struct brcmf_pciedev_info *devinfo,
brcmf_dbg(PCIE, "Download NVRAM %s\n", devinfo->nvram_name);
address = devinfo->ci->rambase + devinfo->ci->ramsize -
nvram_len;
- brcmf_pcie_copy_mem_todev(devinfo, address, nvram, nvram_len);
+ memcpy_toio(devinfo->tcm + address, nvram, nvram_len);
brcmf_fw_nvram_free(nvram);

/* Some Apple chips/firmwares expect a buffer of random data
@@ -1728,13 +1688,12 @@ static int brcmf_pcie_download_fw_nvram(struct brcmf_pciedev_info *devinfo,
brcmf_dbg(PCIE, "Download random seed\n");

address -= sizeof(footer);
- brcmf_pcie_copy_mem_todev(devinfo, address, &footer,
- sizeof(footer));
+ memcpy_toio(devinfo->tcm + address, &footer, sizeof(footer));

address -= rand_len;
randbuf = kzalloc(rand_len, GFP_KERNEL);
get_random_bytes(randbuf, rand_len);
- brcmf_pcie_copy_mem_todev(devinfo, address, randbuf, rand_len);
+ memcpy_toio(devinfo->tcm + address, randbuf, rand_len);
kfree(randbuf);
} else {
brcmf_dbg(PCIE, "No matching NVRAM file found %s\n",
--
2.33.0


2021-12-26 15:40:41

by Hector Martin

[permalink] [raw]
Subject: [PATCH 21/34] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number

At least on BCM4387, the D11 cores are held in reset on cold startup and
firmware expects to release reset itself. Just assert reset here and let
firmware deassert it. Premature deassertion results in the firmware
failing to initialize properly some of the time, with strange AXI bus
errors.

Also, BCM4387 has 3 cores, up from 2. The logic for handling that is in
brcmf_chip_ai_resetcore(), but since we aren't using that any more, just
handle it here.

Signed-off-by: Hector Martin <[email protected]>
---
.../net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 73ab96968ac6..713546cebd5a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -1289,15 +1289,18 @@ static bool brcmf_chip_cm3_set_active(struct brcmf_chip_priv *chip)
static inline void
brcmf_chip_cr4_set_passive(struct brcmf_chip_priv *chip)
{
+ int i;
struct brcmf_core *core;

brcmf_chip_disable_arm(chip, BCMA_CORE_ARM_CR4);

- core = brcmf_chip_get_core(&chip->pub, BCMA_CORE_80211);
- brcmf_chip_resetcore(core, D11_BCMA_IOCTL_PHYRESET |
- D11_BCMA_IOCTL_PHYCLOCKEN,
- D11_BCMA_IOCTL_PHYCLOCKEN,
- D11_BCMA_IOCTL_PHYCLOCKEN);
+ /* Disable the cores only and let the firmware enable them.
+ * Releasing reset ourselves breaks BCM4387 in weird ways.
+ */
+ for (i = 0; (core = brcmf_chip_get_d11core(&chip->pub, i)); i++)
+ brcmf_chip_coredisable(core, D11_BCMA_IOCTL_PHYRESET |
+ D11_BCMA_IOCTL_PHYCLOCKEN,
+ D11_BCMA_IOCTL_PHYCLOCKEN);
}

static bool brcmf_chip_cr4_set_active(struct brcmf_chip_priv *chip, u32 rstvec)
--
2.33.0


2021-12-26 15:40:55

by Hector Martin

[permalink] [raw]
Subject: [PATCH 29/34] brcmfmac: pcie: Read the console on init and shutdown

This allows us to get console messages if the firmware crashed during
early init, or if an operation failed and we're about to shut down.

Signed-off-by: Hector Martin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 6cf55027e0d7..4202ca2e9381 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -851,6 +851,8 @@ static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info *devinfo,
return;

console = &devinfo->shared.console;
+ if (!console->base_addr)
+ return;
addr = console->base_addr + BRCMF_CONSOLE_WRITEIDX_OFFSET;
newidx = brcmf_pcie_read_tcm32(devinfo, addr);
while (newidx != console->read_idx) {
@@ -1627,6 +1629,7 @@ brcmf_pcie_init_share_ram_info(struct brcmf_pciedev_info *devinfo,
shared->max_rxbufpost, shared->rx_dataoffset);

brcmf_pcie_bus_console_init(devinfo);
+ brcmf_pcie_bus_console_read(devinfo, false);

return 0;
}
@@ -2394,6 +2397,7 @@ brcmf_pcie_remove(struct pci_dev *pdev)
return;

devinfo = bus->bus_priv.pcie->devinfo;
+ brcmf_pcie_bus_console_read(devinfo, false);

devinfo->state = BRCMFMAC_PCIE_STATE_DOWN;
if (devinfo->ci)
--
2.33.0


2021-12-26 15:40:56

by Hector Martin

[permalink] [raw]
Subject: [PATCH 30/34] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path

This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that
the CLM blob is released in the device remove path.

Fixes: 82f93cf46d60 ("brcmfmac: get chip's default RAM info during PCIe setup")
Signed-off-by: Hector Martin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 4202ca2e9381..6f483d25f7a1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -2118,6 +2118,8 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
ret = brcmf_chip_get_raminfo(devinfo->ci);
if (ret) {
brcmf_err(bus, "Failed to get RAM info\n");
+ release_firmware(fw);
+ brcmf_fw_nvram_free(nvram);
goto fail;
}

--
2.33.0


2021-12-26 15:41:11

by Hector Martin

[permalink] [raw]
Subject: [PATCH 31/34] brcmfmac: fwil: Constify iovar name arguments

Make all the iovar name arguments const char * instead of just char *.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/fwil.c | 34 +++++++++----------
.../broadcom/brcm80211/brcmfmac/fwil.h | 28 +++++++--------
2 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c
index d5578ca681bb..72fe8bce6eaf 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c
@@ -192,7 +192,7 @@ brcmf_fil_cmd_int_get(struct brcmf_if *ifp, u32 cmd, u32 *data)
}

static u32
-brcmf_create_iovar(char *name, const char *data, u32 datalen,
+brcmf_create_iovar(const char *name, const char *data, u32 datalen,
char *buf, u32 buflen)
{
u32 len;
@@ -213,7 +213,7 @@ brcmf_create_iovar(char *name, const char *data, u32 datalen,


s32
-brcmf_fil_iovar_data_set(struct brcmf_if *ifp, char *name, const void *data,
+brcmf_fil_iovar_data_set(struct brcmf_if *ifp, const char *name, const void *data,
u32 len)
{
struct brcmf_pub *drvr = ifp->drvr;
@@ -241,7 +241,7 @@ brcmf_fil_iovar_data_set(struct brcmf_if *ifp, char *name, const void *data,
}

s32
-brcmf_fil_iovar_data_get(struct brcmf_if *ifp, char *name, void *data,
+brcmf_fil_iovar_data_get(struct brcmf_if *ifp, const char *name, void *data,
u32 len)
{
struct brcmf_pub *drvr = ifp->drvr;
@@ -272,7 +272,7 @@ brcmf_fil_iovar_data_get(struct brcmf_if *ifp, char *name, void *data,
}

s32
-brcmf_fil_iovar_int_set(struct brcmf_if *ifp, char *name, u32 data)
+brcmf_fil_iovar_int_set(struct brcmf_if *ifp, const char *name, u32 data)
{
__le32 data_le = cpu_to_le32(data);

@@ -280,7 +280,7 @@ brcmf_fil_iovar_int_set(struct brcmf_if *ifp, char *name, u32 data)
}

s32
-brcmf_fil_iovar_int_get(struct brcmf_if *ifp, char *name, u32 *data)
+brcmf_fil_iovar_int_get(struct brcmf_if *ifp, const char *name, u32 *data)
{
__le32 data_le = cpu_to_le32(*data);
s32 err;
@@ -292,7 +292,7 @@ brcmf_fil_iovar_int_get(struct brcmf_if *ifp, char *name, u32 *data)
}

static u32
-brcmf_create_bsscfg(s32 bsscfgidx, char *name, char *data, u32 datalen,
+brcmf_create_bsscfg(s32 bsscfgidx, const char *name, char *data, u32 datalen,
char *buf, u32 buflen)
{
const s8 *prefix = "bsscfg:";
@@ -337,7 +337,7 @@ brcmf_create_bsscfg(s32 bsscfgidx, char *name, char *data, u32 datalen,
}

s32
-brcmf_fil_bsscfg_data_set(struct brcmf_if *ifp, char *name,
+brcmf_fil_bsscfg_data_set(struct brcmf_if *ifp, const char *name,
void *data, u32 len)
{
struct brcmf_pub *drvr = ifp->drvr;
@@ -366,7 +366,7 @@ brcmf_fil_bsscfg_data_set(struct brcmf_if *ifp, char *name,
}

s32
-brcmf_fil_bsscfg_data_get(struct brcmf_if *ifp, char *name,
+brcmf_fil_bsscfg_data_get(struct brcmf_if *ifp, const char *name,
void *data, u32 len)
{
struct brcmf_pub *drvr = ifp->drvr;
@@ -396,7 +396,7 @@ brcmf_fil_bsscfg_data_get(struct brcmf_if *ifp, char *name,
}

s32
-brcmf_fil_bsscfg_int_set(struct brcmf_if *ifp, char *name, u32 data)
+brcmf_fil_bsscfg_int_set(struct brcmf_if *ifp, const char *name, u32 data)
{
__le32 data_le = cpu_to_le32(data);

@@ -405,7 +405,7 @@ brcmf_fil_bsscfg_int_set(struct brcmf_if *ifp, char *name, u32 data)
}

s32
-brcmf_fil_bsscfg_int_get(struct brcmf_if *ifp, char *name, u32 *data)
+brcmf_fil_bsscfg_int_get(struct brcmf_if *ifp, const char *name, u32 *data)
{
__le32 data_le = cpu_to_le32(*data);
s32 err;
@@ -417,7 +417,7 @@ brcmf_fil_bsscfg_int_get(struct brcmf_if *ifp, char *name, u32 *data)
return err;
}

-static u32 brcmf_create_xtlv(char *name, u16 id, char *data, u32 len,
+static u32 brcmf_create_xtlv(const char *name, u16 id, char *data, u32 len,
char *buf, u32 buflen)
{
u32 iolen;
@@ -438,7 +438,7 @@ static u32 brcmf_create_xtlv(char *name, u16 id, char *data, u32 len,
return iolen;
}

-s32 brcmf_fil_xtlv_data_set(struct brcmf_if *ifp, char *name, u16 id,
+s32 brcmf_fil_xtlv_data_set(struct brcmf_if *ifp, const char *name, u16 id,
void *data, u32 len)
{
struct brcmf_pub *drvr = ifp->drvr;
@@ -466,7 +466,7 @@ s32 brcmf_fil_xtlv_data_set(struct brcmf_if *ifp, char *name, u16 id,
return err;
}

-s32 brcmf_fil_xtlv_data_get(struct brcmf_if *ifp, char *name, u16 id,
+s32 brcmf_fil_xtlv_data_get(struct brcmf_if *ifp, const char *name, u16 id,
void *data, u32 len)
{
struct brcmf_pub *drvr = ifp->drvr;
@@ -495,7 +495,7 @@ s32 brcmf_fil_xtlv_data_get(struct brcmf_if *ifp, char *name, u16 id,
return err;
}

-s32 brcmf_fil_xtlv_int_set(struct brcmf_if *ifp, char *name, u16 id, u32 data)
+s32 brcmf_fil_xtlv_int_set(struct brcmf_if *ifp, const char *name, u16 id, u32 data)
{
__le32 data_le = cpu_to_le32(data);

@@ -503,7 +503,7 @@ s32 brcmf_fil_xtlv_int_set(struct brcmf_if *ifp, char *name, u16 id, u32 data)
sizeof(data_le));
}

-s32 brcmf_fil_xtlv_int_get(struct brcmf_if *ifp, char *name, u16 id, u32 *data)
+s32 brcmf_fil_xtlv_int_get(struct brcmf_if *ifp, const char *name, u16 id, u32 *data)
{
__le32 data_le = cpu_to_le32(*data);
s32 err;
@@ -514,12 +514,12 @@ s32 brcmf_fil_xtlv_int_get(struct brcmf_if *ifp, char *name, u16 id, u32 *data)
return err;
}

-s32 brcmf_fil_xtlv_int8_get(struct brcmf_if *ifp, char *name, u16 id, u8 *data)
+s32 brcmf_fil_xtlv_int8_get(struct brcmf_if *ifp, const char *name, u16 id, u8 *data)
{
return brcmf_fil_xtlv_data_get(ifp, name, id, data, sizeof(*data));
}

-s32 brcmf_fil_xtlv_int16_get(struct brcmf_if *ifp, char *name, u16 id, u16 *data)
+s32 brcmf_fil_xtlv_int16_get(struct brcmf_if *ifp, const char *name, u16 id, u16 *data)
{
__le16 data_le = cpu_to_le16(*data);
s32 err;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h
index cb26f8c59c21..bc693157c4b1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h
@@ -84,26 +84,26 @@ s32 brcmf_fil_cmd_data_get(struct brcmf_if *ifp, u32 cmd, void *data, u32 len);
s32 brcmf_fil_cmd_int_set(struct brcmf_if *ifp, u32 cmd, u32 data);
s32 brcmf_fil_cmd_int_get(struct brcmf_if *ifp, u32 cmd, u32 *data);

-s32 brcmf_fil_iovar_data_set(struct brcmf_if *ifp, char *name, const void *data,
+s32 brcmf_fil_iovar_data_set(struct brcmf_if *ifp, const char *name, const void *data,
u32 len);
-s32 brcmf_fil_iovar_data_get(struct brcmf_if *ifp, char *name, void *data,
+s32 brcmf_fil_iovar_data_get(struct brcmf_if *ifp, const char *name, void *data,
u32 len);
-s32 brcmf_fil_iovar_int_set(struct brcmf_if *ifp, char *name, u32 data);
-s32 brcmf_fil_iovar_int_get(struct brcmf_if *ifp, char *name, u32 *data);
+s32 brcmf_fil_iovar_int_set(struct brcmf_if *ifp, const char *name, u32 data);
+s32 brcmf_fil_iovar_int_get(struct brcmf_if *ifp, const char *name, u32 *data);

-s32 brcmf_fil_bsscfg_data_set(struct brcmf_if *ifp, char *name, void *data,
+s32 brcmf_fil_bsscfg_data_set(struct brcmf_if *ifp, const char *name, void *data,
u32 len);
-s32 brcmf_fil_bsscfg_data_get(struct brcmf_if *ifp, char *name, void *data,
+s32 brcmf_fil_bsscfg_data_get(struct brcmf_if *ifp, const char *name, void *data,
u32 len);
-s32 brcmf_fil_bsscfg_int_set(struct brcmf_if *ifp, char *name, u32 data);
-s32 brcmf_fil_bsscfg_int_get(struct brcmf_if *ifp, char *name, u32 *data);
-s32 brcmf_fil_xtlv_data_set(struct brcmf_if *ifp, char *name, u16 id,
+s32 brcmf_fil_bsscfg_int_set(struct brcmf_if *ifp, const char *name, u32 data);
+s32 brcmf_fil_bsscfg_int_get(struct brcmf_if *ifp, const char *name, u32 *data);
+s32 brcmf_fil_xtlv_data_set(struct brcmf_if *ifp, const char *name, u16 id,
void *data, u32 len);
-s32 brcmf_fil_xtlv_data_get(struct brcmf_if *ifp, char *name, u16 id,
+s32 brcmf_fil_xtlv_data_get(struct brcmf_if *ifp, const char *name, u16 id,
void *data, u32 len);
-s32 brcmf_fil_xtlv_int_set(struct brcmf_if *ifp, char *name, u16 id, u32 data);
-s32 brcmf_fil_xtlv_int_get(struct brcmf_if *ifp, char *name, u16 id, u32 *data);
-s32 brcmf_fil_xtlv_int8_get(struct brcmf_if *ifp, char *name, u16 id, u8 *data);
-s32 brcmf_fil_xtlv_int16_get(struct brcmf_if *ifp, char *name, u16 id, u16 *data);
+s32 brcmf_fil_xtlv_int_set(struct brcmf_if *ifp, const char *name, u16 id, u32 data);
+s32 brcmf_fil_xtlv_int_get(struct brcmf_if *ifp, const char *name, u16 id, u32 *data);
+s32 brcmf_fil_xtlv_int8_get(struct brcmf_if *ifp, const char *name, u16 id, u8 *data);
+s32 brcmf_fil_xtlv_int16_get(struct brcmf_if *ifp, const char *name, u16 id, u16 *data);

#endif /* _fwil_h_ */
--
2.33.0


2021-12-26 15:41:25

by Hector Martin

[permalink] [raw]
Subject: [PATCH 32/34] brcmfmac: common: Add support for downloading TxCap blobs

The TxCap blobs are additional data blobs used on Apple devices, and
are uploaded analogously to CLM blobs. Add core support for doing this.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/bus.h | 1 +
.../broadcom/brcm80211/brcmfmac/common.c | 97 +++++++++++++------
2 files changed, 71 insertions(+), 27 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
index b13af8f631f3..f4bd98da9761 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
@@ -39,6 +39,7 @@ enum brcmf_bus_protocol_type {
/* Firmware blobs that may be available */
enum brcmf_blob_type {
BRCMF_BLOB_CLM,
+ BRCMF_BLOB_TXCAP,
};

struct brcmf_mp_device;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index c84c48e49fde..d65308c3f070 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -101,7 +101,7 @@ void brcmf_c_set_joinpref_default(struct brcmf_if *ifp)

static int brcmf_c_download(struct brcmf_if *ifp, u16 flag,
struct brcmf_dload_data_le *dload_buf,
- u32 len)
+ u32 len, const char *var)
{
s32 err;

@@ -112,17 +112,17 @@ static int brcmf_c_download(struct brcmf_if *ifp, u16 flag,
dload_buf->crc = cpu_to_le32(0);
len = sizeof(*dload_buf) + len - 1;

- err = brcmf_fil_iovar_data_set(ifp, "clmload", dload_buf, len);
+ err = brcmf_fil_iovar_data_set(ifp, var, dload_buf, len);

return err;
}

-static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
+static int brcmf_c_download_blob(struct brcmf_if *ifp,
+ const void *data, size_t size,
+ const char *loadvar, const char *statvar)
{
struct brcmf_pub *drvr = ifp->drvr;
- struct brcmf_bus *bus = drvr->bus_if;
struct brcmf_dload_data_le *chunk_buf;
- const struct firmware *clm = NULL;
u32 chunk_len;
u32 datalen;
u32 cumulative_len;
@@ -132,20 +132,11 @@ static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)

brcmf_dbg(TRACE, "Enter\n");

- err = brcmf_bus_get_blob(bus, &clm, BRCMF_BLOB_CLM);
- if (err || !clm) {
- brcmf_info("no clm_blob available (err=%d), device may have limited channels available\n",
- err);
- return 0;
- }
-
chunk_buf = kzalloc(sizeof(*chunk_buf) + MAX_CHUNK_LEN - 1, GFP_KERNEL);
- if (!chunk_buf) {
- err = -ENOMEM;
- goto done;
- }
+ if (!chunk_buf)
+ return -ENOMEM;

- datalen = clm->size;
+ datalen = size;
cumulative_len = 0;
do {
if (datalen > MAX_CHUNK_LEN) {
@@ -154,9 +145,10 @@ static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
chunk_len = datalen;
dl_flag |= DL_END;
}
- memcpy(chunk_buf->data, clm->data + cumulative_len, chunk_len);
+ memcpy(chunk_buf->data, data + cumulative_len, chunk_len);

- err = brcmf_c_download(ifp, dl_flag, chunk_buf, chunk_len);
+ err = brcmf_c_download(ifp, dl_flag, chunk_buf, chunk_len,
+ loadvar);

dl_flag &= ~DL_BEGIN;

@@ -165,20 +157,64 @@ static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
} while ((datalen > 0) && (err == 0));

if (err) {
- bphy_err(drvr, "clmload (%zu byte file) failed (%d)\n",
- clm->size, err);
- /* Retrieve clmload_status and print */
- err = brcmf_fil_iovar_int_get(ifp, "clmload_status", &status);
+ bphy_err(drvr, "%s (%zu byte file) failed (%d)\n",
+ loadvar, size, err);
+ /* Retrieve status and print */
+ err = brcmf_fil_iovar_int_get(ifp, statvar, &status);
if (err)
- bphy_err(drvr, "get clmload_status failed (%d)\n", err);
+ bphy_err(drvr, "get %s failed (%d)\n", statvar, err);
else
- brcmf_dbg(INFO, "clmload_status=%d\n", status);
+ brcmf_dbg(INFO, "%s=%d\n", statvar, status);
err = -EIO;
}

kfree(chunk_buf);
-done:
- release_firmware(clm);
+ return err;
+}
+
+static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
+{
+ struct brcmf_pub *drvr = ifp->drvr;
+ struct brcmf_bus *bus = drvr->bus_if;
+ const struct firmware *fw = NULL;
+ s32 err;
+
+ brcmf_dbg(TRACE, "Enter\n");
+
+ err = brcmf_bus_get_blob(bus, &fw, BRCMF_BLOB_CLM);
+ if (err || !fw) {
+ brcmf_info("no clm_blob available (err=%d), device may have limited channels available\n",
+ err);
+ return 0;
+ }
+
+ err = brcmf_c_download_blob(ifp, fw->data, fw->size,
+ "clmload", "clmload_status");
+
+ release_firmware(fw);
+ return err;
+}
+
+static int brcmf_c_process_txcap_blob(struct brcmf_if *ifp)
+{
+ struct brcmf_pub *drvr = ifp->drvr;
+ struct brcmf_bus *bus = drvr->bus_if;
+ const struct firmware *fw = NULL;
+ s32 err;
+
+ brcmf_dbg(TRACE, "Enter\n");
+
+ err = brcmf_bus_get_blob(bus, &fw, BRCMF_BLOB_TXCAP);
+ if (err || !fw) {
+ brcmf_info("no txcap_blob available (err=%d)\n", err);
+ return 0;
+ }
+
+ brcmf_info("TxCap blob found, loading\n");
+ err = brcmf_c_download_blob(ifp, fw->data, fw->size,
+ "txcapload", "txcapload_status");
+
+ release_firmware(fw);
return err;
}

@@ -248,6 +284,13 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
goto done;
}

+ /* Do TxCap downloading, if needed */
+ err = brcmf_c_process_txcap_blob(ifp);
+ if (err < 0) {
+ bphy_err(drvr, "download TxCap blob file failed, %d\n", err);
+ goto done;
+ }
+
/* query for 'ver' to get version info from firmware */
memset(buf, 0, sizeof(buf));
err = brcmf_fil_iovar_data_get(ifp, "ver", buf, sizeof(buf));
--
2.33.0


2021-12-26 15:41:30

by Hector Martin

[permalink] [raw]
Subject: [PATCH 33/34] brcmfmac: pcie: Load and provide TxCap blobs

These blobs are named .txcap_blob, and exist alongside the existing
.clm_blob files. Use the existing firmware machinery to provide them to
the core.

Signed-off-by: Hector Martin <[email protected]>
---
.../net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 6f483d25f7a1..04c29e620eca 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -73,6 +73,7 @@ MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.txt");
/* per-board firmware binaries */
MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.bin");
MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.clm_blob");
+MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.txcap_blob");

static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFF, 43602),
@@ -325,7 +326,9 @@ struct brcmf_pciedev_info {
char fw_name[BRCMF_FW_NAME_LEN];
char nvram_name[BRCMF_FW_NAME_LEN];
char clm_name[BRCMF_FW_NAME_LEN];
+ char txcap_name[BRCMF_FW_NAME_LEN];
const struct firmware *clm_fw;
+ const struct firmware *txcap_fw;
const struct brcmf_pcie_reginfo *reginfo;
void __iomem *regs;
void __iomem *tcm;
@@ -1499,6 +1502,10 @@ static int brcmf_pcie_get_blob(struct device *dev, const struct firmware **fw,
*fw = devinfo->clm_fw;
devinfo->clm_fw = NULL;
break;
+ case BRCMF_BLOB_TXCAP:
+ *fw = devinfo->txcap_fw;
+ devinfo->txcap_fw = NULL;
+ break;
default:
return -ENOENT;
}
@@ -2088,6 +2095,7 @@ static int brcmf_pcie_read_otp(struct brcmf_pciedev_info *devinfo)
#define BRCMF_PCIE_FW_CODE 0
#define BRCMF_PCIE_FW_NVRAM 1
#define BRCMF_PCIE_FW_CLM 2
+#define BRCMF_PCIE_FW_TXCAP 3

static void brcmf_pcie_setup(struct device *dev, int ret,
struct brcmf_fw_request *fwreq)
@@ -2113,6 +2121,7 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
nvram = fwreq->items[BRCMF_PCIE_FW_NVRAM].nv_data.data;
nvram_len = fwreq->items[BRCMF_PCIE_FW_NVRAM].nv_data.len;
devinfo->clm_fw = fwreq->items[BRCMF_PCIE_FW_CLM].binary;
+ devinfo->txcap_fw = fwreq->items[BRCMF_PCIE_FW_TXCAP].binary;
kfree(fwreq);

ret = brcmf_chip_get_raminfo(devinfo->ci);
@@ -2189,6 +2198,7 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo)
{ ".bin", devinfo->fw_name },
{ ".txt", devinfo->nvram_name },
{ ".clm_blob", devinfo->clm_name },
+ { ".txcap_blob", devinfo->txcap_name },
};

fwreq = brcmf_fw_alloc_request(devinfo->ci->chip, devinfo->ci->chiprev,
@@ -2203,6 +2213,8 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo)
fwreq->items[BRCMF_PCIE_FW_NVRAM].flags = BRCMF_FW_REQF_OPTIONAL;
fwreq->items[BRCMF_PCIE_FW_CLM].type = BRCMF_FW_TYPE_BINARY;
fwreq->items[BRCMF_PCIE_FW_CLM].flags = BRCMF_FW_REQF_OPTIONAL;
+ fwreq->items[BRCMF_PCIE_FW_TXCAP].type = BRCMF_FW_TYPE_BINARY;
+ fwreq->items[BRCMF_PCIE_FW_TXCAP].flags = BRCMF_FW_REQF_OPTIONAL;
/* NVRAM reserves PCI domain 0 for Broadcom's SDK faked bus */
fwreq->domain_nr = pci_domain_nr(devinfo->pdev->bus) + 1;
fwreq->bus_nr = devinfo->pdev->bus->number;
@@ -2419,6 +2431,7 @@ brcmf_pcie_remove(struct pci_dev *pdev)
brcmf_pcie_reset_device(devinfo);
brcmf_pcie_release_resource(devinfo);
release_firmware(devinfo->clm_fw);
+ release_firmware(devinfo->txcap_fw);

if (devinfo->ci)
brcmf_chip_detach(devinfo->ci);
--
2.33.0


2021-12-26 15:41:34

by Hector Martin

[permalink] [raw]
Subject: [PATCH 34/34] brcmfmac: common: Add support for external calibration blobs

The calibration blob for a chip is normally stored in SROM and loaded
internally by the firmware. However, Apple ARM64 platforms instead store
it as part of platform configuration data, and provide it via the Apple
Device Tree. We forward this into the Linux DT in the bootloader.

Add support for taking this blob from the DT and loading it into the
dongle. The loading mechanism is the same as used for the CLM and TxCap
blobs.

Signed-off-by: Hector Martin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/common.c | 24 +++++++++++++++++++
.../broadcom/brcm80211/brcmfmac/common.h | 2 ++
.../wireless/broadcom/brcm80211/brcmfmac/of.c | 8 +++++++
3 files changed, 34 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index d65308c3f070..ad36e6b5dd47 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -218,6 +218,23 @@ static int brcmf_c_process_txcap_blob(struct brcmf_if *ifp)
return err;
}

+static int brcmf_c_process_cal_blob(struct brcmf_if *ifp)
+{
+ struct brcmf_pub *drvr = ifp->drvr;
+ struct brcmf_mp_device *settings = drvr->settings;
+ s32 err;
+
+ brcmf_dbg(TRACE, "Enter\n");
+
+ if (!settings->cal_blob || !settings->cal_size)
+ return 0;
+
+ brcmf_info("Calibration blob provided by platform, loading\n");
+ err = brcmf_c_download_blob(ifp, settings->cal_blob, settings->cal_size,
+ "calload", "calload_status");
+ return err;
+}
+
int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
{
struct brcmf_pub *drvr = ifp->drvr;
@@ -291,6 +308,13 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
goto done;
}

+ /* Download external calibration blob, if available */
+ err = brcmf_c_process_cal_blob(ifp);
+ if (err < 0) {
+ bphy_err(drvr, "download calibration blob file failed, %d\n", err);
+ goto done;
+ }
+
/* query for 'ver' to get version info from firmware */
memset(buf, 0, sizeof(buf));
err = brcmf_fil_iovar_data_get(ifp, "ver", buf, sizeof(buf));
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
index a88c4a9310f3..f321346edd01 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
@@ -51,6 +51,8 @@ struct brcmf_mp_device {
struct brcmfmac_pd_cc *country_codes;
const char *board_type;
const char *antenna_sku;
+ void *cal_blob;
+ int cal_size;
union {
struct brcmfmac_sdio_pd sdio;
} bus;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index 453a6cda5abb..2f40d70fdbf1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -85,6 +85,14 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
if (!of_property_read_string(np, "apple,antenna-sku", &prop))
settings->antenna_sku = devm_kstrdup(dev, prop, GFP_KERNEL);

+ /* The WLAN calibration blob is normally stored in SROM, but Apple
+ * ARM64 platforms pass it via the DT instead.
+ */
+ prop = of_get_property(np, "brcm,cal-blob", &settings->cal_size);
+ if (prop && settings->cal_size)
+ settings->cal_blob = devm_kmemdup(dev, prop, settings->cal_size,
+ GFP_KERNEL);
+
/* Set board-type to the first string of the machine compatible prop */
root = of_find_node_by_path("/");
if (root && !settings->board_type) {
--
2.33.0


2021-12-26 18:28:31

by Lukas Wunner

[permalink] [raw]
Subject: Re: [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props

On Mon, Dec 27, 2021 at 12:36:05AM +0900, Hector Martin wrote:
> The Wi-Fi module in Apple machines has a "module-instance" device
> property that specifies the platform type and is used for firmware
> selection. Its value is a string, so add support for string values in
> acpi_extract_apple_properties().
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Lukas Wunner <[email protected]>

2021-12-26 19:17:34

by Lukas Wunner

[permalink] [raw]
Subject: Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms

On Mon, Dec 27, 2021 at 12:35:50AM +0900, Hector Martin wrote:
> # On firmware
>
> As you might expect, the firmware for these machines is not available
> under a redistributable license; however, every owner of one of these
> machines *is* implicitly licensed to posess the firmware, and the OS
> packages containing it are available under well-known URLs on Apple's
> CDN with no authentication.

Apple's EFI firmware contains a full-fledged network stack for
downloading macOS images from osrecovery.apple.com. I suspect
that it also contains wifi firmware.

You may want to check if it's passed to the OS as an EFI property.
Using that would sidestep license issues. There's EDID data,
Thunderbolt DROM data and whatnot in those properties, so I
wouldn't be surprised if it contained wifi stuff as well.

Enable CONFIG_APPLE_PROPERTIES and pass "dump_apple_properties"
on the command line to see all EFI properties in dmesg.
Alternatively, check "ioreg -l" on macOS. Generally, what's
available in the I/O registry should also be available on Linux
either as an ACPI or EFI property.

Thanks,

Lukas

2021-12-26 21:02:37

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

On Sun, Dec 26, 2021 at 4:36 PM Hector Martin <[email protected]> wrote:

> 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.
>
> Signed-off-by: Hector Martin <[email protected]>

Makes sense to me!
Reviewed-by: Linus Walleij <[email protected]>

> + brcm,cal-blob:
> + $ref: /schemas/types.yaml#/definitions/uint8-array
> + description: A per-device calibration blob for the Wi-Fi radio. This
> + should be filled in by the bootloader from platform configuration
> + data, if necessary, and will be uploaded to the device if present.

This is especially nice. This way on other systems U-Boot can read the
calibration file (usually stored in a special partition) and modify the
device tree to include this, then we don't need the driver to learn
about any specific file locations for calibrations or worry about
inserting it from userspace.

Yours,
Linus Walleij

2021-12-26 21:04:22

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 02/34] brcmfmac: pcie: Declare missing firmware files in pcie.c

On Sun, Dec 26, 2021 at 4:36 PM Hector Martin <[email protected]> wrote:

> Move one of the declarations from sdio.c to pcie.c, since it makes no
> sense in the former (SDIO support is optional), and add missing ones.
>
> Signed-off-by: Hector Martin <[email protected]>
> Fixes: 75729e110e68 ("brcmfmac: expose firmware config files through modinfo")

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2021-12-26 21:43:01

by Hans de Goede

[permalink] [raw]
Subject: Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms

Hi,

On 12/26/21 20:17, Lukas Wunner wrote:
> On Mon, Dec 27, 2021 at 12:35:50AM +0900, Hector Martin wrote:
>> # On firmware
>>
>> As you might expect, the firmware for these machines is not available
>> under a redistributable license; however, every owner of one of these
>> machines *is* implicitly licensed to posess the firmware, and the OS
>> packages containing it are available under well-known URLs on Apple's
>> CDN with no authentication.
>
> Apple's EFI firmware contains a full-fledged network stack for
> downloading macOS images from osrecovery.apple.com. I suspect
> that it also contains wifi firmware.
>
> You may want to check if it's passed to the OS as an EFI property.
> Using that would sidestep license issues. There's EDID data,
> Thunderbolt DROM data and whatnot in those properties, so I
> wouldn't be surprised if it contained wifi stuff as well.
>
> Enable CONFIG_APPLE_PROPERTIES and pass "dump_apple_properties"
> on the command line to see all EFI properties in dmesg.
> Alternatively, check "ioreg -l" on macOS. Generally, what's
> available in the I/O registry should also be available on Linux
> either as an ACPI or EFI property.

Interesting, note that even if the files are not available as
a property we also have CONFIG_EFI_EMBEDDED_FIRMWARE, see:

drivers/firmware/efi/embedded-firmware.c
Documentation/driver-api/firmware/fallback-mechanisms.rst

I wrote this to pry/dig out some touchscreen firmwares (where
we have been unable to get permission to redistribute) out of
EFI boot_services_code mem regions on tablets where
the touchsceen is supported under the EFI environment.

This may need some tweaks, but if there is an embedded copy
of the firmware files in the EFI mem regions somewhere it
should be possible to adjust this code to grab it and present
it to the firmware-loader mechanism as a fallback option.

Refards,

Hans


2021-12-26 23:34:19

by Rob Herring (Arm)

[permalink] [raw]
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

On Mon, 27 Dec 2021 00:35:51 +0900, Hector Martin wrote:
> 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.
>
> Signed-off-by: Hector Martin <[email protected]>
> ---
> .../net/wireless/brcm,bcm4329-fmac.yaml | 32 +++++++++++++++++--
> 1 file changed, 29 insertions(+), 3 deletions(-)
>

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml: properties:apple,antenna-sku: '$def' is not one of ['$ref', 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 'type', 'typeSize', 'unevaluatedProperties', 'uniqueItems']
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml: properties:apple,antenna-sku: 'oneOf' conditional failed, one must be fixed:
'type' is a required property
hint: A vendor boolean property can use "type: boolean"
Additional properties are not allowed ('$def' was unexpected)
hint: A vendor boolean property can use "type: boolean"
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml: properties:apple,antenna-sku: 'oneOf' conditional failed, one must be fixed:
'enum' is a required property
'const' is a required property
hint: A vendor string property with exact values has an implicit type
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml: properties:apple,antenna-sku: 'oneOf' conditional failed, one must be fixed:
'$ref' is a required property
'allOf' is a required property
hint: A vendor property needs a $ref to types.yaml
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml: ignoring, error in schema: properties: apple,antenna-sku
Documentation/devicetree/bindings/mmc/mmc-controller.example.dt.yaml:0:0: /example-0/mmc@1c12000/wifi@1: failed to match any schema with compatible: ['brcm,bcm4329-fmac']
Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.example.dt.yaml:0:0: /example-0/mmc@80118000/wifi@1: failed to match any schema with compatible: ['brcm,bcm4334-fmac', 'brcm,bcm4329-fmac']
Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.example.dt.yaml:0:0: /example-0/mmc@80118000/wifi@1: failed to match any schema with compatible: ['brcm,bcm4334-fmac', 'brcm,bcm4329-fmac']

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1573232

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


2021-12-27 11:53:35

by Hector Martin

[permalink] [raw]
Subject: Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms

On 2021/12/27 6:42, Hans de Goede wrote:
> Hi,
>
> On 12/26/21 20:17, Lukas Wunner wrote:
>> On Mon, Dec 27, 2021 at 12:35:50AM +0900, Hector Martin wrote:
>>> # On firmware
>>>
>>> As you might expect, the firmware for these machines is not available
>>> under a redistributable license; however, every owner of one of these
>>> machines *is* implicitly licensed to posess the firmware, and the OS
>>> packages containing it are available under well-known URLs on Apple's
>>> CDN with no authentication.
>>
>> Apple's EFI firmware contains a full-fledged network stack for
>> downloading macOS images from osrecovery.apple.com. I suspect
>> that it also contains wifi firmware.
>>
>> You may want to check if it's passed to the OS as an EFI property.
>> Using that would sidestep license issues. There's EDID data,
>> Thunderbolt DROM data and whatnot in those properties, so I
>> wouldn't be surprised if it contained wifi stuff as well.
>>
>> Enable CONFIG_APPLE_PROPERTIES and pass "dump_apple_properties"
>> on the command line to see all EFI properties in dmesg.
>> Alternatively, check "ioreg -l" on macOS. Generally, what's
>> available in the I/O registry should also be available on Linux
>> either as an ACPI or EFI property.
>
> Interesting, note that even if the files are not available as
> a property we also have CONFIG_EFI_EMBEDDED_FIRMWARE, see:
>
> drivers/firmware/efi/embedded-firmware.c
> Documentation/driver-api/firmware/fallback-mechanisms.rst
>
> I wrote this to pry/dig out some touchscreen firmwares (where
> we have been unable to get permission to redistribute) out of
> EFI boot_services_code mem regions on tablets where
> the touchsceen is supported under the EFI environment.
>
> This may need some tweaks, but if there is an embedded copy
> of the firmware files in the EFI mem regions somewhere it
> should be possible to adjust this code to grab it and present
> it to the firmware-loader mechanism as a fallback option.

Note that this wouldn't work on M1 Macs anyway, since those don't have
EFI (we provide EFI via U-Boot as a chained bootloader on those), and
their bootloader doesn't support any networking (it doesn't even do USB
or any kind of UI).

Quick recap for those not familiar with the M1 boot process: the
bootloader is iBoot, which is extremely simple (at least compared to
EFI). All it can do is boot kernels from APFS volumes on internal NVMe.
The boot selection menu and recovery options are implemented as macOS
apps running from a recovery image (~1GB), and "USB boot" is implemented
by copying the macOS equivalent of /boot to NVMe. There is a global
recovery image as well as per-OS recovery image. The WiFi firmware is
present in this image as well as on normal macOS root volumes.

Our Linux install script is actually mostly a macOS install script that
sets up all the boot components that macOS would normally have,
including the recovery image, minus the main root filesystem. This is
all required to work properly within Apple's security and multi-boot
framework. So, since we're installing the recovery image, we're already
in an easy position to pull the firmware out and stick it in the EFI
partition for Linux to easily use. The alternative would be for Linux
userspace to read it from APFS directly, but that seems unlikely to be
practical until linux-apfs is upstreamed.

For T2 Macs I'm sure the firmware will be in EFI somewhere, but even if
we can get it from there (I wouldn't be surprised if it's e.g. still
compressed in the normal boot path that doesn't start network services),
I'm not sure it's worth implementing yet another mechanism for those
machines. Once we have the vendor-firmware mechanism implemented for M1,
it's easy to just run the same script on T2s and get the proper firmware
from macOS (which might even be different from the EFI firmware...).
macOS definitely doesn't read the firmware from EFI on those machines,
so a hack to do it by scanning the code would probably not be something
we can rely on to continue working across firmware updates (and they do
update WiFi firmware; it's a rather well known source of security
issues... so then we'd have to play the update-the-sha256 cat and mouse
game). I'm pretty sure there's no property containing the big firmware
blob passed explicitly to the OS; it has its own copy.

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2021-12-27 16:36:40

by Rob Herring (Arm)

[permalink] [raw]
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

On Mon, Dec 27, 2021 at 12:35:51AM +0900, Hector Martin wrote:
> 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.
>
> Signed-off-by: Hector Martin <[email protected]>
> ---
> .../net/wireless/brcm,bcm4329-fmac.yaml | 32 +++++++++++++++++--
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> index c11f23b20c4c..2530ff3e7b90 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/net/wireless/brcm,bcm4329-fmac.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: Broadcom BCM4329 family fullmac wireless SDIO devices
> +title: Broadcom BCM4329 family fullmac wireless SDIO/PCIE devices
>
> maintainers:
> - Arend van Spriel <[email protected]>
> @@ -36,16 +36,22 @@ properties:
> - brcm,bcm43455-fmac
> - brcm,bcm43456-fmac
> - brcm,bcm4354-fmac
> + - brcm,bcm4355c1-fmac
> - brcm,bcm4356-fmac
> - brcm,bcm4359-fmac
> + - brcm,bcm4364b2-fmac
> + - brcm,bcm4364b3-fmac
> + - brcm,bcm4377b3-fmac
> + - brcm,bcm4378b1-fmac
> + - brcm,bcm4387c2-fmac
> - cypress,cyw4373-fmac
> - cypress,cyw43012-fmac
> - const: brcm,bcm4329-fmac
> - const: brcm,bcm4329-fmac
>
> reg:
> - description: SDIO function number for the device, for most cases
> - this will be 1.
> + description: SDIO function number for the device (for most cases
> + this will be 1) or PCI device identifier.
>
> interrupts:
> maxItems: 1
> @@ -75,6 +81,26 @@ properties:
> items:
> pattern: '^[A-Z][A-Z]-[A-Z][0-9A-Z]-[0-9]+$'
>
> + brcm,cal-blob:
> + $ref: /schemas/types.yaml#/definitions/uint8-array
> + description: A per-device calibration blob for the Wi-Fi radio. This
> + should be filled in by the bootloader from platform configuration
> + data, if necessary, and will be uploaded to the device if present.
> +
> + apple,module-instance:
> + $ref: /schemas/types.yaml#/definitions/string
> + description: Module codename used to identify a specific board on
> + Apple platforms. This is used to build the firmware filenames, to allow
> + different platforms to have different firmware and/or NVRAM config.
> +
> + apple,antenna-sku:
> + $def: /schemas/types.yaml#/definitions/string
> + description: Antenna SKU used to identify a specific antenna configuration
> + on Apple platforms. This is use to build firmware filenames, to allow
> + platforms with different antenna configs to have different firmware and/or
> + NVRAM. This would normally be filled in by the bootloader from platform
> + configuration data.

Is there a known set of strings that can be defined?

There's also the somewhat standard 'firmware-name' property that serves
similar purpose, but if there's multiple files, then I guess this
approach is fine.

Rob

2021-12-27 17:23:16

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

On 28/12/2021 01.36, Rob Herring wrote:
> On Mon, Dec 27, 2021 at 12:35:51AM +0900, Hector Martin wrote:
>> + brcm,cal-blob:
>> + $ref: /schemas/types.yaml#/definitions/uint8-array
>> + description: A per-device calibration blob for the Wi-Fi radio. This
>> + should be filled in by the bootloader from platform configuration
>> + data, if necessary, and will be uploaded to the device if present.
>> +
>> + apple,module-instance:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description: Module codename used to identify a specific board on
>> + Apple platforms. This is used to build the firmware filenames, to allow
>> + different platforms to have different firmware and/or NVRAM config.
>> +
>> + apple,antenna-sku:
>> + $def: /schemas/types.yaml#/definitions/string
>> + description: Antenna SKU used to identify a specific antenna configuration
>> + on Apple platforms. This is use to build firmware filenames, to allow
>> + platforms with different antenna configs to have different firmware and/or
>> + NVRAM. This would normally be filled in by the bootloader from platform
>> + configuration data.
>
> Is there a known set of strings that can be defined?

For apple,module-instance there is, though it will grow with every new
machine. If you're happy with me pushing updates to this through
asahi-soc I can keep it maintained as we add DTs and compatibles there.

I'm curious whether you prefer this approach or something like
brcm,board-name instead. Right now we do:

apple,module-instance = "honshu"

That gets converted to board_name="apple,honshu" in the code, which is
what the firmwares are named after (plus extra info later appended, if
the rest of the Apple data is available).

But we could also do:

brcm,board-name = "apple,honshu"

The latter would be more generically useful for other platforms, since
it would allow e.g. having DTs for different boards that use the same
WiFi module/subsystem and thus a compatible NVRAM fw file alias to the
same file name (right now this is done with symlinks in /lib/firmware,
one for each equivalent board). For non-Apple platforms (i.e. if
antenna-sku and/or the OTP aren't available to do the funky Apple
firmware selection), this just ends up replacing what would normally be
the OF root node compatible in the firmware filename.

E.g. right now we have:

brcmfmac43430-sdio.AP6212.txt
brcmfmac43430-sdio.raspberrypi,3-model-b.txt
brcmfmac43430-sdio.raspberrypi,model-zero-w.txt -> brcmfmac43430-sdio.raspberrypi,3-model-b.txt
brcmfmac43430-sdio.sinovoip,bpi-m2-plus.txt -> brcmfmac43430-sdio.AP6212.txt
brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt -> brcmfmac43430-sdio.AP6212.txt
brcmfmac43430-sdio.sinovoip,bpi-m2-zero.txt -> brcmfmac43430-sdio.AP6212.txt
brcmfmac43430-sdio.sinovoip,bpi-m3.txt -> brcmfmac43430-sdio.AP6212.txt

And this could allow the sinovoip.* DTs to say:
brcm,board-name = "AP6212";

And the rPi zero one:
brcm,board-name = "raspberrypi,3-model-b";

And avoid the symlinks.

The antenna-sku thing is specific to the Apple firmware selection
process and doesn't make sense as a more generic property.

antenna-sku right now always seems to be one of "ID", "X0", "X2", "X3",
though that could presumably change in the future. I can add this to the
binding if you want, though since this will be filled in by the
bootloader from platform data we wouldn't be validating it anyway. Not
sure if it's worth it.

> There's also the somewhat standard 'firmware-name' property that
> serves similar purpose, but if there's multiple files, then I guess
> this approach is fine.

Yeah, and the firmware name is constructed using non-DT information too
(and we have several attempted filenames times several firmware types),
so it wouldn't be complete.

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2021-12-29 16:38:59

by Mark Kettenis

[permalink] [raw]
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

> From: Hector Martin <[email protected]>
> Date: Tue, 28 Dec 2021 02:23:02 +0900
>
> On 28/12/2021 01.36, Rob Herring wrote:
> > On Mon, Dec 27, 2021 at 12:35:51AM +0900, Hector Martin wrote:
> >> + brcm,cal-blob:
> >> + $ref: /schemas/types.yaml#/definitions/uint8-array
> >> + description: A per-device calibration blob for the Wi-Fi radio. This
> >> + should be filled in by the bootloader from platform configuration
> >> + data, if necessary, and will be uploaded to the device if present.
> >> +
> >> + apple,module-instance:
> >> + $ref: /schemas/types.yaml#/definitions/string
> >> + description: Module codename used to identify a specific board on
> >> + Apple platforms. This is used to build the firmware filenames, to allow
> >> + different platforms to have different firmware and/or NVRAM config.
> >> +
> >> + apple,antenna-sku:
> >> + $def: /schemas/types.yaml#/definitions/string
> >> + description: Antenna SKU used to identify a specific antenna configuration
> >> + on Apple platforms. This is use to build firmware filenames, to allow
> >> + platforms with different antenna configs to have different firmware and/or
> >> + NVRAM. This would normally be filled in by the bootloader from platform
> >> + configuration data.
> >
> > Is there a known set of strings that can be defined?
>
> For apple,module-instance there is, though it will grow with every new
> machine. If you're happy with me pushing updates to this through
> asahi-soc I can keep it maintained as we add DTs and compatibles there.
>
> I'm curious whether you prefer this approach or something like
> brcm,board-name instead. Right now we do:
>
> apple,module-instance = "honshu"
>
> That gets converted to board_name="apple,honshu" in the code, which is
> what the firmwares are named after (plus extra info later appended, if
> the rest of the Apple data is available).
>
> But we could also do:
>
> brcm,board-name = "apple,honshu"
>
> The latter would be more generically useful for other platforms, since
> it would allow e.g. having DTs for different boards that use the same
> WiFi module/subsystem and thus a compatible NVRAM fw file alias to the
> same file name (right now this is done with symlinks in /lib/firmware,
> one for each equivalent board). For non-Apple platforms (i.e. if
> antenna-sku and/or the OTP aren't available to do the funky Apple
> firmware selection), this just ends up replacing what would normally be
> the OF root node compatible in the firmware filename.
>
> E.g. right now we have:
>
> brcmfmac43430-sdio.AP6212.txt
> brcmfmac43430-sdio.raspberrypi,3-model-b.txt
> brcmfmac43430-sdio.raspberrypi,model-zero-w.txt -> brcmfmac43430-sdio.raspberrypi,3-model-b.txt
> brcmfmac43430-sdio.sinovoip,bpi-m2-plus.txt -> brcmfmac43430-sdio.AP6212.txt
> brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt -> brcmfmac43430-sdio.AP6212.txt
> brcmfmac43430-sdio.sinovoip,bpi-m2-zero.txt -> brcmfmac43430-sdio.AP6212.txt
> brcmfmac43430-sdio.sinovoip,bpi-m3.txt -> brcmfmac43430-sdio.AP6212.txt
>
> And this could allow the sinovoip.* DTs to say:
> brcm,board-name = "AP6212";
>
> And the rPi zero one:
> brcm,board-name = "raspberrypi,3-model-b";
>
> And avoid the symlinks.
>
> The antenna-sku thing is specific to the Apple firmware selection
> process and doesn't make sense as a more generic property.
>
> antenna-sku right now always seems to be one of "ID", "X0", "X2", "X3",
> though that could presumably change in the future. I can add this to the
> binding if you want, though since this will be filled in by the
> bootloader from platform data we wouldn't be validating it anyway. Not
> sure if it's worth it.

Actually what Apple does here makes quite a bit of sense. Typically
WiFi chips are integrated with some analog components into a shielded
module. The AP6212 mentioned above is an example of such a module. I
suspect that the module defines some of the characteristics encoded in
the "nvmram" files, but certainly not all because the connected
antenna will also affect how the thing behaves. Of course many SBCs
come without an antenna so the actual antenna depends on whatever the
user connects to the board. So using a module-specific "nvram" file
is probably the best one can do here. So I think if you want to have
a generic module name property, it should be called "brcm,module-name"
instead of "brcm,board-name". However...

> > There's also the somewhat standard 'firmware-name' property that
> > serves similar purpose, but if there's multiple files, then I guess
> > this approach is fine.
>
> Yeah, and the firmware name is constructed using non-DT information too
> (and we have several attempted filenames times several firmware types),
> so it wouldn't be complete.

...if the way the firmware name is constructed remains Apple-specific
because of this non-DT information, keeping the "apple,xxx" properties
has the benefit of signalling that firmware names constructed this way
are desired. Or rather, their absence can signal that the
Apple-specific code in the driver should be skipped.

2021-12-29 16:42:21

by Mark Kettenis

[permalink] [raw]
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

> From: Hector Martin <[email protected]>
> Cc: Hector Martin <[email protected]>, Sven Peter <[email protected]>,
> Alyssa Rosenzweig <[email protected]>,
> Mark Kettenis <[email protected]>,
> Rafał Miłecki <[email protected]>,
> Pieter-Paul Giesberts <[email protected]>,
> Linus Walleij <[email protected]>,
> Hans de Goede <[email protected]>,
> "John W. Linville" <[email protected]>,
> "Daniel (Deognyoun) Kim" <[email protected]>,
> "brian m. carlson" <[email protected]>,
> [email protected], [email protected],
> [email protected], [email protected],
> [email protected], [email protected],
> [email protected]
> Date: Mon, 27 Dec 2021 00:35:51 +0900
>
> 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.
>
> Signed-off-by: Hector Martin <[email protected]>
> ---
> .../net/wireless/brcm,bcm4329-fmac.yaml | 32 +++++++++++++++++--
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> index c11f23b20c4c..2530ff3e7b90 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/net/wireless/brcm,bcm4329-fmac.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: Broadcom BCM4329 family fullmac wireless SDIO devices
> +title: Broadcom BCM4329 family fullmac wireless SDIO/PCIE devices
>
> maintainers:
> - Arend van Spriel <[email protected]>
> @@ -36,16 +36,22 @@ properties:
> - brcm,bcm43455-fmac
> - brcm,bcm43456-fmac
> - brcm,bcm4354-fmac
> + - brcm,bcm4355c1-fmac
> - brcm,bcm4356-fmac
> - brcm,bcm4359-fmac
> + - brcm,bcm4364b2-fmac
> + - brcm,bcm4364b3-fmac
> + - brcm,bcm4377b3-fmac
> + - brcm,bcm4378b1-fmac
> + - brcm,bcm4387c2-fmac
> - cypress,cyw4373-fmac
> - cypress,cyw43012-fmac
> - const: brcm,bcm4329-fmac
> - const: brcm,bcm4329-fmac

I suppose this helps with validation of device trees. However, nodes
for PCI devices are not supposed to have a "compatible" property as
the PCI vendor and device IDs are supposed to be used to identify a
device.

That does raise the question how a schema for additional properties
for PCI device nodes is supposed to be defined...

> reg:
> - description: SDIO function number for the device, for most cases
> - this will be 1.
> + description: SDIO function number for the device (for most cases
> + this will be 1) or PCI device identifier.
>
> interrupts:
> maxItems: 1
> @@ -75,6 +81,26 @@ properties:
> items:
> pattern: '^[A-Z][A-Z]-[A-Z][0-9A-Z]-[0-9]+$'
>
> + brcm,cal-blob:
> + $ref: /schemas/types.yaml#/definitions/uint8-array
> + description: A per-device calibration blob for the Wi-Fi radio. This
> + should be filled in by the bootloader from platform configuration
> + data, if necessary, and will be uploaded to the device if present.
> +
> + apple,module-instance:
> + $ref: /schemas/types.yaml#/definitions/string
> + description: Module codename used to identify a specific board on
> + Apple platforms. This is used to build the firmware filenames, to allow
> + different platforms to have different firmware and/or NVRAM config.
> +
> + apple,antenna-sku:
> + $def: /schemas/types.yaml#/definitions/string
> + description: Antenna SKU used to identify a specific antenna configuration
> + on Apple platforms. This is use to build firmware filenames, to allow
> + platforms with different antenna configs to have different firmware and/or
> + NVRAM. This would normally be filled in by the bootloader from platform
> + configuration data.
> +
> required:
> - compatible
> - reg
> --
> 2.33.0
>
>

2022-01-02 05:32:27

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:

> Apple platforms have firmware and config files identified with multiple
> dimensions. We want to be able to find the most specific firmware
> available for any given platform, progressively trying more general
> firmwares.
>
> First, add support for having multiple alternate firmware paths.
>
> Signed-off-by: Hector Martin <[email protected]>

This looks OK to me so FWIW:
Acked-by: Linus Walleij <[email protected]>

Make sure Dmitry Osipenko gets to review this though, he has many
valuable insights about how the FW is loaded and helped me out a
lot when I patched this.

Yours,
Linus Walleij

2022-01-02 05:34:21

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 06/34] brcmfmac: firmware: Support passing in multiple board_types

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:

> In order to make use of the multiple alt_path functionality, change
> board_type to an array. Bus drivers can pass in a NULL-terminated list
> of board type strings to try for the firmware fetch.
>
> Signed-off-by: Hector Martin <[email protected]>

Acked-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 05:38:44

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:

> On Apple platforms, the One Time Programmable ROM in the Broadcom chips
> contains information about the specific board design (module, vendor,
> version) that is required to select the correct NVRAM file. Parse this
> OTP ROM and extract the required strings.
>
> Note that the user OTP offset/size is per-chip. This patch does not add
> any chips yet.
>
> Signed-off-by: Hector Martin <[email protected]>

Overall looks fine!

> + const char *chip_params;
> + const char *module_params;

This variable name "module_params" is a bit confusing since loadable
kernel modules have params...

Can we think of another name and just put a comment that this
refers to the WiFi module building block?

Sometimes people talk about SoM:s (system-on-modules), so
maybe som_params or brcm_som_params?

Yours,
Linus Walleij

2022-01-02 05:41:06

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 08/34] brcmfmac: of: Fetch Apple properties

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:

> 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.
>
> The module-instance is hard-coded in per-board DTS files, 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.
>
> The module-instance is used to construct a board_type by prepending it
> with "apple,".
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 05:45:48

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 09/34] brcmfmac: pcie: Perform firmware selection for Apple platforms

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:

> On Apple platforms, firmware selection uses the following elements:
>
> Property Example Source
> ============== ======= ========================
> * Chip name 4378 Device ID
> * Chip revision B1 OTP
> * Platform shikoku DT (ARM64) or ACPI (x86)
> * Module type RASP OTP
> * Module vendor m OTP
> * Module version 6.11 OTP
> * Antenna SKU X3 DT (ARM64) or ??? (x86)
>
> In macOS, these firmwares are stored using filenames in this format
> under /usr/share/firmware/wifi:
>
> C-4378__s-B1/P-shikoku-X3_M-RASP_V-m__m-6.11.txt
>
> To prepare firmwares for Linux, we rename these to a scheme following
> the existing brcmfmac convention:
>
> brcmfmac<chip><lower(rev)>-pcie.apple,<platform>-<mod_type>-\
> <mod_vendor>-<mod_version>-<antenna_sku>.txt
>
> The NVRAM uses all the components, while the firmware and CLM blob only
> use the chip/revision/platform/antenna_sku:
>
> brcmfmac<chip><lower(rev)>-pcie.apple,<platform>-<antenna_sku>.bin
>
> e.g.
>
> brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11-X3.txt
> brcm/brcmfmac4378b1-pcie.apple,shikoku-X3.bin
>
> In addition, since there are over 1000 files in total, many of which are
> symlinks or outright duplicates, we deduplicate and prune the firmware
> tree to reduce firmware filenames to fewer dimensions. For example, the
> shikoku platform (MacBook Air M1 2020) simplifies to just 4 files:
>
> brcm/brcmfmac4378b1-pcie.apple,shikoku.clm_blob
> brcm/brcmfmac4378b1-pcie.apple,shikoku.bin
> brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m.txt
> brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-u.txt
>
> This reduces the total file count to around 170, of which 75 are
> symlinks and 95 are regular files: 7 firmware blobs, 27 CLM blobs, and
> 61 NVRAM config files. We also slightly process NVRAM files to correct
> some formatting issues and add a missing default macaddr= property.
>
> To handle this, the driver must try the following path formats when
> looking for firmware files:
>
> brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11-X3.txt
> brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11.txt
> brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m.txt
> brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP.txt
> brcm/brcmfmac4378b1-pcie.apple,shikoku-X3.txt *
> brcm/brcmfmac4378b1-pcie.apple,shikoku.txt
>
> * Not relevant for NVRAM, only for firmware/CLM.
>
> The chip revision nominally comes from OTP on Apple platforms, but it
> can be mapped to the PCI revision number, so we ignore the OTP revision
> and continue to use the existing PCI revision mechanism to identify chip
> revisions, as the driver already does for other chips. Unfortunately,
> the mapping is not consistent between different chip types, so this has
> to be determined experimentally.
>
> Signed-off-by: Hector Martin <[email protected]>

It's a neat hack, and I don't see anyone doing anything smarter so:
Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 05:50:31

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:

> On Device Tree platforms, it is customary to be able to set the MAC
> address via the Device Tree, as it is often stored in system firmware.
> This is particularly relevant for Apple ARM64 platforms, where this
> information comes from system configuration and passed through by the
> bootloader into the DT.
>
> Implement support for this by fetching the platform MAC address and
> adding or replacing the macaddr= property in nvram. This becomes the
> dongle's default MAC address.
>
> On platforms with an SROM MAC address, this overrides it. On platforms
> without one, such as Apple ARM64 devices, this is required for the
> firmware to boot (it will fail if it does not have a valid MAC at all).
>
> Signed-off-by: Hector Martin <[email protected]>

This looks very helpful.

> + /* Add space for properties we may add */
> + size += strlen(BRCMF_FW_DEFAULT_BOARDREV) + 1;
> + size += BRCMF_FW_MACADDR_LEN + 1;

Add some note to the commit log why you also make space for
boardrev? (Looks useful.) Is the boardrev spacing in the right
patch?

With that addressed:
Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 05:52:05

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 11/34] brcmfmac: msgbuf: Increase RX ring sizes to 1024

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <[email protected]> wrote:

> Newer chips used on Apple platforms have more than max_rxbufpost greater
> than 512, which causes warnings when brcmf_msgbuf_rxbuf_data_fill tries
> to put more in the ring than fit. Increase the ring sizes to 1024.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 05:52:06

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 12/34] brcmfmac: pcie: Fix crashes due to early IRQs

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <[email protected]> wrote:

> The driver was enabling IRQs before the message processing was
> initialized. This could cause IRQs to come in too early and crash the
> driver. Instead, move the IRQ enable and hostready to a bus preinit
> function, at which point everything is properly initialized.
>
> Fixes: 9e37f045d5e7 ("brcmfmac: Adding PCIe bus layer support.")
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 05:53:30

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 13/34] brcmfmac: pcie: Support PCIe core revisions >= 64

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <[email protected]> wrote:

> These newer PCIe core revisions include new sets of registers that must
> be used instead of the legacy ones. Introduce a brcmf_pcie_reginfo to
> hold the specific register offsets and values to use for a given
> platform, and change all the register accesses to indirect through it.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 05:54:10

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 14/34] brcmfmac: pcie: Add IDs/properties for BCM4378

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <[email protected]> wrote:

> This chip is present on Apple M1 (t8103) platforms:
>
> * atlantisb (apple,j274): Mac mini (M1, 2020)
> * honshu (apple,j293): MacBook Pro (13-inch, M1, 2020)
> * shikoku (apple,j313): MacBook Air (M1, 2020)
> * capri (apple,j456): iMac (24-inch, 4x USB-C, M1, 2020)
> * santorini (apple,j457): iMac (24-inch, 2x USB-C, M1, 2020)
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 05:59:01

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <[email protected]> wrote:

> On DT platforms, the module-instance and antenna-sku-info properties
> are passed in the DT. On ACPI platforms, module-instance is passed via
> the analogous Apple device property mechanism, while the antenna SKU
> info is instead obtained via an ACPI method that grabs it from
> non-volatile storage.
>
> Add support for this, to allow proper firmware selection on Apple
> platforms.
>
> Signed-off-by: Hector Martin <[email protected]>

If the strings treated here are exactly the same as for the device tree,
you should be able to just use "devprops" (firmware node) to handle it
abstractly, and then the respective DT and ACPI backend will provide
the properties.

I don't know if this patch I made recently is enough of an examples:
https://lore.kernel.org/linux-hwmon/[email protected]/

If the ACPI and DT differs a lot in format and strings etc it may not
be worth it.

Yours,
Linus Walleij

2022-01-02 06:00:10

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 17/34] brcmfmac: pcie: Provide a buffer of random bytes to the device

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <[email protected]> wrote:

> Newer Apple firmwares on chipsets without a hardware RNG require the
> host to provide a buffer of 256 random bytes to the device on
> initialization. This buffer is present immediately before NVRAM,
> suffixed by a footer containing a magic number and the buffer length.
>
> This won't affect chips/firmwares that do not use this feature, so do it
> unconditionally.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:00:57

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 18/34] brcmfmac: pcie: Add IDs/properties for BCM4355

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <[email protected]> wrote:

> This chip is present on at least these Apple T2 Macs:
>
> * hawaii: MacBook Air 13" (Late 2018)
> * hawaii: MacBook Air 13" (True Tone, 2019)
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:01:41

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 19/34] brcmfmac: pcie: Add IDs/properties for BCM4377

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <[email protected]> wrote:

> This chip is present on at least these Apple T2 Macs:
>
> * tahiti: MacBook Pro 13" (2020, 2 TB3)
> * formosa: MacBook Pro 13" (Touch/2019)
> * fiji: MacBook Air 13" (Scissor, 2020)
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:02:28

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 20/34] brcmfmac: pcie: Perform correct BCM4364 firmware selection

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <[email protected]> wrote:

> This chip exists in two revisions (B2=r3 and B3=r4) on different
> platforms, and was added without regard to doing proper firmware
> selection or differentiating between them. Fix this to have proper
> per-revision firmwares and support Apple NVRAM selection.
>
> Revision B2 is present on at least these Apple T2 Macs:
>
> kauai: MacBook Pro 15" (Touch/2018-2019)
> maui: MacBook Pro 13" (Touch/2018-2019)
> lanai: Mac mini (Late 2018)
> ekans: iMac Pro 27" (5K, Late 2017)
>
> And these non-T2 Macs:
>
> nihau: iMac 27" (5K, 2019)
>
> Revision B3 is present on at least these Apple T2 Macs:
>
> bali: MacBook Pro 16" (2019)
> trinidad: MacBook Pro 13" (2020, 4 TB3)
> borneo: MacBook Pro 16" (2019, 5600M)
> kahana: Mac Pro (2019)
> kahana: Mac Pro (2019, Rack)
> hanauma: iMac 27" (5K, 2020)
> kure: iMac 27" (5K, 2020, 5700/XT)
>
> Fixes: 24f0bd136264 ("brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2")
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:03:30

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 21/34] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <[email protected]> wrote:

> At least on BCM4387, the D11 cores are held in reset on cold startup and
> firmware expects to release reset itself. Just assert reset here and let
> firmware deassert it. Premature deassertion results in the firmware
> failing to initialize properly some of the time, with strange AXI bus
> errors.
>
> Also, BCM4387 has 3 cores, up from 2. The logic for handling that is in
> brcmf_chip_ai_resetcore(), but since we aren't using that any more, just
> handle it here.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:10:12

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 22/34] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <[email protected]> wrote:

> BCM4387 has trailing odd-sized blocks as part of TCM which have
> their size described as a multiple of 1024 instead of 8192. Handle this
> so we can compute the TCM size properly.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:11:52

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 24/34] brcmfmac: feature: Add support for setting feats based on WLC version

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <[email protected]> wrote:

> The "wlc_ver" iovar returns information on the WLC and EPI versions.
> This can be used to determine whether the PMKID_V2 and _V3 features are
> supported.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:12:44

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 25/34] brcmfmac: cfg80211: Add support for PMKID_V3 operations

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <[email protected]> wrote:

> Add support for the new PMKID_V3 API, which allows performing PMKID
> mutations individually, instead of requiring the driver to keep track of
> the full list. This new API is required by at least BCM4387.
>
> Note that PMKID_V2 is not implemented yet.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:13:30

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 26/34] brcmfmac: cfg80211: Pass the PMK in binary instead of hex

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <[email protected]> wrote:

> Apparently the hex passphrase mechanism does not work on newer
> chips/firmware (e.g. BCM4387). It seems there was a simple way of
> passing it in binary all along, so use that and avoid the hexification.
>
> OpenBSD has been doing it like this from the beginning, so this should
> work on all chips.
>
> Also clear the structure before setting the PMK. This was leaking
> uninitialized stack contents to the device.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:14:03

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 27/34] brcmfmac: pcie: Add IDs/properties for BCM4387

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <[email protected]> wrote:

> This chip is present on Apple M1 Pro/Max (t600x) platforms:
>
> * maldives (apple,j314s): MacBook Pro (14-inch, M1 Pro, 2021)
> * maldives (apple,j314c): MacBook Pro (14-inch, M1 Max, 2021)
> * madagascar (apple,j316s): MacBook Pro (16-inch, M1 Pro, 2021)
> * madagascar (apple,j316c): MacBook Pro (16-inch, M1 Max, 2021)
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:15:21

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 28/34] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <[email protected]> wrote:

> The alignment check was wrong (e.g. & 4 instead of & 3), and the logic
> was also inefficient if the length was not a multiple of 4, since it
> would needlessly fall back to copying the entire buffer bytewise.
>
> We already have a perfectly good memcpy_toio function, so just call that
> instead of rolling our own copy logic here. brcmf_pcie_init_ringbuffers
> was already using it anyway.
>
> Fixes: 9e37f045d5e7 ("brcmfmac: Adding PCIe bus layer support.")
> Signed-off-by: Hector Martin <[email protected]>

Excellent patch.
Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:16:31

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 29/34] brcmfmac: pcie: Read the console on init and shutdown

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <[email protected]> wrote:

> This allows us to get console messages if the firmware crashed during
> early init, or if an operation failed and we're about to shut down.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:17:57

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 30/34] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <[email protected]> wrote:

> This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that
> the CLM blob is released in the device remove path.
>
> Fixes: 82f93cf46d60 ("brcmfmac: get chip's default RAM info during PCIe setup")
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:18:03

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 31/34] brcmfmac: fwil: Constify iovar name arguments

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <[email protected]> wrote:

> Make all the iovar name arguments const char * instead of just char *.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:18:56

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 32/34] brcmfmac: common: Add support for downloading TxCap blobs

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <[email protected]> wrote:

> The TxCap blobs are additional data blobs used on Apple devices, and
> are uploaded analogously to CLM blobs. Add core support for doing this.
>
> Signed-off-by: Hector Martin <[email protected]>

Acked-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:19:31

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 33/34] brcmfmac: pcie: Load and provide TxCap blobs

On Sun, Dec 26, 2021 at 4:41 PM Hector Martin <[email protected]> wrote:

> These blobs are named .txcap_blob, and exist alongside the existing
> .clm_blob files. Use the existing firmware machinery to provide them to
> the core.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:20:06

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 34/34] brcmfmac: common: Add support for external calibration blobs

On Sun, Dec 26, 2021 at 4:41 PM Hector Martin <[email protected]> wrote:

> The calibration blob for a chip is normally stored in SROM and loaded
> internally by the firmware. However, Apple ARM64 platforms instead store
> it as part of platform configuration data, and provide it via the Apple
> Device Tree. We forward this into the Linux DT in the bootloader.
>
> Add support for taking this blob from the DT and loading it into the
> dongle. The loading mechanism is the same as used for the CLM and TxCap
> blobs.
>
> Signed-off-by: Hector Martin <[email protected]>

Reviewed-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:20:59

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <[email protected]> wrote:

> The Wi-Fi module in Apple machines has a "module-instance" device
> property that specifies the platform type and is used for firmware
> selection. Its value is a string, so add support for string values in
> acpi_extract_apple_properties().
>
> Signed-off-by: Hector Martin <[email protected]>

Acked-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:22:48

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 05/34] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:

> Now that the firmware fetcher can handle per-board CLM files, load the
> CLM blob alongside the other firmware files and change the bus API to
> just return the existing blob, instead of fetching the filename.
>
> This enables per-board CLM blobs, which are required on Apple platforms.
>
> Signed-off-by: Hector Martin <[email protected]>

Acked-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:23:40

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 23/34] brcmfmac: cfg80211: Add support for scan params v2

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <[email protected]> wrote:

> This new API version is required for at least the BCM4387 firmware. Add
> support for it, with a fallback to the v1 API.
>
> Signed-off-by: Hector Martin <[email protected]>

Acked-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:24:40

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 04/34] brcmfmac: firmware: Handle per-board clm_blob files

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:

> Teach brcm_alt_fw_paths to correctly split off variable length
> extensions, and enable alt firmware lookups for the CLM blob firmware
> requests.
>
> Apple platforms have per-board CLM blob files.
>
> Signed-off-by: Hector Martin <[email protected]>

Acked-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-02 06:26:20

by Linus Walleij

[permalink] [raw]
Subject: Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms

On Sun, Dec 26, 2021 at 4:36 PM Hector Martin <[email protected]> wrote:

> Merry Christmas! This year Santa brings us a 34-patch series to add
> proper support for the Broadcom FullMAC chips used on Apple T2 and M1
> platforms:

I tried to review as best I could, when I think I know what I'm doing I state
Reviewed-by and when I think it just LooksGoodToMe(TM) I replied
Acked-by. If I missed some patch you can assume Acked-by from me
on these as well.

Thanks for doing this, some really old bugs and code improvements long
overdue is in the series, much appreciated.

Yours,
Linus Walleij

2022-01-02 06:38:20

by Dmitry Osipenko

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

26.12.2021 18:35, Hector Martin пишет:
> Apple platforms have firmware and config files identified with multiple
> dimensions. We want to be able to find the most specific firmware
> available for any given platform, progressively trying more general
> firmwares.
>
> First, add support for having multiple alternate firmware paths.
>
> Signed-off-by: Hector Martin <[email protected]>
> ---
> .../broadcom/brcm80211/brcmfmac/firmware.c | 73 ++++++++++++++-----
> 1 file changed, 55 insertions(+), 18 deletions(-)

...
> -static char *brcm_alt_fw_path(const char *path, const char *board_type)
> +static const char **brcm_alt_fw_paths(const char *path, const char *board_type)
...
> static int brcmf_fw_request_firmware(const struct firmware **fw,
> struct brcmf_fw *fwctx)
> {
> struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
> - int ret;
> + int ret, i;
>
> /* Files can be board-specific, first try a board-specific path */
> if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
> - char *alt_path;
> + const char **alt_paths = brcm_alt_fw_paths(cur->path, fwctx);

The brcm_alt_fw_paths() takes "board_type" argument, while you're
passing the "fwctx" to it. This patch doesn't compile.

If this code is changed by a further patch, then please use "git rebase
--exec" to compile-test all the patches.

drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c: In function
‘brcmf_fw_request_firmware’:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:642:71:
error: passing argument 2 of ‘brcm_alt_fw_paths’ from incompatible
pointer type [-Werror=incompatible-pointer-types]
642 | const char **alt_paths =
brcm_alt_fw_paths(cur->path, fwctx);
|
^~~~~
|
|
|
struct brcmf_fw *
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:597:69:
note: expected ‘const char *’ but argument is of type ‘struct brcmf_fw *’
597 | static const char **brcm_alt_fw_paths(const char *path, const
char *board_type)
|
~~~~~~~~~~~~^~~~~~~~~~
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c: In function
‘brcmf_fw_get_firmwares’:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:752:59:
error: passing argument 2 of ‘brcm_alt_fw_paths’ from incompatible
pointer type [-Werror=incompatible-pointer-types]
752 | fwctx->alt_paths = brcm_alt_fw_paths(first->path, fwctx);
| ^~~~~
| |
| struct
brcmf_fw *
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:597:69:
note: expected ‘const char *’ but argument is of type ‘struct brcmf_fw *’
597 | static const char **brcm_alt_fw_paths(const char *path, const
char *board_type)
|
~~~~~~~~~~~~^~~~~~~~~~
cc1: some warnings being treated as errors

2022-01-02 06:45:37

by Dmitry Osipenko

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

26.12.2021 18:35, Hector Martin пишет:
> -static char *brcm_alt_fw_path(const char *path, const char *board_type)
> +static const char **brcm_alt_fw_paths(const char *path, const char *board_type)
> {
> char alt_path[BRCMF_FW_NAME_LEN];
> + char **alt_paths;
> char suffix[5];
>
> strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
> @@ -609,27 +612,46 @@ static char *brcm_alt_fw_path(const char *path, const char *board_type)
> strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
> strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
>
> - return kstrdup(alt_path, GFP_KERNEL);
> + alt_paths = kzalloc(sizeof(char *) * 2, GFP_KERNEL);

array_size()?

> + alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
> +
> + return (const char **)alt_paths;

Why this casting is needed?

> +}


2022-01-02 06:55:49

by Dmitry Osipenko

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

26.12.2021 18:35, Hector Martin пишет:
> struct brcmf_fw {
> struct device *dev;
> struct brcmf_fw_request *req;
> + const char **alt_paths;

> + int alt_index;
...
> +static void brcm_free_alt_fw_paths(const char **alt_paths)
> +{
> + int i;
...
> static int brcmf_fw_request_firmware(const struct firmware **fw,
> struct brcmf_fw *fwctx)
> {
> struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
> - int ret;
> + int ret, i;

unsigned int

2022-01-02 07:08:38

by Dmitry Osipenko

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

26.12.2021 18:35, Hector Martin пишет:
> +static void brcm_free_alt_fw_paths(const char **alt_paths)
> +{
> + int i;
> +
> + if (!alt_paths)
> + return;
> +
> + for (i = 0; alt_paths[i]; i++)
> + kfree(alt_paths[i]);
> +
> + kfree(alt_paths);
> }
>
> static int brcmf_fw_request_firmware(const struct firmware **fw,
> struct brcmf_fw *fwctx)
> {
> struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
> - int ret;
> + int ret, i;
>
> /* Files can be board-specific, first try a board-specific path */
> if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
> - char *alt_path;
> + const char **alt_paths = brcm_alt_fw_paths(cur->path, fwctx);
>
> - alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);
> - if (!alt_path)
> + if (!alt_paths)
> goto fallback;
>
> - ret = request_firmware(fw, alt_path, fwctx->dev);
> - kfree(alt_path);
> - if (ret == 0)
> - return ret;
> + for (i = 0; alt_paths[i]; i++) {
> + ret = firmware_request_nowarn(fw, alt_paths[i], fwctx->dev);
> + if (ret == 0) {
> + brcm_free_alt_fw_paths(alt_paths);
> + return ret;
> + }
> + }
> + brcm_free_alt_fw_paths(alt_paths);
> }
>
> fallback:
> @@ -641,6 +663,9 @@ static void brcmf_fw_request_done(const struct firmware *fw, void *ctx)
> struct brcmf_fw *fwctx = ctx;
> int ret;
>
> + brcm_free_alt_fw_paths(fwctx->alt_paths);
> + fwctx->alt_paths = NULL;

It looks suspicious that fwctx->alt_paths isn't zero'ed by other code
paths. The brcm_free_alt_fw_paths() should take fwctx for the argument
and fwctx->alt_paths should be set to NULL there.

On the other hand, I'd change the **alt_paths to a fixed-size array.
This should simplify the code, making it easier to follow and maintain.

- const char **alt_paths;
+ char *alt_paths[BRCM_MAX_ALT_FW_PATHS];

Then you also won't need to NULL-terminate the array, which is a common
source of bugs in kernel.

2022-01-02 07:10:45

by Dmitry Osipenko

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

02.01.2022 08:31, Linus Walleij пишет:
> On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:
>
>> Apple platforms have firmware and config files identified with multiple
>> dimensions. We want to be able to find the most specific firmware
>> available for any given platform, progressively trying more general
>> firmwares.
>>
>> First, add support for having multiple alternate firmware paths.
>>
>> Signed-off-by: Hector Martin <[email protected]>
>
> This looks OK to me so FWIW:
> Acked-by: Linus Walleij <[email protected]>
>
> Make sure Dmitry Osipenko gets to review this though, he has many
> valuable insights about how the FW is loaded and helped me out a
> lot when I patched this.

Thanks, Linus. I took a brief look at the patch and may give it a test
next time, once it will compile without errors and warnings.

2022-01-02 07:20:46

by Dmitry Osipenko

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

02.01.2022 10:08, Dmitry Osipenko пишет:
> 26.12.2021 18:35, Hector Martin пишет:
>> +static void brcm_free_alt_fw_paths(const char **alt_paths)
>> +{
>> + int i;
>> +
>> + if (!alt_paths)
>> + return;
>> +
>> + for (i = 0; alt_paths[i]; i++)
>> + kfree(alt_paths[i]);
>> +
>> + kfree(alt_paths);
>> }
>>
>> static int brcmf_fw_request_firmware(const struct firmware **fw,
>> struct brcmf_fw *fwctx)
>> {
>> struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
>> - int ret;
>> + int ret, i;
>>
>> /* Files can be board-specific, first try a board-specific path */
>> if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
>> - char *alt_path;
>> + const char **alt_paths = brcm_alt_fw_paths(cur->path, fwctx);
>>
>> - alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);
>> - if (!alt_path)
>> + if (!alt_paths)
>> goto fallback;
>>
>> - ret = request_firmware(fw, alt_path, fwctx->dev);
>> - kfree(alt_path);
>> - if (ret == 0)
>> - return ret;
>> + for (i = 0; alt_paths[i]; i++) {
>> + ret = firmware_request_nowarn(fw, alt_paths[i], fwctx->dev);
>> + if (ret == 0) {
>> + brcm_free_alt_fw_paths(alt_paths);
>> + return ret;
>> + }
>> + }
>> + brcm_free_alt_fw_paths(alt_paths);
>> }
>>
>> fallback:
>> @@ -641,6 +663,9 @@ static void brcmf_fw_request_done(const struct firmware *fw, void *ctx)
>> struct brcmf_fw *fwctx = ctx;
>> int ret;
>>
>> + brcm_free_alt_fw_paths(fwctx->alt_paths);
>> + fwctx->alt_paths = NULL;
>
> It looks suspicious that fwctx->alt_paths isn't zero'ed by other code
> paths. The brcm_free_alt_fw_paths() should take fwctx for the argument
> and fwctx->alt_paths should be set to NULL there.
>
> On the other hand, I'd change the **alt_paths to a fixed-size array.
> This should simplify the code, making it easier to follow and maintain.
>
> - const char **alt_paths;
> + char *alt_paths[BRCM_MAX_ALT_FW_PATHS];

Although, the const should be kept.

const char *alt_paths[BRCM_MAX_ALT_FW_PATHS];

>
> Then you also won't need to NULL-terminate the array, which is a common
> source of bugs in kernel.
>


2022-01-02 14:13:00

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

On 2021/12/30 1:38, Mark Kettenis wrote:
>> From: Hector Martin <[email protected]>
>> Date: Tue, 28 Dec 2021 02:23:02 +0900
>>
>> On 28/12/2021 01.36, Rob Herring wrote:
>>> On Mon, Dec 27, 2021 at 12:35:51AM +0900, Hector Martin wrote:
>>>> + brcm,cal-blob:
>>>> + $ref: /schemas/types.yaml#/definitions/uint8-array
>>>> + description: A per-device calibration blob for the Wi-Fi radio. This
>>>> + should be filled in by the bootloader from platform configuration
>>>> + data, if necessary, and will be uploaded to the device if present.
>>>> +
>>>> + apple,module-instance:
>>>> + $ref: /schemas/types.yaml#/definitions/string
>>>> + description: Module codename used to identify a specific board on
>>>> + Apple platforms. This is used to build the firmware filenames, to allow
>>>> + different platforms to have different firmware and/or NVRAM config.
>>>> +
>>>> + apple,antenna-sku:
>>>> + $def: /schemas/types.yaml#/definitions/string
>>>> + description: Antenna SKU used to identify a specific antenna configuration
>>>> + on Apple platforms. This is use to build firmware filenames, to allow
>>>> + platforms with different antenna configs to have different firmware and/or
>>>> + NVRAM. This would normally be filled in by the bootloader from platform
>>>> + configuration data.
>>>
>>> Is there a known set of strings that can be defined?
>>
>> For apple,module-instance there is, though it will grow with every new
>> machine. If you're happy with me pushing updates to this through
>> asahi-soc I can keep it maintained as we add DTs and compatibles there.
>>
>> I'm curious whether you prefer this approach or something like
>> brcm,board-name instead. Right now we do:
>>
>> apple,module-instance = "honshu"
>>
>> That gets converted to board_name="apple,honshu" in the code, which is
>> what the firmwares are named after (plus extra info later appended, if
>> the rest of the Apple data is available).
>>
>> But we could also do:
>>
>> brcm,board-name = "apple,honshu"
>>
>> The latter would be more generically useful for other platforms, since
>> it would allow e.g. having DTs for different boards that use the same
>> WiFi module/subsystem and thus a compatible NVRAM fw file alias to the
>> same file name (right now this is done with symlinks in /lib/firmware,
>> one for each equivalent board). For non-Apple platforms (i.e. if
>> antenna-sku and/or the OTP aren't available to do the funky Apple
>> firmware selection), this just ends up replacing what would normally be
>> the OF root node compatible in the firmware filename.
>>
>> E.g. right now we have:
>>
>> brcmfmac43430-sdio.AP6212.txt
>> brcmfmac43430-sdio.raspberrypi,3-model-b.txt
>> brcmfmac43430-sdio.raspberrypi,model-zero-w.txt -> brcmfmac43430-sdio.raspberrypi,3-model-b.txt
>> brcmfmac43430-sdio.sinovoip,bpi-m2-plus.txt -> brcmfmac43430-sdio.AP6212.txt
>> brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt -> brcmfmac43430-sdio.AP6212.txt
>> brcmfmac43430-sdio.sinovoip,bpi-m2-zero.txt -> brcmfmac43430-sdio.AP6212.txt
>> brcmfmac43430-sdio.sinovoip,bpi-m3.txt -> brcmfmac43430-sdio.AP6212.txt
>>
>> And this could allow the sinovoip.* DTs to say:
>> brcm,board-name = "AP6212";
>>
>> And the rPi zero one:
>> brcm,board-name = "raspberrypi,3-model-b";
>>
>> And avoid the symlinks.
>>
>> The antenna-sku thing is specific to the Apple firmware selection
>> process and doesn't make sense as a more generic property.
>>
>> antenna-sku right now always seems to be one of "ID", "X0", "X2", "X3",
>> though that could presumably change in the future. I can add this to the
>> binding if you want, though since this will be filled in by the
>> bootloader from platform data we wouldn't be validating it anyway. Not
>> sure if it's worth it.
>
> Actually what Apple does here makes quite a bit of sense. Typically
> WiFi chips are integrated with some analog components into a shielded
> module. The AP6212 mentioned above is an example of such a module. I
> suspect that the module defines some of the characteristics encoded in
> the "nvmram" files, but certainly not all because the connected
> antenna will also affect how the thing behaves. Of course many SBCs
> come without an antenna so the actual antenna depends on whatever the
> user connects to the board. So using a module-specific "nvram" file
> is probably the best one can do here. So I think if you want to have
> a generic module name property, it should be called "brcm,module-name"
> instead of "brcm,board-name". However...
>
>>> There's also the somewhat standard 'firmware-name' property that
>>> serves similar purpose, but if there's multiple files, then I guess
>>> this approach is fine.
>>
>> Yeah, and the firmware name is constructed using non-DT information too
>> (and we have several attempted filenames times several firmware types),
>> so it wouldn't be complete.
>
> ...if the way the firmware name is constructed remains Apple-specific
> because of this non-DT information, keeping the "apple,xxx" properties
> has the benefit of signalling that firmware names constructed this way
> are desired. Or rather, their absence can signal that the
> Apple-specific code in the driver should be skipped.
>

The current logic is that if all the information is available (OTP,
antenna-sku, board-name but that always gets filled in by default from
DT/DMI global info) it will use the Apple mechanism, otherwise it will
use the standard one. So in this case we could still use
brcm,board-name/module-name for Apple devices, and we'd keep
apple,antenna-sku as one of the two triggers to do Apple firmware
selection. Other devices may use nothing (use default DMI or DT device
name/compatible as module-name) or specify an override, and they will
still get firmwares with that name in them and a fallback to generic
firmware, which is the current behavior.

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-02 14:18:20

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

On 2022/01/02 15:45, Dmitry Osipenko wrote:
> 26.12.2021 18:35, Hector Martin пишет:
>> -static char *brcm_alt_fw_path(const char *path, const char *board_type)
>> +static const char **brcm_alt_fw_paths(const char *path, const char *board_type)
>> {
>> char alt_path[BRCMF_FW_NAME_LEN];
>> + char **alt_paths;
>> char suffix[5];
>>
>> strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
>> @@ -609,27 +612,46 @@ static char *brcm_alt_fw_path(const char *path, const char *board_type)
>> strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
>> strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
>>
>> - return kstrdup(alt_path, GFP_KERNEL);
>> + alt_paths = kzalloc(sizeof(char *) * 2, GFP_KERNEL);
>
> array_size()?

Of what array?

>
>> + alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
>> +
>> + return (const char **)alt_paths;
>
> Why this casting is needed?

Because implicit conversion from char ** to const char ** is not legal
in C, as that could cause const unsoundness if you do this:

char *foo[1];
const char **bar = foo;

bar[0] = "constant string";
foo[0][0] = '!'; // clobbers constant string

But it's fine in this case since the non-const pointer disappears so
nothing can ever write through it again.

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-02 14:25:42

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

On 2022/01/02 16:08, Dmitry Osipenko wrote:
> 26.12.2021 18:35, Hector Martin пишет:
>> +static void brcm_free_alt_fw_paths(const char **alt_paths)
>> +{
>> + int i;
>> +
>> + if (!alt_paths)
>> + return;
>> +
>> + for (i = 0; alt_paths[i]; i++)
>> + kfree(alt_paths[i]);
>> +
>> + kfree(alt_paths);
>> }
>>
>> static int brcmf_fw_request_firmware(const struct firmware **fw,
>> struct brcmf_fw *fwctx)
>> {
>> struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
>> - int ret;
>> + int ret, i;
>>
>> /* Files can be board-specific, first try a board-specific path */
>> if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
>> - char *alt_path;
>> + const char **alt_paths = brcm_alt_fw_paths(cur->path, fwctx);
>>
>> - alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);
>> - if (!alt_path)
>> + if (!alt_paths)
>> goto fallback;
>>
>> - ret = request_firmware(fw, alt_path, fwctx->dev);
>> - kfree(alt_path);
>> - if (ret == 0)
>> - return ret;
>> + for (i = 0; alt_paths[i]; i++) {
>> + ret = firmware_request_nowarn(fw, alt_paths[i], fwctx->dev);
>> + if (ret == 0) {
>> + brcm_free_alt_fw_paths(alt_paths);
>> + return ret;
>> + }
>> + }
>> + brcm_free_alt_fw_paths(alt_paths);
>> }
>>
>> fallback:
>> @@ -641,6 +663,9 @@ static void brcmf_fw_request_done(const struct firmware *fw, void *ctx)
>> struct brcmf_fw *fwctx = ctx;
>> int ret;
>>
>> + brcm_free_alt_fw_paths(fwctx->alt_paths);
>> + fwctx->alt_paths = NULL;
>
> It looks suspicious that fwctx->alt_paths isn't zero'ed by other code
> paths. The brcm_free_alt_fw_paths() should take fwctx for the argument
> and fwctx->alt_paths should be set to NULL there.

There are multiple code paths for alt_paths; the initial firmware lookup
uses fwctx->alt_paths, and once we know the firmware load succeeded we
use blocking firmware requests for NVRAM/CLM/etc and those do not use
the fwctx member, but rather just keep alt_paths in function scope
(brcmf_fw_request_firmware). You're right that there was a rebase SNAFU
there though, I'll compile test each patch before sending v2. Sorry
about that. In this series the code should build again by patch #6.

Are you thinking of any particular code paths? As far as I saw when
writing this, brcmf_fw_request_done() should always get called whether
things succeed or fail. There are no other code paths that free
fwctx->alt_paths.

> On the other hand, I'd change the **alt_paths to a fixed-size array.
> This should simplify the code, making it easier to follow and maintain.
>
> - const char **alt_paths;
> + char *alt_paths[BRCM_MAX_ALT_FW_PATHS];
>
> Then you also won't need to NULL-terminate the array, which is a common
> source of bugs in kernel.

That sounds reasonable, it'll certainly make the code simpler. I'll do
that for v2.


--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-02 20:11:40

by Dmitry Osipenko

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

02.01.2022 17:18, Hector Martin пишет:
> On 2022/01/02 15:45, Dmitry Osipenko wrote:
>> 26.12.2021 18:35, Hector Martin пишет:
>>> -static char *brcm_alt_fw_path(const char *path, const char *board_type)
>>> +static const char **brcm_alt_fw_paths(const char *path, const char *board_type)
>>> {
>>> char alt_path[BRCMF_FW_NAME_LEN];
>>> + char **alt_paths;
>>> char suffix[5];
>>>
>>> strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
>>> @@ -609,27 +612,46 @@ static char *brcm_alt_fw_path(const char *path, const char *board_type)
>>> strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
>>> strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
>>>
>>> - return kstrdup(alt_path, GFP_KERNEL);
>>> + alt_paths = kzalloc(sizeof(char *) * 2, GFP_KERNEL);
>>
>> array_size()?
>
> Of what array?

array_size(sizeof(*alt_paths), 2)

>>> + alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
>>> +
>>> + return (const char **)alt_paths;
>>
>> Why this casting is needed?
>
> Because implicit conversion from char ** to const char ** is not legal
> in C, as that could cause const unsoundness if you do this:
>
> char *foo[1];
> const char **bar = foo;
>
> bar[0] = "constant string";
> foo[0][0] = '!'; // clobbers constant string

It's up to a programmer to decide what is right to do. C gives you
flexibility, meanwhile it's easy to shoot yourself in the foot if you
won't be careful.

> But it's fine in this case since the non-const pointer disappears so
> nothing can ever write through it again.
>

There is indeed no need for the castings in such cases, it's a typical
code pattern in kernel. You would need to do the casting for the other
way around, i.e. if char ** was returned and **alt_paths was a const.

2022-01-02 20:12:48

by Dmitry Osipenko

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

02.01.2022 17:25, Hector Martin пишет:
> On 2022/01/02 16:08, Dmitry Osipenko wrote:
>> 26.12.2021 18:35, Hector Martin пишет:
>>> +static void brcm_free_alt_fw_paths(const char **alt_paths)
>>> +{
>>> + int i;
>>> +
>>> + if (!alt_paths)
>>> + return;
>>> +
>>> + for (i = 0; alt_paths[i]; i++)
>>> + kfree(alt_paths[i]);
>>> +
>>> + kfree(alt_paths);
>>> }
>>>
>>> static int brcmf_fw_request_firmware(const struct firmware **fw,
>>> struct brcmf_fw *fwctx)
>>> {
>>> struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
>>> - int ret;
>>> + int ret, i;
>>>
>>> /* Files can be board-specific, first try a board-specific path */
>>> if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
>>> - char *alt_path;
>>> + const char **alt_paths = brcm_alt_fw_paths(cur->path, fwctx);
>>>
>>> - alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);
>>> - if (!alt_path)
>>> + if (!alt_paths)
>>> goto fallback;
>>>
>>> - ret = request_firmware(fw, alt_path, fwctx->dev);
>>> - kfree(alt_path);
>>> - if (ret == 0)
>>> - return ret;
>>> + for (i = 0; alt_paths[i]; i++) {
>>> + ret = firmware_request_nowarn(fw, alt_paths[i], fwctx->dev);
>>> + if (ret == 0) {
>>> + brcm_free_alt_fw_paths(alt_paths);
>>> + return ret;
>>> + }
>>> + }
>>> + brcm_free_alt_fw_paths(alt_paths);
>>> }
>>>
>>> fallback:
>>> @@ -641,6 +663,9 @@ static void brcmf_fw_request_done(const struct firmware *fw, void *ctx)
>>> struct brcmf_fw *fwctx = ctx;
>>> int ret;
>>>
>>> + brcm_free_alt_fw_paths(fwctx->alt_paths);
>>> + fwctx->alt_paths = NULL;
>>
>> It looks suspicious that fwctx->alt_paths isn't zero'ed by other code
>> paths. The brcm_free_alt_fw_paths() should take fwctx for the argument
>> and fwctx->alt_paths should be set to NULL there.
>
> There are multiple code paths for alt_paths; the initial firmware lookup
> uses fwctx->alt_paths, and once we know the firmware load succeeded we
> use blocking firmware requests for NVRAM/CLM/etc and those do not use
> the fwctx member, but rather just keep alt_paths in function scope
> (brcmf_fw_request_firmware). You're right that there was a rebase SNAFU
> there though, I'll compile test each patch before sending v2. Sorry
> about that. In this series the code should build again by patch #6.
>
> Are you thinking of any particular code paths? As far as I saw when
> writing this, brcmf_fw_request_done() should always get called whether
> things succeed or fail. There are no other code paths that free
> fwctx->alt_paths.

It should be okay in the particular case then. But this is not obvious
without taking a closer look at the code, which is a sign that there is
some room for improvement.

>> On the other hand, I'd change the **alt_paths to a fixed-size array.
>> This should simplify the code, making it easier to follow and maintain.
>>
>> - const char **alt_paths;
>> + char *alt_paths[BRCM_MAX_ALT_FW_PATHS];
>>
>> Then you also won't need to NULL-terminate the array, which is a common
>> source of bugs in kernel.
>
> That sounds reasonable, it'll certainly make the code simpler. I'll do
> that for v2.

Feel free to CC me on v2. I'll take a closer look and give a test to the
patches on older hardware, checking for regressions.


2022-01-03 00:41:42

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

On 03/01/2022 05.11, Dmitry Osipenko wrote:
> 02.01.2022 17:18, Hector Martin пишет:
>> On 2022/01/02 15:45, Dmitry Osipenko wrote:
>>> 26.12.2021 18:35, Hector Martin пишет:
>>>> -static char *brcm_alt_fw_path(const char *path, const char *board_type)
>>>> +static const char **brcm_alt_fw_paths(const char *path, const char *board_type)
>>>> {
>>>> char alt_path[BRCMF_FW_NAME_LEN];
>>>> + char **alt_paths;
>>>> char suffix[5];
>>>>
>>>> strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
>>>> @@ -609,27 +612,46 @@ static char *brcm_alt_fw_path(const char *path, const char *board_type)
>>>> strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
>>>> strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
>>>>
>>>> - return kstrdup(alt_path, GFP_KERNEL);
>>>> + alt_paths = kzalloc(sizeof(char *) * 2, GFP_KERNEL);
>>>
>>> array_size()?
>>
>> Of what array?
>
> array_size(sizeof(*alt_paths), 2)

Heh, TIL. I thought you meant ARRAY_SIZE. First time I see the lowercase
macro. That's a confusing name collision...

>>>> + alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
>>>> +
>>>> + return (const char **)alt_paths;
>>>
>>> Why this casting is needed?
>>
>> Because implicit conversion from char ** to const char ** is not legal
>> in C, as that could cause const unsoundness if you do this:
>>
>> char *foo[1];
>> const char **bar = foo;
>>
>> bar[0] = "constant string";
>> foo[0][0] = '!'; // clobbers constant string
>
> It's up to a programmer to decide what is right to do. C gives you
> flexibility, meanwhile it's easy to shoot yourself in the foot if you
> won't be careful.

Which is why that conversion is illegal without a cast and you need to
explicitly choose to shoot yourself in the foot :-)

>> But it's fine in this case since the non-const pointer disappears so
>> nothing can ever write through it again.
>>
>
> There is indeed no need for the castings in such cases, it's a typical
> code pattern in kernel. You would need to do the casting for the other
> way around, i.e. if char ** was returned and **alt_paths was a const.

You do need to do the cast. Try it.

$ cat test.c
int main() {
char *foo[1];
const char **bar = foo;

return 0;
}

$ gcc test.c
test.c: In function ‘main’:
test.c:4:28: warning: initialization of ‘const char **’ from
incompatible pointer type ‘char **’ [-Wincompatible-pointer-types]
4 | const char **bar = foo;
|

You can implicitly cast char* to const char*, but you *cannot*
impliclicitly cast char** to const char** for the reason I explained. It
requires a cast.

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-03 01:26:22

by Dmitry Osipenko

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

03.01.2022 03:41, Hector Martin пишет:
>> There is indeed no need for the castings in such cases, it's a typical
>> code pattern in kernel. You would need to do the casting for the other
>> way around, i.e. if char ** was returned and **alt_paths was a const.
> You do need to do the cast. Try it.
>
> $ cat test.c
> int main() {
> char *foo[1];
> const char **bar = foo;
>
> return 0;
> }
>
> $ gcc test.c
> test.c: In function ‘main’:
> test.c:4:28: warning: initialization of ‘const char **’ from
> incompatible pointer type ‘char **’ [-Wincompatible-pointer-types]
> 4 | const char **bar = foo;
> |
>
> You can implicitly cast char* to const char*, but you *cannot*
> impliclicitly cast char** to const char** for the reason I explained. It
> requires a cast.

Right, I read it as "char * const *". The "const char **" vs "char *
const *" always confuses me.

Hence you should've written "const char **alt_paths;" in
brcm_alt_fw_paths() in the first place and then casting wouldn't have
been needed.

2022-01-03 05:42:54

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr

On 2022/01/02 14:50, Linus Walleij wrote:
> On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:
>
>> On Device Tree platforms, it is customary to be able to set the MAC
>> address via the Device Tree, as it is often stored in system firmware.
>> This is particularly relevant for Apple ARM64 platforms, where this
>> information comes from system configuration and passed through by the
>> bootloader into the DT.
>>
>> Implement support for this by fetching the platform MAC address and
>> adding or replacing the macaddr= property in nvram. This becomes the
>> dongle's default MAC address.
>>
>> On platforms with an SROM MAC address, this overrides it. On platforms
>> without one, such as Apple ARM64 devices, this is required for the
>> firmware to boot (it will fail if it does not have a valid MAC at all).
>>
>> Signed-off-by: Hector Martin <[email protected]>
>
> This looks very helpful.
>
>> + /* Add space for properties we may add */
>> + size += strlen(BRCMF_FW_DEFAULT_BOARDREV) + 1;
>> + size += BRCMF_FW_MACADDR_LEN + 1;
>
> Add some note to the commit log why you also make space for
> boardrev? (Looks useful.) Is the boardrev spacing in the right
> patch?

Ah, that was a drive-by fix. While adding the MACADDR space I noticed we
weren't allocating space for BOARDREV... not sure if any platforms hit
this; it would cause an overflow if there are platforms with no
board_rev in the nvram that also don't have enough comments/junk to
otherwise make space for it.

I'll move it to another patch so it's more evident, and it should get a
Fixes: too.

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-03 05:52:10

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information

On 2022/01/02 14:38, Linus Walleij wrote:
> On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:
>
>> On Apple platforms, the One Time Programmable ROM in the Broadcom chips
>> contains information about the specific board design (module, vendor,
>> version) that is required to select the correct NVRAM file. Parse this
>> OTP ROM and extract the required strings.
>>
>> Note that the user OTP offset/size is per-chip. This patch does not add
>> any chips yet.
>>
>> Signed-off-by: Hector Martin <[email protected]>
>
> Overall looks fine!
>
>> + const char *chip_params;
>> + const char *module_params;
>
> This variable name "module_params" is a bit confusing since loadable
> kernel modules have params...
>
> Can we think of another name and just put a comment that this
> refers to the WiFi module building block?
>
> Sometimes people talk about SoM:s (system-on-modules), so
> maybe som_params or brcm_som_params?
>
> Yours,
> Linus Walleij
>

How about board_params, since we're already calling those things boards
elsewhere in the driver? That could refer to the board of a standalone
module, or an integrated board, which should cover all cases.

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-03 06:03:39

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties

On 2022/01/02 14:58, Linus Walleij wrote:
> On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <[email protected]> wrote:
>
>> On DT platforms, the module-instance and antenna-sku-info properties
>> are passed in the DT. On ACPI platforms, module-instance is passed via
>> the analogous Apple device property mechanism, while the antenna SKU
>> info is instead obtained via an ACPI method that grabs it from
>> non-volatile storage.
>>
>> Add support for this, to allow proper firmware selection on Apple
>> platforms.
>>
>> Signed-off-by: Hector Martin <[email protected]>
>
> If the strings treated here are exactly the same as for the device tree,
> you should be able to just use "devprops" (firmware node) to handle it
> abstractly, and then the respective DT and ACPI backend will provide
> the properties.
>
> I don't know if this patch I made recently is enough of an examples:
> https://lore.kernel.org/linux-hwmon/[email protected]/
>
> If the ACPI and DT differs a lot in format and strings etc it may not
> be worth it.

It's not quite the same; module-instance is the same from macOS'
perspective, but we don't use Apple's device tree directly but rather
roll our own DT which uses a different property name in this case.
antenna-sku-info uses an ACPI method on x86, so that one is completely
different. So in the end nothing is actually shared.

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-03 06:18:08

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

On 2022/01/03 10:26, Dmitry Osipenko wrote:
> 03.01.2022 03:41, Hector Martin пишет:
>>> There is indeed no need for the castings in such cases, it's a typical
>>> code pattern in kernel. You would need to do the casting for the other
>>> way around, i.e. if char ** was returned and **alt_paths was a const.
>> You do need to do the cast. Try it.
>>
>> $ cat test.c
>> int main() {
>> char *foo[1];
>> const char **bar = foo;
>>
>> return 0;
>> }
>>
>> $ gcc test.c
>> test.c: In function ‘main’:
>> test.c:4:28: warning: initialization of ‘const char **’ from
>> incompatible pointer type ‘char **’ [-Wincompatible-pointer-types]
>> 4 | const char **bar = foo;
>> |
>>
>> You can implicitly cast char* to const char*, but you *cannot*
>> impliclicitly cast char** to const char** for the reason I explained. It
>> requires a cast.
>
> Right, I read it as "char * const *". The "const char **" vs "char *
> const *" always confuses me.
>
> Hence you should've written "const char **alt_paths;" in
> brcm_alt_fw_paths() in the first place and then casting wouldn't have
> been needed.

Sure, in this case that works since the string is just strduped and
never mutated. Either way this will change to an argument instead of a
return value, since I'll change it to be statically sized as you said
and allocated by the caller (or in the struct).

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-03 06:18:54

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths

On 2022/01/02 15:55, Dmitry Osipenko wrote:
> 26.12.2021 18:35, Hector Martin пишет:
>> struct brcmf_fw {
>> struct device *dev;
>> struct brcmf_fw_request *req;
>> + const char **alt_paths;
>
>> + int alt_index;
> ...
>> +static void brcm_free_alt_fw_paths(const char **alt_paths)
>> +{
>> + int i;
> ...
>> static int brcmf_fw_request_firmware(const struct firmware **fw,
>> struct brcmf_fw *fwctx)
>> {
>> struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
>> - int ret;
>> + int ret, i;
>
> unsigned int
>

Thanks, changed for v2!

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-03 06:27:40

by Hector Martin

[permalink] [raw]
Subject: Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms

On 2022/01/02 15:25, Linus Walleij wrote:
> On Sun, Dec 26, 2021 at 4:36 PM Hector Martin <[email protected]> wrote:
>
>> Merry Christmas! This year Santa brings us a 34-patch series to add
>> proper support for the Broadcom FullMAC chips used on Apple T2 and M1
>> platforms:
>
> I tried to review as best I could, when I think I know what I'm doing I state
> Reviewed-by and when I think it just LooksGoodToMe(TM) I replied
> Acked-by. If I missed some patch you can assume Acked-by from me
> on these as well.
>
> Thanks for doing this, some really old bugs and code improvements long
> overdue is in the series, much appreciated.
>
> Yours,
> Linus Walleij
>

Thanks for the comprehensive review! I'm glad this all makes some sense
and I'm not crazy about the approach :)

I'll wait a bit for any other feedback that might come in and then
submit a v2 with the fixes/changes mentioned so far.

Cheers,
--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-03 10:21:15

by Arend van Spriel

[permalink] [raw]
Subject: Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms

On 1/3/2022 7:27 AM, Hector Martin wrote:
> On 2022/01/02 15:25, Linus Walleij wrote:
>> On Sun, Dec 26, 2021 at 4:36 PM Hector Martin <[email protected]> wrote:
>>
>>> Merry Christmas! This year Santa brings us a 34-patch series to add
>>> proper support for the Broadcom FullMAC chips used on Apple T2 and M1
>>> platforms:
>>
>> I tried to review as best I could, when I think I know what I'm doing I state
>> Reviewed-by and when I think it just LooksGoodToMe(TM) I replied
>> Acked-by. If I missed some patch you can assume Acked-by from me
>> on these as well.
>>
>> Thanks for doing this, some really old bugs and code improvements long
>> overdue is in the series, much appreciated.
>>
>> Yours,
>> Linus Walleij
>>
>
> Thanks for the comprehensive review! I'm glad this all makes some sense
> and I'm not crazy about the approach :)
>
> I'll wait a bit for any other feedback that might come in and then
> submit a v2 with the fixes/changes mentioned so far.

Happy new year to you all. I wanted to start the new year relaxing by
reviewing this series, but with the comments already given I prefer to
do that with v2 so don't wait for me :-)

Regards,
Arend



Attachments:
smime.p7s (4.12 kB)
S/MIME Cryptographic Signature

2022-01-03 11:14:14

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information

On Mon, Jan 3, 2022 at 6:52 AM Hector Martin <[email protected]> wrote:
> On 2022/01/02 14:38, Linus Walleij wrote:
> > On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <[email protected]> wrote:
> >
> >> On Apple platforms, the One Time Programmable ROM in the Broadcom chips
> >> contains information about the specific board design (module, vendor,
> >> version) that is required to select the correct NVRAM file. Parse this
> >> OTP ROM and extract the required strings.
> >>
> >> Note that the user OTP offset/size is per-chip. This patch does not add
> >> any chips yet.
> >>
> >> Signed-off-by: Hector Martin <[email protected]>
> >
> > Overall looks fine!
> >
> >> + const char *chip_params;
> >> + const char *module_params;
> >
> > This variable name "module_params" is a bit confusing since loadable
> > kernel modules have params...
> >
> > Can we think of another name and just put a comment that this
> > refers to the WiFi module building block?
> >
> > Sometimes people talk about SoM:s (system-on-modules), so
> > maybe som_params or brcm_som_params?
> >
> > Yours,
> > Linus Walleij
> >
>
> How about board_params, since we're already calling those things boards
> elsewhere in the driver? That could refer to the board of a standalone
> module, or an integrated board, which should cover all cases.

Fair enough, go for board_params!

Yours,
Linus Walleij

2022-01-03 11:15:07

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties

On Mon, Jan 3, 2022 at 7:03 AM Hector Martin <[email protected]> wrote:
> On 2022/01/02 14:58, Linus Walleij wrote:
> > On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <[email protected]> wrote:
> >
> >> On DT platforms, the module-instance and antenna-sku-info properties
> >> are passed in the DT. On ACPI platforms, module-instance is passed via
> >> the analogous Apple device property mechanism, while the antenna SKU
> >> info is instead obtained via an ACPI method that grabs it from
> >> non-volatile storage.
> >>
> >> Add support for this, to allow proper firmware selection on Apple
> >> platforms.
> >>
> >> Signed-off-by: Hector Martin <[email protected]>
> >
> > If the strings treated here are exactly the same as for the device tree,
> > you should be able to just use "devprops" (firmware node) to handle it
> > abstractly, and then the respective DT and ACPI backend will provide
> > the properties.
> >
> > I don't know if this patch I made recently is enough of an examples:
> > https://lore.kernel.org/linux-hwmon/[email protected]/
> >
> > If the ACPI and DT differs a lot in format and strings etc it may not
> > be worth it.
>
> It's not quite the same; module-instance is the same from macOS'
> perspective, but we don't use Apple's device tree directly but rather
> roll our own DT which uses a different property name in this case.
> antenna-sku-info uses an ACPI method on x86, so that one is completely
> different. So in the end nothing is actually shared.

OK then!
Acked-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-01-03 17:23:07

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties

On 2022/01/04 1:20, Andy Shevchenko wrote:
> +void brcmf_acpi_probe(struct device *dev, enum brcmf_bus_type bus_type,
> +                     struct brcmf_mp_device *settings)
> +{
> +       acpi_status status;
> +       struct acpi_device *adev = ACPI_COMPANION(dev);
>
>
> Please, move the assignment closer to its first user 

So... two lines down? :-)

>   
>
> +       const union acpi_object *o;
> +       struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL};
> +
> +       if (!adev)
> +               return;
> +
> +       if (!ACPI_FAILURE(acpi_dev_get_property(adev, "module-instance",
> +                                               ACPI_TYPE_STRING,
> &o))) {
> +               const char *prefix = "apple,";
> +               int len = strlen(prefix) + o->string.length + 1;
> +               char *board_type = devm_kzalloc(dev, len, GFP_KERNEL);
> +
> +               strscpy(board_type, prefix, len);
> +               strlcat(board_type, o->string.pointer, 
>
>
> NIH devm_kasprintf()?

That sounds useful, didn't know that existed. Thanks!

>  
>
> +               brcmf_dbg(INFO, "ACPI module-instance=%s\n",
> o->string.pointer);
> +               settings->board_type = board_type;
> +       } else {
> +               brcmf_dbg(INFO, "No ACPI module-instance\n");
> +       }
> +
> +       status = acpi_evaluate_object(adev->handle, "RWCV", NULL, &buf);
> +       o = buf.pointer;
> +       if (!ACPI_FAILURE(status) && o && o->type == ACPI_TYPE_BUFFER &&
> +           o->buffer.length >= 2) {
> +               char *antenna_sku = devm_kzalloc(dev, 3, GFP_KERNEL);
> +
> +               memcpy(antenna_sku, o->buffer.pointer, 2);
>
>
> NIH devm_kmemdup()?

Not *quite*. I take the first two bytes of the returned buffer and turn
them into a null-terminated 3-byte string. kmemdup wouldn't
null-terminate or would copy too much, depending on length.

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-04 05:23:13

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties

On 2022/01/04 7:50, Andy Shevchenko wrote:
> >     +       status = acpi_evaluate_object(adev->handle, "RWCV",
> NULL, &buf);
> >     +       o = buf.pointer;
> >     +       if (!ACPI_FAILURE(status) && o && o->type ==
> ACPI_TYPE_BUFFER &&
> >     +           o->buffer.length >= 2) {
> >     +               char *antenna_sku = devm_kzalloc(dev, 3,
> GFP_KERNEL);
> >     +
> >     +               memcpy(antenna_sku, o->buffer.pointer, 2);
> >
> >
> > NIH devm_kmemdup()?
>
> Not *quite*. I take the first two bytes of the returned buffer and turn
> them into a null-terminated 3-byte string. kmemdup wouldn't
> null-terminate or would copy too much, depending on length.
>
>
>
> devm_kstrndup() then?
>
>  

That doesn't seem to be a thing.


--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-04 05:47:39

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

On 2021/12/30 1:42, Mark Kettenis wrote:
>> From: Hector Martin <[email protected]>
>> Cc: Hector Martin <[email protected]>, Sven Peter <[email protected]>,
>> Alyssa Rosenzweig <[email protected]>,
>> Mark Kettenis <[email protected]>,
>> Rafał Miłecki <[email protected]>,
>> Pieter-Paul Giesberts <[email protected]>,
>> Linus Walleij <[email protected]>,
>> Hans de Goede <[email protected]>,
>> "John W. Linville" <[email protected]>,
>> "Daniel (Deognyoun) Kim" <[email protected]>,
>> "brian m. carlson" <[email protected]>,
>> [email protected], [email protected],
>> [email protected], [email protected],
>> [email protected], [email protected],
>> [email protected]
>> Date: Mon, 27 Dec 2021 00:35:51 +0900
>>
>> 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.
>>
>> Signed-off-by: Hector Martin <[email protected]>
>> ---
>> .../net/wireless/brcm,bcm4329-fmac.yaml | 32 +++++++++++++++++--
>> 1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
>> index c11f23b20c4c..2530ff3e7b90 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
>> @@ -4,7 +4,7 @@
>> $id: http://devicetree.org/schemas/net/wireless/brcm,bcm4329-fmac.yaml#
>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>
>> -title: Broadcom BCM4329 family fullmac wireless SDIO devices
>> +title: Broadcom BCM4329 family fullmac wireless SDIO/PCIE devices
>>
>> maintainers:
>> - Arend van Spriel <[email protected]>
>> @@ -36,16 +36,22 @@ properties:
>> - brcm,bcm43455-fmac
>> - brcm,bcm43456-fmac
>> - brcm,bcm4354-fmac
>> + - brcm,bcm4355c1-fmac
>> - brcm,bcm4356-fmac
>> - brcm,bcm4359-fmac
>> + - brcm,bcm4364b2-fmac
>> + - brcm,bcm4364b3-fmac
>> + - brcm,bcm4377b3-fmac
>> + - brcm,bcm4378b1-fmac
>> + - brcm,bcm4387c2-fmac
>> - cypress,cyw4373-fmac
>> - cypress,cyw43012-fmac
>> - const: brcm,bcm4329-fmac
>> - const: brcm,bcm4329-fmac
>
> I suppose this helps with validation of device trees. However, nodes
> for PCI devices are not supposed to have a "compatible" property as
> the PCI vendor and device IDs are supposed to be used to identify a
> device.
>
> That does raise the question how a schema for additional properties
> for PCI device nodes is supposed to be defined...

Apparently using a "pciVVVV,DDDD" compatible is one way, see
bindings/net/wireless/qca,ath9k.yaml

There's apparently exactly one example of this in in-tree devicetrees:
boot/dts/rockchip/rk3399-gru-chromebook.dtsi

I guess this is the way to go then, unless Rob has a different idea :)

--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub

2022-01-10 09:59:58

by Kalle Valo

[permalink] [raw]
Subject: Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties

Andy Shevchenko <[email protected]> writes:

> On Sunday, December 26, 2021, Hector Martin <[email protected]> wrote:
>
> On DT platforms, the module-instance and antenna-sku-info properties
> are passed in the DT. On ACPI platforms, module-instance is passed via
> the analogous Apple device property mechanism, while the antenna SKU
> info is instead obtained via an ACPI method that grabs it from
> non-volatile storage.
>
> Add support for this, to allow proper firmware selection on Apple
> platforms.
>
> Signed-off-by: Hector Martin <[email protected]>
> ---
> .../broadcom/brcm80211/brcmfmac/Makefile | 2 +
> .../broadcom/brcm80211/brcmfmac/acpi.c | 51 +++++++++++++++++++
> .../broadcom/brcm80211/brcmfmac/common.c | 1 +
> .../broadcom/brcm80211/brcmfmac/common.h | 9 ++++
> 4 files changed, 63 insertions(+)
> create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
> index 13c13504a6e8..19009eb9db93 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
> @@ -47,3 +47,5 @@ brcmfmac-$(CONFIG_OF) += \
> of.o
> brcmfmac-$(CONFIG_DMI) += \
> dmi.o
> +brcmfmac-$(CONFIG_ACPI) += \
> + acpi.o
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
> new file mode 100644
> index 000000000000..3e56dc7a8db2
> --- /dev/null
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
> @@ -0,0 +1,51 @@
> +// SPDX-License-Identifier: ISC
> +/*
> + * Copyright The Asahi Linux Contributors
> + */
> +
> +#include <linux/acpi.h>
> +#include "debug.h"
> +#include "core.h"
> +#include "common.h"
> +
> +void brcmf_acpi_probe(struct device *dev, enum brcmf_bus_type bus_type,
> + struct brcmf_mp_device *settings)
> +{
> + acpi_status status;
> + struct acpi_device *adev = ACPI_COMPANION(dev);
>
> Please, move the assignment closer to its first user

Andy, your email was formatted in HTML. I'm sure you know this already,
but our mailing lists drop all HTML emails so other people (and
patchwork) don't see your comments.

--
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches