linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms
@ 2021-12-26 15:35 Hector Martin
  2021-12-26 15:35 ` [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
                   ` (35 more replies)
  0 siblings, 36 replies; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:35 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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


^ permalink raw reply	[flat|nested] 105+ messages in thread

* [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
@ 2021-12-26 15:35 ` Hector Martin
  2021-12-26 21:02   ` Linus Walleij
                     ` (3 more replies)
  2021-12-26 15:35 ` [PATCH 02/34] brcmfmac: pcie: Declare missing firmware files in pcie.c Hector Martin
                   ` (34 subsequent siblings)
  35 siblings, 4 replies; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:35 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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 <arend@broadcom.com>
@@ -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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 02/34] brcmfmac: pcie: Declare missing firmware files in pcie.c
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
  2021-12-26 15:35 ` [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
@ 2021-12-26 15:35 ` Hector Martin
  2021-12-26 21:04   ` Linus Walleij
  2021-12-26 15:35 ` [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths Hector Martin
                   ` (33 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:35 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
  2021-12-26 15:35 ` [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
  2021-12-26 15:35 ` [PATCH 02/34] brcmfmac: pcie: Declare missing firmware files in pcie.c Hector Martin
@ 2021-12-26 15:35 ` Hector Martin
  2022-01-02  5:31   ` Linus Walleij
                     ` (4 more replies)
  2021-12-26 15:35 ` [PATCH 04/34] brcmfmac: firmware: Handle per-board clm_blob files Hector Martin
                   ` (32 subsequent siblings)
  35 siblings, 5 replies; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:35 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 04/34] brcmfmac: firmware: Handle per-board clm_blob files
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (2 preceding siblings ...)
  2021-12-26 15:35 ` [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths Hector Martin
@ 2021-12-26 15:35 ` Hector Martin
  2022-01-02  6:21   ` Linus Walleij
  2021-12-26 15:35 ` [PATCH 05/34] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism Hector Martin
                   ` (31 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:35 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 05/34] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (3 preceding siblings ...)
  2021-12-26 15:35 ` [PATCH 04/34] brcmfmac: firmware: Handle per-board clm_blob files Hector Martin
@ 2021-12-26 15:35 ` Hector Martin
  2022-01-02  6:22   ` Linus Walleij
  2021-12-26 15:35 ` [PATCH 06/34] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
                   ` (30 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:35 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 06/34] brcmfmac: firmware: Support passing in multiple board_types
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (4 preceding siblings ...)
  2021-12-26 15:35 ` [PATCH 05/34] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism Hector Martin
@ 2021-12-26 15:35 ` Hector Martin
  2022-01-02  5:34   ` Linus Walleij
  2021-12-26 15:35 ` [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information Hector Martin
                   ` (29 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:35 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (5 preceding siblings ...)
  2021-12-26 15:35 ` [PATCH 06/34] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
@ 2021-12-26 15:35 ` Hector Martin
  2022-01-02  5:38   ` Linus Walleij
  2021-12-26 15:35 ` [PATCH 08/34] brcmfmac: of: Fetch Apple properties Hector Martin
                   ` (28 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:35 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 08/34] brcmfmac: of: Fetch Apple properties
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (6 preceding siblings ...)
  2021-12-26 15:35 ` [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information Hector Martin
@ 2021-12-26 15:35 ` Hector Martin
  2022-01-02  5:40   ` Linus Walleij
  2021-12-26 15:35 ` [PATCH 09/34] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
                   ` (27 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:35 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 09/34] brcmfmac: pcie: Perform firmware selection for Apple platforms
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (7 preceding siblings ...)
  2021-12-26 15:35 ` [PATCH 08/34] brcmfmac: of: Fetch Apple properties Hector Martin
@ 2021-12-26 15:35 ` Hector Martin
  2022-01-02  5:44   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
                   ` (26 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:35 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (8 preceding siblings ...)
  2021-12-26 15:35 ` [PATCH 09/34] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  5:50   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 11/34] brcmfmac: msgbuf: Increase RX ring sizes to 1024 Hector Martin
                   ` (25 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 11/34] brcmfmac: msgbuf: Increase RX ring sizes to 1024
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (9 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  5:50   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 12/34] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
                   ` (24 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 12/34] brcmfmac: pcie: Fix crashes due to early IRQs
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (10 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 11/34] brcmfmac: msgbuf: Increase RX ring sizes to 1024 Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  5:51   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 13/34] brcmfmac: pcie: Support PCIe core revisions >= 64 Hector Martin
                   ` (23 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 13/34] brcmfmac: pcie: Support PCIe core revisions >= 64
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (11 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 12/34] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  5:53   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 14/34] brcmfmac: pcie: Add IDs/properties for BCM4378 Hector Martin
                   ` (22 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 14/34] brcmfmac: pcie: Add IDs/properties for BCM4378
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (12 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 13/34] brcmfmac: pcie: Support PCIe core revisions >= 64 Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  5:53   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props Hector Martin
                   ` (21 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (13 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 14/34] brcmfmac: pcie: Add IDs/properties for BCM4378 Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2021-12-26 18:20   ` Lukas Wunner
  2022-01-02  6:20   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
                   ` (20 subsequent siblings)
  35 siblings, 2 replies; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (14 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  5:58   ` Linus Walleij
       [not found]   ` <CAHp75VcZcJ+zCDL-J+w8gEeKXGYdJajjLoa1JTj_kkJixrV12Q@mail.gmail.com>
  2021-12-26 15:36 ` [PATCH 17/34] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
                   ` (19 subsequent siblings)
  35 siblings, 2 replies; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 17/34] brcmfmac: pcie: Provide a buffer of random bytes to the device
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (15 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  5:59   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 18/34] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
                   ` (18 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 18/34] brcmfmac: pcie: Add IDs/properties for BCM4355
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (16 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 17/34] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:00   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 19/34] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
                   ` (17 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 19/34] brcmfmac: pcie: Add IDs/properties for BCM4377
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (17 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 18/34] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:01   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 20/34] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin
                   ` (16 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 20/34] brcmfmac: pcie: Perform correct BCM4364 firmware selection
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (18 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 19/34] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:02   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 21/34] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number Hector Martin
                   ` (15 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 21/34] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (19 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 20/34] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:03   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 22/34] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks Hector Martin
                   ` (14 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 22/34] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (20 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 21/34] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:09   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 23/34] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
                   ` (13 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 23/34] brcmfmac: cfg80211: Add support for scan params v2
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (21 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 22/34] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:23   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 24/34] brcmfmac: feature: Add support for setting feats based on WLC version Hector Martin
                   ` (12 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 24/34] brcmfmac: feature: Add support for setting feats based on WLC version
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (22 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 23/34] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:11   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 25/34] brcmfmac: cfg80211: Add support for PMKID_V3 operations Hector Martin
                   ` (11 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 25/34] brcmfmac: cfg80211: Add support for PMKID_V3 operations
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (23 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 24/34] brcmfmac: feature: Add support for setting feats based on WLC version Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:12   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 26/34] brcmfmac: cfg80211: Pass the PMK in binary instead of hex Hector Martin
                   ` (10 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 26/34] brcmfmac: cfg80211: Pass the PMK in binary instead of hex
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (24 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 25/34] brcmfmac: cfg80211: Add support for PMKID_V3 operations Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:13   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 27/34] brcmfmac: pcie: Add IDs/properties for BCM4387 Hector Martin
                   ` (9 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 27/34] brcmfmac: pcie: Add IDs/properties for BCM4387
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (25 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 26/34] brcmfmac: cfg80211: Pass the PMK in binary instead of hex Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:13   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 28/34] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio Hector Martin
                   ` (8 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 28/34] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (26 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 27/34] brcmfmac: pcie: Add IDs/properties for BCM4387 Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:15   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 29/34] brcmfmac: pcie: Read the console on init and shutdown Hector Martin
                   ` (7 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 29/34] brcmfmac: pcie: Read the console on init and shutdown
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (27 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 28/34] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:16   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 30/34] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path Hector Martin
                   ` (6 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 30/34] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (28 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 29/34] brcmfmac: pcie: Read the console on init and shutdown Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:16   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 31/34] brcmfmac: fwil: Constify iovar name arguments Hector Martin
                   ` (5 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 31/34] brcmfmac: fwil: Constify iovar name arguments
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (29 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 30/34] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:17   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 32/34] brcmfmac: common: Add support for downloading TxCap blobs Hector Martin
                   ` (4 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 32/34] brcmfmac: common: Add support for downloading TxCap blobs
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (30 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 31/34] brcmfmac: fwil: Constify iovar name arguments Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:18   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 33/34] brcmfmac: pcie: Load and provide " Hector Martin
                   ` (3 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 33/34] brcmfmac: pcie: Load and provide TxCap blobs
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (31 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 32/34] brcmfmac: common: Add support for downloading TxCap blobs Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:19   ` Linus Walleij
  2021-12-26 15:36 ` [PATCH 34/34] brcmfmac: common: Add support for external calibration blobs Hector Martin
                   ` (2 subsequent siblings)
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* [PATCH 34/34] brcmfmac: common: Add support for external calibration blobs
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (32 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 33/34] brcmfmac: pcie: Load and provide " Hector Martin
@ 2021-12-26 15:36 ` Hector Martin
  2022-01-02  6:19   ` Linus Walleij
  2021-12-26 19:17 ` [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Lukas Wunner
  2022-01-02  6:25 ` Linus Walleij
  35 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-26 15:36 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
---
 .../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


^ permalink raw reply related	[flat|nested] 105+ messages in thread

* Re: [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props
  2021-12-26 15:36 ` [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props Hector Martin
@ 2021-12-26 18:20   ` Lukas Wunner
  2022-01-02  6:20   ` Linus Walleij
  1 sibling, 0 replies; 105+ messages in thread
From: Lukas Wunner @ 2021-12-26 18:20 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis, Rafa?? Mi??ecki,
	Pieter-Paul Giesberts, Linus Walleij, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

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 <marcan@marcan.st>

Reviewed-by: Lukas Wunner <lukas@wunner.de>

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (33 preceding siblings ...)
  2021-12-26 15:36 ` [PATCH 34/34] brcmfmac: common: Add support for external calibration blobs Hector Martin
@ 2021-12-26 19:17 ` Lukas Wunner
  2021-12-26 21:42   ` Hans de Goede
  2022-01-02  6:25 ` Linus Walleij
  35 siblings, 1 reply; 105+ messages in thread
From: Lukas Wunner @ 2021-12-26 19:17 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis, Rafa?? Mi??ecki,
	Pieter-Paul Giesberts, Linus Walleij, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2021-12-26 15:35 ` [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
@ 2021-12-26 21:02   ` Linus Walleij
  2021-12-26 23:34   ` Rob Herring
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2021-12-26 21:02 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, Stephan Gerhold

On Sun, Dec 26, 2021 at 4:36 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Makes sense to me!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

> +  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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 02/34] brcmfmac: pcie: Declare missing firmware files in pcie.c
  2021-12-26 15:35 ` [PATCH 02/34] brcmfmac: pcie: Declare missing firmware files in pcie.c Hector Martin
@ 2021-12-26 21:04   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2021-12-26 21:04 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:36 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>
> Fixes: 75729e110e68 ("brcmfmac: expose firmware config files through modinfo")

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms
  2021-12-26 19:17 ` [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Lukas Wunner
@ 2021-12-26 21:42   ` Hans de Goede
  2021-12-27 11:53     ` Hector Martin
  0 siblings, 1 reply; 105+ messages in thread
From: Hans de Goede @ 2021-12-26 21:42 UTC (permalink / raw)
  To: Lukas Wunner, Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis, Rafa?? Mi??ecki,
	Pieter-Paul Giesberts, Linus Walleij, John W. Linville,
	Daniel (Deognyoun) Kim, brian m. carlson, linux-wireless, netdev,
	devicetree, linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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


^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2021-12-26 15:35 ` [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
  2021-12-26 21:02   ` Linus Walleij
@ 2021-12-26 23:34   ` Rob Herring
  2021-12-27 16:36   ` Rob Herring
  2021-12-29 16:42   ` Mark Kettenis
  3 siblings, 0 replies; 105+ messages in thread
From: Rob Herring @ 2021-12-26 23:34 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, brian m. carlson, Chung-hsien Hsu,
	Daniel (Deognyoun) Kim, Linus Walleij, Alyssa Rosenzweig,
	Wright Feng, brcm80211-dev-list.pdl, Rafał Miłecki,
	Hante Meuleman, Sven Peter, Rob Herring, devicetree, Len Brown,
	John W. Linville, linux-acpi, Jakub Kicinski, Arend van Spriel,
	netdev, linux-kernel, Chi-hsien Lin, Mark Kettenis, Franky Lin,
	linux-wireless, SHA-cyfmac-dev-list, Hans de Goede,
	Rafael J. Wysocki, David S. Miller, Pieter-Paul Giesberts

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 <marcan@marcan.st>
> ---
>  .../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.


^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms
  2021-12-26 21:42   ` Hans de Goede
@ 2021-12-27 11:53     ` Hector Martin
  0 siblings, 0 replies; 105+ messages in thread
From: Hector Martin @ 2021-12-27 11:53 UTC (permalink / raw)
  To: Hans de Goede, Lukas Wunner
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Sven Peter,
	Alyssa Rosenzweig, Mark Kettenis, Rafa?? Mi??ecki,
	Pieter-Paul Giesberts, Linus Walleij, John W. Linville,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2021-12-26 15:35 ` [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
  2021-12-26 21:02   ` Linus Walleij
  2021-12-26 23:34   ` Rob Herring
@ 2021-12-27 16:36   ` Rob Herring
  2021-12-27 17:23     ` Hector Martin
  2021-12-29 16:42   ` Mark Kettenis
  3 siblings, 1 reply; 105+ messages in thread
From: Rob Herring @ 2021-12-27 16:36 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rafael J. Wysocki,
	Len Brown, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-hsien Lin, Wright Feng, Chung-hsien Hsu, Sven Peter,
	Alyssa Rosenzweig, Mark Kettenis, Rafał Miłecki,
	Pieter-Paul Giesberts, Linus Walleij, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

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 <marcan@marcan.st>
> ---
>  .../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 <arend@broadcom.com>
> @@ -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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2021-12-27 16:36   ` Rob Herring
@ 2021-12-27 17:23     ` Hector Martin
  2021-12-29 16:38       ` Mark Kettenis
  0 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2021-12-27 17:23 UTC (permalink / raw)
  To: Rob Herring
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rafael J. Wysocki,
	Len Brown, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-hsien Lin, Wright Feng, Sven Peter, Alyssa Rosenzweig,
	Mark Kettenis, Rafał Miłecki, Pieter-Paul Giesberts,
	Linus Walleij, Hans de Goede, John W. Linville, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2021-12-27 17:23     ` Hector Martin
@ 2021-12-29 16:38       ` Mark Kettenis
  2022-01-02 14:12         ` Hector Martin
  0 siblings, 1 reply; 105+ messages in thread
From: Mark Kettenis @ 2021-12-29 16:38 UTC (permalink / raw)
  To: Hector Martin
  Cc: robh, kvalo, davem, kuba, rafael, lenb, aspriel, franky.lin,
	hante.meuleman, chi-hsien.lin, wright.feng, sven, alyssa,
	kettenis, zajec5, pieter-paul.giesberts, linus.walleij, hdegoede,
	linville, sandals, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

> From: Hector Martin <marcan@marcan.st>
> 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.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2021-12-26 15:35 ` [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
                     ` (2 preceding siblings ...)
  2021-12-27 16:36   ` Rob Herring
@ 2021-12-29 16:42   ` Mark Kettenis
  2022-01-04  5:47     ` Hector Martin
  3 siblings, 1 reply; 105+ messages in thread
From: Mark Kettenis @ 2021-12-29 16:42 UTC (permalink / raw)
  To: Hector Martin
  Cc: kvalo, davem, kuba, robh+dt, rafael, lenb, aspriel, franky.lin,
	hante.meuleman, chi-hsien.lin, wright.feng, chung-hsien.hsu,
	marcan, sven, alyssa, kettenis, zajec5, pieter-paul.giesberts,
	linus.walleij, hdegoede, linville, dekim, sandals,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

> From: Hector Martin <marcan@marcan.st>
> Cc: Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>,
>         Alyssa Rosenzweig <alyssa@rosenzweig.io>,
>         Mark Kettenis <kettenis@openbsd.org>,
>         Rafał Miłecki <zajec5@gmail.com>,
>         Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>,
>         Linus Walleij <linus.walleij@linaro.org>,
>         Hans de Goede <hdegoede@redhat.com>,
>         "John W. Linville" <linville@tuxdriver.com>,
>         "Daniel (Deognyoun) Kim" <dekim@broadcom.com>,
>         "brian m. carlson" <sandals@crustytoothpaste.net>,
>         linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
>         devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
>         linux-acpi@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com,
>         SHA-cyfmac-dev-list@infineon.com
> 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 <marcan@marcan.st>
> ---
>  .../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 <arend@broadcom.com>
> @@ -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
> 
> 

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2021-12-26 15:35 ` [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths Hector Martin
@ 2022-01-02  5:31   ` Linus Walleij
  2022-01-02  7:10     ` Dmitry Osipenko
  2022-01-02  6:38   ` Dmitry Osipenko
                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:31 UTC (permalink / raw)
  To: Hector Martin, Dmitry Osipenko
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

This looks OK to me so FWIW:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 06/34] brcmfmac: firmware: Support passing in multiple board_types
  2021-12-26 15:35 ` [PATCH 06/34] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
@ 2022-01-02  5:34   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:34 UTC (permalink / raw)
  To: Hector Martin, Dmitry Osipenko
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information
  2021-12-26 15:35 ` [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information Hector Martin
@ 2022-01-02  5:38   ` Linus Walleij
  2022-01-03  5:51     ` Hector Martin
  0 siblings, 1 reply; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:38 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 08/34] brcmfmac: of: Fetch Apple properties
  2021-12-26 15:35 ` [PATCH 08/34] brcmfmac: of: Fetch Apple properties Hector Martin
@ 2022-01-02  5:40   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:40 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 09/34] brcmfmac: pcie: Perform firmware selection for Apple platforms
  2021-12-26 15:35 ` [PATCH 09/34] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
@ 2022-01-02  5:44   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:44 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

It's a neat hack, and I don't see anyone doing anything smarter so:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr
  2021-12-26 15:36 ` [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
@ 2022-01-02  5:50   ` Linus Walleij
  2022-01-03  5:42     ` Hector Martin
  0 siblings, 1 reply; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:50 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

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 <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 11/34] brcmfmac: msgbuf: Increase RX ring sizes to 1024
  2021-12-26 15:36 ` [PATCH 11/34] brcmfmac: msgbuf: Increase RX ring sizes to 1024 Hector Martin
@ 2022-01-02  5:50   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:50 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 12/34] brcmfmac: pcie: Fix crashes due to early IRQs
  2021-12-26 15:36 ` [PATCH 12/34] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
@ 2022-01-02  5:51   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:51 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 13/34] brcmfmac: pcie: Support PCIe core revisions >= 64
  2021-12-26 15:36 ` [PATCH 13/34] brcmfmac: pcie: Support PCIe core revisions >= 64 Hector Martin
@ 2022-01-02  5:53   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:53 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 14/34] brcmfmac: pcie: Add IDs/properties for BCM4378
  2021-12-26 15:36 ` [PATCH 14/34] brcmfmac: pcie: Add IDs/properties for BCM4378 Hector Martin
@ 2022-01-02  5:53   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:53 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties
  2021-12-26 15:36 ` [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
@ 2022-01-02  5:58   ` Linus Walleij
  2022-01-03  6:03     ` Hector Martin
       [not found]   ` <CAHp75VcZcJ+zCDL-J+w8gEeKXGYdJajjLoa1JTj_kkJixrV12Q@mail.gmail.com>
  1 sibling, 1 reply; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:58 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

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/20211206020423.62402-2-linus.walleij@linaro.org/

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

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 17/34] brcmfmac: pcie: Provide a buffer of random bytes to the device
  2021-12-26 15:36 ` [PATCH 17/34] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
@ 2022-01-02  5:59   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  5:59 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 18/34] brcmfmac: pcie: Add IDs/properties for BCM4355
  2021-12-26 15:36 ` [PATCH 18/34] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
@ 2022-01-02  6:00   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:00 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 19/34] brcmfmac: pcie: Add IDs/properties for BCM4377
  2021-12-26 15:36 ` [PATCH 19/34] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
@ 2022-01-02  6:01   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:01 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 20/34] brcmfmac: pcie: Perform correct BCM4364 firmware selection
  2021-12-26 15:36 ` [PATCH 20/34] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin
@ 2022-01-02  6:02   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:02 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 21/34] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number
  2021-12-26 15:36 ` [PATCH 21/34] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number Hector Martin
@ 2022-01-02  6:03   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:03 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 22/34] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks
  2021-12-26 15:36 ` [PATCH 22/34] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks Hector Martin
@ 2022-01-02  6:09   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:09 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 24/34] brcmfmac: feature: Add support for setting feats based on WLC version
  2021-12-26 15:36 ` [PATCH 24/34] brcmfmac: feature: Add support for setting feats based on WLC version Hector Martin
@ 2022-01-02  6:11   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:11 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 25/34] brcmfmac: cfg80211: Add support for PMKID_V3 operations
  2021-12-26 15:36 ` [PATCH 25/34] brcmfmac: cfg80211: Add support for PMKID_V3 operations Hector Martin
@ 2022-01-02  6:12   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:12 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 26/34] brcmfmac: cfg80211: Pass the PMK in binary instead of hex
  2021-12-26 15:36 ` [PATCH 26/34] brcmfmac: cfg80211: Pass the PMK in binary instead of hex Hector Martin
@ 2022-01-02  6:13   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:13 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 27/34] brcmfmac: pcie: Add IDs/properties for BCM4387
  2021-12-26 15:36 ` [PATCH 27/34] brcmfmac: pcie: Add IDs/properties for BCM4387 Hector Martin
@ 2022-01-02  6:13   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:13 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 28/34] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio
  2021-12-26 15:36 ` [PATCH 28/34] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio Hector Martin
@ 2022-01-02  6:15   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:15 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Excellent patch.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 29/34] brcmfmac: pcie: Read the console on init and shutdown
  2021-12-26 15:36 ` [PATCH 29/34] brcmfmac: pcie: Read the console on init and shutdown Hector Martin
@ 2022-01-02  6:16   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:16 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 30/34] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path
  2021-12-26 15:36 ` [PATCH 30/34] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path Hector Martin
@ 2022-01-02  6:16   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:16 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 31/34] brcmfmac: fwil: Constify iovar name arguments
  2021-12-26 15:36 ` [PATCH 31/34] brcmfmac: fwil: Constify iovar name arguments Hector Martin
@ 2022-01-02  6:17   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:17 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <marcan@marcan.st> wrote:

> Make all the iovar name arguments const char * instead of just char *.
>
> Signed-off-by: Hector Martin <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 32/34] brcmfmac: common: Add support for downloading TxCap blobs
  2021-12-26 15:36 ` [PATCH 32/34] brcmfmac: common: Add support for downloading TxCap blobs Hector Martin
@ 2022-01-02  6:18   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:18 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:40 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 33/34] brcmfmac: pcie: Load and provide TxCap blobs
  2021-12-26 15:36 ` [PATCH 33/34] brcmfmac: pcie: Load and provide " Hector Martin
@ 2022-01-02  6:19   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:19 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:41 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 34/34] brcmfmac: common: Add support for external calibration blobs
  2021-12-26 15:36 ` [PATCH 34/34] brcmfmac: common: Add support for external calibration blobs Hector Martin
@ 2022-01-02  6:19   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:19 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:41 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props
  2021-12-26 15:36 ` [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props Hector Martin
  2021-12-26 18:20   ` Lukas Wunner
@ 2022-01-02  6:20   ` Linus Walleij
  1 sibling, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:20 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 04/34] brcmfmac: firmware: Handle per-board clm_blob files
  2021-12-26 15:35 ` [PATCH 04/34] brcmfmac: firmware: Handle per-board clm_blob files Hector Martin
@ 2022-01-02  6:21   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:21 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 05/34] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism
  2021-12-26 15:35 ` [PATCH 05/34] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism Hector Martin
@ 2022-01-02  6:22   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:22 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 23/34] brcmfmac: cfg80211: Add support for scan params v2
  2021-12-26 15:36 ` [PATCH 23/34] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
@ 2022-01-02  6:23   ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:23 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:39 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms
  2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (34 preceding siblings ...)
  2021-12-26 19:17 ` [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Lukas Wunner
@ 2022-01-02  6:25 ` Linus Walleij
  2022-01-03  6:27   ` Hector Martin
  35 siblings, 1 reply; 105+ messages in thread
From: Linus Walleij @ 2022-01-02  6:25 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Sun, Dec 26, 2021 at 4:36 PM Hector Martin <marcan@marcan.st> 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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2021-12-26 15:35 ` [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths Hector Martin
  2022-01-02  5:31   ` Linus Walleij
@ 2022-01-02  6:38   ` Dmitry Osipenko
  2022-01-02  6:45   ` Dmitry Osipenko
                     ` (2 subsequent siblings)
  4 siblings, 0 replies; 105+ messages in thread
From: Dmitry Osipenko @ 2022-01-02  6:38 UTC (permalink / raw)
  To: Hector Martin, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng,
	Chung-hsien Hsu
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 <marcan@marcan.st>
> ---
>  .../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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2021-12-26 15:35 ` [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths Hector Martin
  2022-01-02  5:31   ` Linus Walleij
  2022-01-02  6:38   ` Dmitry Osipenko
@ 2022-01-02  6:45   ` Dmitry Osipenko
  2022-01-02 14:18     ` Hector Martin
  2022-01-02  6:55   ` Dmitry Osipenko
  2022-01-02  7:08   ` Dmitry Osipenko
  4 siblings, 1 reply; 105+ messages in thread
From: Dmitry Osipenko @ 2022-01-02  6:45 UTC (permalink / raw)
  To: Hector Martin, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng,
	Chung-hsien Hsu
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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?

> +}


^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2021-12-26 15:35 ` [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths Hector Martin
                     ` (2 preceding siblings ...)
  2022-01-02  6:45   ` Dmitry Osipenko
@ 2022-01-02  6:55   ` Dmitry Osipenko
  2022-01-03  6:18     ` Hector Martin
  2022-01-02  7:08   ` Dmitry Osipenko
  4 siblings, 1 reply; 105+ messages in thread
From: Dmitry Osipenko @ 2022-01-02  6:55 UTC (permalink / raw)
  To: Hector Martin, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng,
	Chung-hsien Hsu
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2021-12-26 15:35 ` [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths Hector Martin
                     ` (3 preceding siblings ...)
  2022-01-02  6:55   ` Dmitry Osipenko
@ 2022-01-02  7:08   ` Dmitry Osipenko
  2022-01-02  7:20     ` Dmitry Osipenko
  2022-01-02 14:25     ` Hector Martin
  4 siblings, 2 replies; 105+ messages in thread
From: Dmitry Osipenko @ 2022-01-02  7:08 UTC (permalink / raw)
  To: Hector Martin, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng,
	Chung-hsien Hsu
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2022-01-02  5:31   ` Linus Walleij
@ 2022-01-02  7:10     ` Dmitry Osipenko
  0 siblings, 0 replies; 105+ messages in thread
From: Dmitry Osipenko @ 2022-01-02  7:10 UTC (permalink / raw)
  To: Linus Walleij, Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

02.01.2022 08:31, Linus Walleij пишет:
> On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>
> 
> This looks OK to me so FWIW:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 
> 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.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2022-01-02  7:08   ` Dmitry Osipenko
@ 2022-01-02  7:20     ` Dmitry Osipenko
  2022-01-02 14:25     ` Hector Martin
  1 sibling, 0 replies; 105+ messages in thread
From: Dmitry Osipenko @ 2022-01-02  7:20 UTC (permalink / raw)
  To: Hector Martin, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng,
	Chung-hsien Hsu
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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.
> 


^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2021-12-29 16:38       ` Mark Kettenis
@ 2022-01-02 14:12         ` Hector Martin
  0 siblings, 0 replies; 105+ messages in thread
From: Hector Martin @ 2022-01-02 14:12 UTC (permalink / raw)
  To: Mark Kettenis
  Cc: robh, kvalo, davem, kuba, rafael, lenb, aspriel, franky.lin,
	hante.meuleman, chi-hsien.lin, wright.feng, sven, alyssa,
	kettenis, zajec5, pieter-paul.giesberts, linus.walleij, hdegoede,
	linville, sandals, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2021/12/30 1:38, Mark Kettenis wrote:
>> From: Hector Martin <marcan@marcan.st>
>> 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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2022-01-02  6:45   ` Dmitry Osipenko
@ 2022-01-02 14:18     ` Hector Martin
  2022-01-02 20:11       ` Dmitry Osipenko
  0 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2022-01-02 14:18 UTC (permalink / raw)
  To: Dmitry Osipenko, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng,
	Chung-hsien Hsu
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2022-01-02  7:08   ` Dmitry Osipenko
  2022-01-02  7:20     ` Dmitry Osipenko
@ 2022-01-02 14:25     ` Hector Martin
  2022-01-02 20:12       ` Dmitry Osipenko
  1 sibling, 1 reply; 105+ messages in thread
From: Hector Martin @ 2022-01-02 14:25 UTC (permalink / raw)
  To: Dmitry Osipenko, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2022-01-02 14:18     ` Hector Martin
@ 2022-01-02 20:11       ` Dmitry Osipenko
  2022-01-03  0:41         ` Hector Martin
  0 siblings, 1 reply; 105+ messages in thread
From: Dmitry Osipenko @ 2022-01-02 20:11 UTC (permalink / raw)
  To: Hector Martin, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng,
	Chung-hsien Hsu
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2022-01-02 14:25     ` Hector Martin
@ 2022-01-02 20:12       ` Dmitry Osipenko
  0 siblings, 0 replies; 105+ messages in thread
From: Dmitry Osipenko @ 2022-01-02 20:12 UTC (permalink / raw)
  To: Hector Martin, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

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.


^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2022-01-02 20:11       ` Dmitry Osipenko
@ 2022-01-03  0:41         ` Hector Martin
  2022-01-03  1:26           ` Dmitry Osipenko
  0 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2022-01-03  0:41 UTC (permalink / raw)
  To: Dmitry Osipenko, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2022-01-03  0:41         ` Hector Martin
@ 2022-01-03  1:26           ` Dmitry Osipenko
  2022-01-03  6:17             ` Hector Martin
  0 siblings, 1 reply; 105+ messages in thread
From: Dmitry Osipenko @ 2022-01-03  1:26 UTC (permalink / raw)
  To: Hector Martin, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

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.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr
  2022-01-02  5:50   ` Linus Walleij
@ 2022-01-03  5:42     ` Hector Martin
  0 siblings, 0 replies; 105+ messages in thread
From: Hector Martin @ 2022-01-03  5:42 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Sven Peter,
	Alyssa Rosenzweig, Mark Kettenis, Rafał Miłecki,
	Pieter-Paul Giesberts, Hans de Goede, John W. Linville,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/02 14:50, Linus Walleij wrote:
> On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>
> 
> 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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information
  2022-01-02  5:38   ` Linus Walleij
@ 2022-01-03  5:51     ` Hector Martin
  2022-01-03 11:13       ` Linus Walleij
  0 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2022-01-03  5:51 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Sven Peter,
	Alyssa Rosenzweig, Mark Kettenis, Rafał Miłecki,
	Pieter-Paul Giesberts, Hans de Goede, John W. Linville,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/02 14:38, Linus Walleij wrote:
> On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>
> 
> 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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties
  2022-01-02  5:58   ` Linus Walleij
@ 2022-01-03  6:03     ` Hector Martin
  2022-01-03 11:14       ` Linus Walleij
  0 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2022-01-03  6:03 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On 2022/01/02 14:58, Linus Walleij wrote:
> On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>
> 
> 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/20211206020423.62402-2-linus.walleij@linaro.org/
> 
> 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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2022-01-03  1:26           ` Dmitry Osipenko
@ 2022-01-03  6:17             ` Hector Martin
  0 siblings, 0 replies; 105+ messages in thread
From: Hector Martin @ 2022-01-03  6:17 UTC (permalink / raw)
  To: Dmitry Osipenko, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths
  2022-01-02  6:55   ` Dmitry Osipenko
@ 2022-01-03  6:18     ` Hector Martin
  0 siblings, 0 replies; 105+ messages in thread
From: Hector Martin @ 2022-01-03  6:18 UTC (permalink / raw)
  To: Dmitry Osipenko, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Chi-hsien Lin, Wright Feng
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms
  2022-01-02  6:25 ` Linus Walleij
@ 2022-01-03  6:27   ` Hector Martin
  2022-01-03 10:20     ` Arend van Spriel
  0 siblings, 1 reply; 105+ messages in thread
From: Hector Martin @ 2022-01-03  6:27 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Sven Peter,
	Alyssa Rosenzweig, Mark Kettenis, Rafał Miłecki,
	Pieter-Paul Giesberts, Hans de Goede, John W. Linville,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/02 15:25, Linus Walleij wrote:
> On Sun, Dec 26, 2021 at 4:36 PM Hector Martin <marcan@marcan.st> 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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms
  2022-01-03  6:27   ` Hector Martin
@ 2022-01-03 10:20     ` Arend van Spriel
  0 siblings, 0 replies; 105+ messages in thread
From: Arend van Spriel @ 2022-01-03 10:20 UTC (permalink / raw)
  To: Hector Martin, Linus Walleij
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Sven Peter,
	Alyssa Rosenzweig, Mark Kettenis, Rafał Miłecki,
	Pieter-Paul Giesberts, Hans de Goede, John W. Linville,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

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 <marcan@marcan.st> 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



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information
  2022-01-03  5:51     ` Hector Martin
@ 2022-01-03 11:13       ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-03 11:13 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Sven Peter,
	Alyssa Rosenzweig, Mark Kettenis, Rafał Miłecki,
	Pieter-Paul Giesberts, Hans de Goede, John W. Linville,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On Mon, Jan 3, 2022 at 6:52 AM Hector Martin <marcan@marcan.st> wrote:
> On 2022/01/02 14:38, Linus Walleij wrote:
> > On Sun, Dec 26, 2021 at 4:37 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>
> >
> > 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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties
  2022-01-03  6:03     ` Hector Martin
@ 2022-01-03 11:14       ` Linus Walleij
  0 siblings, 0 replies; 105+ messages in thread
From: Linus Walleij @ 2022-01-03 11:14 UTC (permalink / raw)
  To: Hector Martin
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Hans de Goede,
	John W. Linville, Daniel (Deognyoun) Kim, brian m. carlson,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

On Mon, Jan 3, 2022 at 7:03 AM Hector Martin <marcan@marcan.st> wrote:
> On 2022/01/02 14:58, Linus Walleij wrote:
> > On Sun, Dec 26, 2021 at 4:38 PM Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>
> >
> > 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/20211206020423.62402-2-linus.walleij@linaro.org/
> >
> > 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 <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties
       [not found]   ` <CAHp75VcZcJ+zCDL-J+w8gEeKXGYdJajjLoa1JTj_kkJixrV12Q@mail.gmail.com>
@ 2022-01-03 17:22     ` Hector Martin
       [not found]       ` <CAHp75Vedgs_zTH2O120jtUuQiuseA0VN62TJiJ7kAi1f5nDQ6Q@mail.gmail.com>
  2022-01-10  9:59     ` Kalle Valo
  1 sibling, 1 reply; 105+ messages in thread
From: Hector Martin @ 2022-01-03 17:22 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Sven Peter,
	Alyssa Rosenzweig, Mark Kettenis, Rafał Miłecki,
	Pieter-Paul Giesberts, Linus Walleij, Hans de Goede,
	John W. Linville, brian m. carlson, linux-wireless, netdev,
	devicetree, linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties
       [not found]       ` <CAHp75Vedgs_zTH2O120jtUuQiuseA0VN62TJiJ7kAi1f5nDQ6Q@mail.gmail.com>
@ 2022-01-04  5:22         ` Hector Martin
  0 siblings, 0 replies; 105+ messages in thread
From: Hector Martin @ 2022-01-04  5:22 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Sven Peter,
	Alyssa Rosenzweig, Mark Kettenis, Rafał Miłecki,
	Pieter-Paul Giesberts, Linus Walleij, Hans de Goede,
	John W. Linville, brian m. carlson, linux-wireless, netdev,
	devicetree, linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2021-12-29 16:42   ` Mark Kettenis
@ 2022-01-04  5:47     ` Hector Martin
  0 siblings, 0 replies; 105+ messages in thread
From: Hector Martin @ 2022-01-04  5:47 UTC (permalink / raw)
  To: Mark Kettenis
  Cc: kvalo, davem, kuba, robh+dt, rafael, lenb, aspriel, franky.lin,
	hante.meuleman, chi-hsien.lin, wright.feng, sven, alyssa,
	kettenis, zajec5, pieter-paul.giesberts, linus.walleij, hdegoede,
	linville, sandals, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2021/12/30 1:42, Mark Kettenis wrote:
>> From: Hector Martin <marcan@marcan.st>
>> Cc: Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>,
>>         Alyssa Rosenzweig <alyssa@rosenzweig.io>,
>>         Mark Kettenis <kettenis@openbsd.org>,
>>         Rafał Miłecki <zajec5@gmail.com>,
>>         Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>,
>>         Linus Walleij <linus.walleij@linaro.org>,
>>         Hans de Goede <hdegoede@redhat.com>,
>>         "John W. Linville" <linville@tuxdriver.com>,
>>         "Daniel (Deognyoun) Kim" <dekim@broadcom.com>,
>>         "brian m. carlson" <sandals@crustytoothpaste.net>,
>>         linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
>>         devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
>>         linux-acpi@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com,
>>         SHA-cyfmac-dev-list@infineon.com
>> 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 <marcan@marcan.st>
>> ---
>>  .../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 <arend@broadcom.com>
>> @@ -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 (marcan@marcan.st)
Public Key: https://mrcn.st/pub

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties
       [not found]   ` <CAHp75VcZcJ+zCDL-J+w8gEeKXGYdJajjLoa1JTj_kkJixrV12Q@mail.gmail.com>
  2022-01-03 17:22     ` Hector Martin
@ 2022-01-10  9:59     ` Kalle Valo
  1 sibling, 0 replies; 105+ messages in thread
From: Kalle Valo @ 2022-01-10  9:59 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Hector Martin, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, Daniel (Deognyoun) Kim,
	brian m. carlson, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

Andy Shevchenko <andy.shevchenko@gmail.com> writes:

> On Sunday, December 26, 2021, Hector Martin <marcan@marcan.st> 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 <marcan@marcan.st>
>  ---
>   .../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

^ permalink raw reply	[flat|nested] 105+ messages in thread

end of thread, other threads:[~2022-01-10  9:59 UTC | newest]

Thread overview: 105+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
2021-12-26 15:35 ` [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
2021-12-26 21:02   ` Linus Walleij
2021-12-26 23:34   ` Rob Herring
2021-12-27 16:36   ` Rob Herring
2021-12-27 17:23     ` Hector Martin
2021-12-29 16:38       ` Mark Kettenis
2022-01-02 14:12         ` Hector Martin
2021-12-29 16:42   ` Mark Kettenis
2022-01-04  5:47     ` Hector Martin
2021-12-26 15:35 ` [PATCH 02/34] brcmfmac: pcie: Declare missing firmware files in pcie.c Hector Martin
2021-12-26 21:04   ` Linus Walleij
2021-12-26 15:35 ` [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths Hector Martin
2022-01-02  5:31   ` Linus Walleij
2022-01-02  7:10     ` Dmitry Osipenko
2022-01-02  6:38   ` Dmitry Osipenko
2022-01-02  6:45   ` Dmitry Osipenko
2022-01-02 14:18     ` Hector Martin
2022-01-02 20:11       ` Dmitry Osipenko
2022-01-03  0:41         ` Hector Martin
2022-01-03  1:26           ` Dmitry Osipenko
2022-01-03  6:17             ` Hector Martin
2022-01-02  6:55   ` Dmitry Osipenko
2022-01-03  6:18     ` Hector Martin
2022-01-02  7:08   ` Dmitry Osipenko
2022-01-02  7:20     ` Dmitry Osipenko
2022-01-02 14:25     ` Hector Martin
2022-01-02 20:12       ` Dmitry Osipenko
2021-12-26 15:35 ` [PATCH 04/34] brcmfmac: firmware: Handle per-board clm_blob files Hector Martin
2022-01-02  6:21   ` Linus Walleij
2021-12-26 15:35 ` [PATCH 05/34] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism Hector Martin
2022-01-02  6:22   ` Linus Walleij
2021-12-26 15:35 ` [PATCH 06/34] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
2022-01-02  5:34   ` Linus Walleij
2021-12-26 15:35 ` [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information Hector Martin
2022-01-02  5:38   ` Linus Walleij
2022-01-03  5:51     ` Hector Martin
2022-01-03 11:13       ` Linus Walleij
2021-12-26 15:35 ` [PATCH 08/34] brcmfmac: of: Fetch Apple properties Hector Martin
2022-01-02  5:40   ` Linus Walleij
2021-12-26 15:35 ` [PATCH 09/34] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
2022-01-02  5:44   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
2022-01-02  5:50   ` Linus Walleij
2022-01-03  5:42     ` Hector Martin
2021-12-26 15:36 ` [PATCH 11/34] brcmfmac: msgbuf: Increase RX ring sizes to 1024 Hector Martin
2022-01-02  5:50   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 12/34] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
2022-01-02  5:51   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 13/34] brcmfmac: pcie: Support PCIe core revisions >= 64 Hector Martin
2022-01-02  5:53   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 14/34] brcmfmac: pcie: Add IDs/properties for BCM4378 Hector Martin
2022-01-02  5:53   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props Hector Martin
2021-12-26 18:20   ` Lukas Wunner
2022-01-02  6:20   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
2022-01-02  5:58   ` Linus Walleij
2022-01-03  6:03     ` Hector Martin
2022-01-03 11:14       ` Linus Walleij
     [not found]   ` <CAHp75VcZcJ+zCDL-J+w8gEeKXGYdJajjLoa1JTj_kkJixrV12Q@mail.gmail.com>
2022-01-03 17:22     ` Hector Martin
     [not found]       ` <CAHp75Vedgs_zTH2O120jtUuQiuseA0VN62TJiJ7kAi1f5nDQ6Q@mail.gmail.com>
2022-01-04  5:22         ` Hector Martin
2022-01-10  9:59     ` Kalle Valo
2021-12-26 15:36 ` [PATCH 17/34] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
2022-01-02  5:59   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 18/34] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
2022-01-02  6:00   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 19/34] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
2022-01-02  6:01   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 20/34] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin
2022-01-02  6:02   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 21/34] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number Hector Martin
2022-01-02  6:03   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 22/34] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks Hector Martin
2022-01-02  6:09   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 23/34] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
2022-01-02  6:23   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 24/34] brcmfmac: feature: Add support for setting feats based on WLC version Hector Martin
2022-01-02  6:11   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 25/34] brcmfmac: cfg80211: Add support for PMKID_V3 operations Hector Martin
2022-01-02  6:12   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 26/34] brcmfmac: cfg80211: Pass the PMK in binary instead of hex Hector Martin
2022-01-02  6:13   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 27/34] brcmfmac: pcie: Add IDs/properties for BCM4387 Hector Martin
2022-01-02  6:13   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 28/34] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio Hector Martin
2022-01-02  6:15   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 29/34] brcmfmac: pcie: Read the console on init and shutdown Hector Martin
2022-01-02  6:16   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 30/34] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path Hector Martin
2022-01-02  6:16   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 31/34] brcmfmac: fwil: Constify iovar name arguments Hector Martin
2022-01-02  6:17   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 32/34] brcmfmac: common: Add support for downloading TxCap blobs Hector Martin
2022-01-02  6:18   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 33/34] brcmfmac: pcie: Load and provide " Hector Martin
2022-01-02  6:19   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 34/34] brcmfmac: common: Add support for external calibration blobs Hector Martin
2022-01-02  6:19   ` Linus Walleij
2021-12-26 19:17 ` [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Lukas Wunner
2021-12-26 21:42   ` Hans de Goede
2021-12-27 11:53     ` Hector Martin
2022-01-02  6:25 ` Linus Walleij
2022-01-03  6:27   ` Hector Martin
2022-01-03 10:20     ` Arend van Spriel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).