linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms
@ 2022-01-04  7:26 Hector Martin
  2022-01-04  7:26 ` [PATCH v2 01/35] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
                   ` (36 more replies)
  0 siblings, 37 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

Hi everyone,

Happy new year! This 35-patch series adds 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:

- brcm,board-type: Overrides the board-type which is used for firmware
  selection on all platforms, which normally comes from the DMI device
  name or the root node compatible. Apple have their own
  mapping/identifier here ("island" name), so we prefix it with "apple,"
  and use it as the board-type override.

- 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~32: 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.

# 33-35: 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

# Known bugs

WPA3 does not yet work on M1 platforms. This is probably more missing
firmware interfaces; I'll look into it shortly and it can go into v3 or
a separate add-on patch.

# Changes since v1

- Replaced new DT compatibles with pciXXXX,YYYY ones (this seems to be
  the way to do it)
- Replaced apple,module instance DT prop with brcm,board-type (more
  generic)
- Reduced stack usage of brcmf_pmksa_v3_op
- Changed alt_paths/board_names to be a fixed, max size instead of
  statically allocated.
- Fixed broken build halfway through the series
- Addressed other review comments (style/etc)
- Fixed typos and other minor issues

Hector Martin (35):
  dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  brcmfmac: pcie: Declare missing firmware files in pcie.c
  brcmfmac: firmware: Handle per-board clm_blob files
  brcmfmac: firmware: Support having multiple alt paths
  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: firmware: Allocate space for default boardrev in nvram
  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       |  37 +-
 drivers/acpi/x86/apple.c                      |  11 +-
 .../broadcom/brcm80211/brcmfmac/Makefile      |   2 +
 .../broadcom/brcm80211/brcmfmac/acpi.c        |  47 ++
 .../broadcom/brcm80211/brcmfmac/bus.h         |  20 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c    | 178 +++++-
 .../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    | 136 +++-
 .../broadcom/brcm80211/brcmfmac/firmware.h    |   4 +-
 .../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 |  20 +-
 .../broadcom/brcm80211/brcmfmac/pcie.c        | 599 +++++++++++++++---
 .../broadcom/brcm80211/brcmfmac/sdio.c        |  39 +-
 .../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, 1313 insertions(+), 270 deletions(-)
 create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c

-- 
2.33.0


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

* [PATCH v2 01/35] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-11 18:45   ` Rob Herring
  2022-01-04  7:26 ` [PATCH v2 02/35] brcmfmac: pcie: Declare missing firmware files in pcie.c Hector Martin
                   ` (35 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
---
 .../net/wireless/brcm,bcm4329-fmac.yaml       | 37 +++++++++++++++++--
 1 file changed, 34 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..8b4147c64355 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>
@@ -42,10 +42,16 @@ properties:
               - cypress,cyw43012-fmac
           - const: brcm,bcm4329-fmac
       - const: brcm,bcm4329-fmac
+      - enum:
+          - pci14e4,43dc  # BCM4355
+          - pci14e4,4464  # BCM4364
+          - pci14e4,4488  # BCM4377
+          - pci14e4,4425  # BCM4378
+          - pci14e4,4433  # BCM4387
 
   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,31 @@ 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.
+
+  brcm,board-type:
+    $ref: /schemas/types.yaml#/definitions/string
+    description: Overrides the board type, which is normally the compatible of
+      the root node. This can be used to decouple the overall system board or
+      device name from the board type for WiFi purposes, which is used to
+      construct firmware and NVRAM configuration filenames, allowing for
+      multiple devices that share the same module or characteristics for the
+      WiFi subsystem to share the same firmware/NVRAM files. On Apple platforms,
+      this should be the Apple module-instance codename prefixed by "apple,",
+      e.g. "apple,honshu".
+
+  apple,antenna-sku:
+    $ref: /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] 122+ messages in thread

* [PATCH v2 02/35] brcmfmac: pcie: Declare missing firmware files in pcie.c
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
  2022-01-04  7:26 ` [PATCH v2 01/35] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-06  9:56   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 03/35] brcmfmac: firmware: Handle per-board clm_blob files Hector Martin
                   ` (34 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Fixes: 75729e110e68 ("brcmfmac: expose firmware config files through modinfo")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
---
 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] 122+ messages in thread

* [PATCH v2 03/35] brcmfmac: firmware: Handle per-board clm_blob files
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
  2022-01-04  7:26 ` [PATCH v2 01/35] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
  2022-01-04  7:26 ` [PATCH v2 02/35] brcmfmac: pcie: Declare missing firmware files in pcie.c Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-06 10:19   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths Hector Martin
                   ` (33 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
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 0eb13e5df517..0497b721136a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -595,16 +595,16 @@ static int brcmf_fw_complete_request(const struct firmware *fw,
 static char *brcm_alt_fw_path(const char *path, const char *board_type)
 {
 	char alt_path[BRCMF_FW_NAME_LEN];
-	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);
@@ -619,7 +619,7 @@ static int brcmf_fw_request_firmware(const struct firmware **fw,
 	int ret;
 
 	/* 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) {
 		char *alt_path;
 
 		alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);
-- 
2.33.0


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

* [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (2 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 03/35] brcmfmac: firmware: Handle per-board clm_blob files Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04  8:26   ` Dmitry Osipenko
                     ` (2 more replies)
  2022-01-04  7:26 ` [PATCH v2 05/35] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism Hector Martin
                   ` (32 subsequent siblings)
  36 siblings, 3 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
---
 .../broadcom/brcm80211/brcmfmac/firmware.c    | 75 ++++++++++++++-----
 .../broadcom/brcm80211/brcmfmac/firmware.h    |  2 +
 2 files changed, 59 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 0497b721136a..7570dbf22cdd 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[BRCMF_FW_MAX_ALT_PATHS];
+	int alt_index;
 	u32 curpos;
 	void (*done)(struct device *dev, int err, struct brcmf_fw_request *req);
 };
@@ -592,14 +594,18 @@ 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 int brcm_alt_fw_paths(const char *path, const char *board_type,
+			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
 {
 	char alt_path[BRCMF_FW_NAME_LEN];
 	const char *suffix;
 
+	memset(alt_paths, 0, array_size(sizeof(*alt_paths),
+					BRCMF_FW_MAX_ALT_PATHS));
+
 	suffix = strrchr(path, '.');
 	if (!suffix || suffix == path)
-		return NULL;
+		return -EINVAL;
 
 	/* strip extension at the end */
 	strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
@@ -609,7 +615,18 @@ 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[0] = kstrdup(alt_path, GFP_KERNEL);
+
+	return 0;
+}
+
+static void
+brcm_free_alt_fw_paths(const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
+{
+	unsigned int i;
+
+	for (i = 0; alt_paths[i]; i++)
+		kfree(alt_paths[i]);
 }
 
 static int brcmf_fw_request_firmware(const struct firmware **fw,
@@ -617,19 +634,25 @@ static int brcmf_fw_request_firmware(const struct firmware **fw,
 {
 	struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
 	int ret;
+	unsigned int i;
 
 	/* Files can be board-specific, first try a board-specific path */
 	if (fwctx->req->board_type) {
-		char *alt_path;
+		const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS];
 
-		alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);
-		if (!alt_path)
+		if (brcm_alt_fw_paths(cur->path, fwctx->req->board_type,
+				      alt_paths) != 0)
 			goto fallback;
 
-		ret = request_firmware(fw, alt_path, fwctx->dev);
-		kfree(alt_path);
-		if (ret == 0)
-			return ret;
+		for (i = 0; i < BRCMF_FW_MAX_ALT_PATHS && 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 +664,8 @@ 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);
+
 	ret = brcmf_fw_complete_request(fw, fwctx);
 
 	while (ret == 0 && ++fwctx->curpos < fwctx->req->n_items) {
@@ -662,13 +687,27 @@ 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_index < BRCMF_FW_MAX_ALT_PATHS &&
+	    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 +732,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 +750,13 @@ 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,
+	if (brcm_alt_fw_paths(first->path, req->board_type,
+			      fwctx->alt_paths) == 0) {
+		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,
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
index e290dec9c53d..7f4e6e359c82 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
@@ -11,6 +11,8 @@
 
 #define BRCMF_FW_DEFAULT_PATH		"brcm/"
 
+#define BRCMF_FW_MAX_ALT_PATHS	8
+
 /**
  * struct brcmf_firmware_mapping - Used to map chipid/revmask to firmware
  *	filename and nvram filename. Each bus type implementation should create
-- 
2.33.0


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

* [PATCH v2 05/35] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (3 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-06 10:48   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
                   ` (31 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
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] 122+ messages in thread

* [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (4 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 05/35] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04 10:22   ` Arend van Spriel
                     ` (2 more replies)
  2022-01-04  7:26 ` [PATCH v2 07/35] brcmfmac: pcie: Read Apple OTP information Hector Martin
                   ` (30 subsequent siblings)
  36 siblings, 3 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
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        |  4 ++-
 .../broadcom/brcm80211/brcmfmac/sdio.c        |  2 +-
 4 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 7570dbf22cdd..054ea3ed133e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -594,28 +594,39 @@ static int brcmf_fw_complete_request(const struct firmware *fw,
 	return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
 }
 
-static int brcm_alt_fw_paths(const char *path, const char *board_type,
+static int brcm_alt_fw_paths(const char *path, struct brcmf_fw *fwctx,
 			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
 {
+	const char **board_types = fwctx->req->board_types;
+	unsigned int i;
 	char alt_path[BRCMF_FW_NAME_LEN];
 	const char *suffix;
 
 	memset(alt_paths, 0, array_size(sizeof(*alt_paths),
 					BRCMF_FW_MAX_ALT_PATHS));
 
+	if (!board_types[0])
+		return -ENOENT;
+
 	suffix = strrchr(path, '.');
 	if (!suffix || suffix == path)
 		return -EINVAL;
 
-	/* strip extension at the end */
-	strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
-	alt_path[suffix - path] = 0;
+	for (i = 0; i < BRCMF_FW_MAX_ALT_PATHS; i++) {
+		if (!board_types[i])
+		    break;
 
-	strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);
-	strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
-	strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
+		/* strip extension at the end */
+		strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
+		alt_path[suffix - path] = 0;
 
-	alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
+		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[i] = kstrdup(alt_path, GFP_KERNEL);
+		brcmf_dbg(TRACE, "FW alt path: %s\n", alt_paths[i]);
+	}
 
 	return 0;
 }
@@ -637,11 +648,10 @@ static int brcmf_fw_request_firmware(const struct firmware **fw,
 	unsigned int i;
 
 	/* Files can be board-specific, first try a board-specific path */
-	if (fwctx->req->board_type) {
+	if (fwctx->req->board_types[0]) {
 		const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS];
 
-		if (brcm_alt_fw_paths(cur->path, fwctx->req->board_type,
-				      alt_paths) != 0)
+		if (brcm_alt_fw_paths(cur->path, fwctx, alt_paths) != 0)
 			goto fallback;
 
 		for (i = 0; i < BRCMF_FW_MAX_ALT_PATHS && alt_paths[i]; i++) {
@@ -750,8 +760,7 @@ 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 */
-	if (brcm_alt_fw_paths(first->path, req->board_type,
-			      fwctx->alt_paths) == 0) {
+	if (brcm_alt_fw_paths(first->path, fwctx, fwctx->alt_paths) == 0) {
 		fwctx->alt_index = 0;
 		ret = request_firmware_nowait(THIS_MODULE, true,
 					      fwctx->alt_paths[0],
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
index 7f4e6e359c82..3b60a0e290b0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
@@ -68,7 +68,7 @@ struct brcmf_fw_request {
 	u16 domain_nr;
 	u16 bus_nr;
 	u32 n_items;
-	const char *board_type;
+	const char *board_types[BRCMF_FW_MAX_ALT_PATHS];
 	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..a52a6f8081eb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1877,11 +1877,13 @@ 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[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..ed944764f6ea 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4432,7 +4432,7 @@ 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[0] = bus->sdiodev->settings->board_type;
 
 	return fwreq;
 }
-- 
2.33.0


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

* [PATCH v2 07/35] brcmfmac: pcie: Read Apple OTP information
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (5 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04 11:26   ` Andy Shevchenko
  2022-01-06 12:37   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 08/35] brcmfmac: of: Fetch Apple properties Hector Martin
                   ` (29 subsequent siblings)
  36 siblings, 2 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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 a52a6f8081eb..74c9a4f74813 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 *board_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;
+
+	board_params = &data[idx];
+
+	/* Skip to terminator of second string */
+	idx += strnlen(board_params, size - idx);
+	if (idx >= size)
+		return -EINVAL;
+
+	/* At this point both strings are guaranteed NUL-terminated */
+	brcmf_dbg(PCIE, "OTP: chip_params='%s' board_params='%s'\n",
+		  chip_params, board_params);
+
+	p = board_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
@@ -1955,6 +2168,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] 122+ messages in thread

* [PATCH v2 08/35] brcmfmac: of: Fetch Apple properties
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (6 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 07/35] brcmfmac: pcie: Read Apple OTP information Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04 11:17   ` Andy Shevchenko
  2022-01-08 20:03   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
                   ` (28 subsequent siblings)
  36 siblings, 2 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.
We map Apple's module codenames to board_types in the form
"apple,<module-instance>".

The mapped board_type is added to the DTS file in that form, while the
antenna-sku is forwarded by our bootloader from the Apple Device Tree
into the FDT. Grab them from the DT so firmware selection can use
them.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
---
 .../wireless/broadcom/brcm80211/brcmfmac/common.h    |  1 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/of.c    | 12 +++++++++++-
 2 files changed, 12 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..085d34176b78 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -63,14 +63,24 @@ 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, "brcm,board-type", &prop))
+		settings->board_type = devm_kstrdup(dev, prop, GFP_KERNEL);
+
+	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] 122+ messages in thread

* [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (7 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 08/35] brcmfmac: of: Fetch Apple properties Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04 14:24   ` Andy Shevchenko
  2022-01-08 20:03   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
                   ` (27 subsequent siblings)
  36 siblings, 2 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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 ACPI (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.

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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
---
 .../broadcom/brcm80211/brcmfmac/pcie.c        | 58 ++++++++++++++++++-
 1 file changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 74c9a4f74813..250e0bd40cb3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -2094,8 +2094,62 @@ 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[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);
+
+		/* 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[0] = devinfo->settings->board_type;
+	}
 
 	return fwreq;
 }
-- 
2.33.0


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

* [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (8 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04 14:23   ` Andy Shevchenko
  2022-01-08 20:14   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 11/35] brcmfmac: msgbuf: Increase RX ring sizes to 1024 Hector Martin
                   ` (26 subsequent siblings)
  36 siblings, 2 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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).

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
---
 .../broadcom/brcm80211/brcmfmac/firmware.c    | 29 +++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 054ea3ed133e..e3f7ac0f5671 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,8 @@ 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 += 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 +375,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 +423,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 +570,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] 122+ messages in thread

* [PATCH v2 11/35] brcmfmac: msgbuf: Increase RX ring sizes to 1024
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (9 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-10  7:17   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 12/35] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
                   ` (25 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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] 122+ messages in thread

* [PATCH v2 12/35] brcmfmac: pcie: Fix crashes due to early IRQs
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (10 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 11/35] brcmfmac: msgbuf: Increase RX ring sizes to 1024 Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04 14:12   ` Andy Shevchenko
  2022-01-10  7:19   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 13/35] brcmfmac: pcie: Support PCIe core revisions >= 64 Hector Martin
                   ` (24 subsequent siblings)
  36 siblings, 2 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 250e0bd40cb3..595815164e18 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] 122+ messages in thread

* [PATCH v2 13/35] brcmfmac: pcie: Support PCIe core revisions >= 64
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (11 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 12/35] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-10  7:31   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 14/35] brcmfmac: pcie: Add IDs/properties for BCM4378 Hector Martin
                   ` (23 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 595815164e18..f3744e806157 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;
 }
@@ -2172,6 +2250,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);
 
@@ -2190,6 +2269,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;
@@ -2358,7 +2443,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] 122+ messages in thread

* [PATCH v2 14/35] brcmfmac: pcie: Add IDs/properties for BCM4378
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (12 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 13/35] brcmfmac: pcie: Support PCIe core revisions >= 64 Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-10  9:10   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 15/35] ACPI / property: Support strings in Apple _DSM props Hector Martin
                   ` (22 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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)

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 f3744e806157..cc76f00724e6 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;
@@ -2509,6 +2516,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] 122+ messages in thread

* [PATCH v2 15/35] ACPI / property: Support strings in Apple _DSM props
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (13 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 14/35] brcmfmac: pcie: Add IDs/properties for BCM4378 Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04  7:26 ` [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
                   ` (21 subsequent siblings)
  36 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list, Lukas Wunner

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

Reviewed-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
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] 122+ messages in thread

* [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (14 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 15/35] ACPI / property: Support strings in Apple _DSM props Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04 10:21   ` Arend van Spriel
  2022-01-10  9:11   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 17/35] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
                   ` (20 subsequent siblings)
  36 siblings, 2 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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        | 47 +++++++++++++++++++
 .../broadcom/brcm80211/brcmfmac/common.c      |  1 +
 .../broadcom/brcm80211/brcmfmac/common.h      |  9 ++++
 4 files changed, 59 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..2b1a4448b291
--- /dev/null
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
@@ -0,0 +1,47 @@
+// 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;
+	const union acpi_object *o;
+	struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL};
+	struct acpi_device *adev = ACPI_COMPANION(dev);
+
+	if (!adev)
+		return;
+
+	if (!ACPI_FAILURE(acpi_dev_get_property(adev, "module-instance",
+						ACPI_TYPE_STRING, &o))) {
+		brcmf_dbg(INFO, "ACPI module-instance=%s\n", o->string.pointer);
+		settings->board_type = devm_kasprintf(dev, GFP_KERNEL,
+						      "apple,%s",
+						      o->string.pointer);
+	} 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] 122+ messages in thread

* [PATCH v2 17/35] brcmfmac: pcie: Provide a buffer of random bytes to the device
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (15 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-10  9:11   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 18/35] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
                   ` (19 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 cc76f00724e6..a8cccfbea20b 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] 122+ messages in thread

* [PATCH v2 18/35] brcmfmac: pcie: Add IDs/properties for BCM4355
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (16 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 17/35] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-10  9:12   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 19/35] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
                   ` (18 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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)

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 a8cccfbea20b..fdba2b5b46f0 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;
@@ -2528,6 +2535,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] 122+ messages in thread

* [PATCH v2 19/35] brcmfmac: pcie: Add IDs/properties for BCM4377
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (17 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 18/35] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-10  9:12   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 20/35] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin
                   ` (17 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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)

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 fdba2b5b46f0..87daabb15cd0 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;
@@ -2554,6 +2557,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] 122+ messages in thread

* [PATCH v2 20/35] brcmfmac: pcie: Perform correct BCM4364 firmware selection
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (18 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 19/35] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-10  9:12   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 21/35] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number Hector Martin
                   ` (16 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 87daabb15cd0..e4f2aff3c0d5 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] 122+ messages in thread

* [PATCH v2 21/35] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (19 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 20/35] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-19 12:36   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 22/35] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks Hector Martin
                   ` (15 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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] 122+ messages in thread

* [PATCH v2 22/35] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (20 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 21/35] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-19 12:36   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 23/35] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
                   ` (14 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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] 122+ messages in thread

* [PATCH v2 23/35] brcmfmac: cfg80211: Add support for scan params v2
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (21 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 22/35] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04 19:46   ` Arend Van Spriel
  2022-01-11  8:50   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 24/35] brcmfmac: feature: Add support for setting feats based on WLC version Hector Martin
                   ` (13 subsequent siblings)
  36 siblings, 2 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
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] 122+ messages in thread

* [PATCH v2 24/35] brcmfmac: feature: Add support for setting feats based on WLC version
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (22 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 23/35] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-21  7:35   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 25/35] brcmfmac: cfg80211: Add support for PMKID_V3 operations Hector Martin
                   ` (12 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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] 122+ messages in thread

* [PATCH v2 25/35] brcmfmac: cfg80211: Add support for PMKID_V3 operations
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (23 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 24/35] brcmfmac: feature: Add support for setting feats based on WLC version Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-21  7:35   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 26/35] brcmfmac: cfg80211: Pass the PMK in binary instead of hex Hector Martin
                   ` (11 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c    | 52 +++++++++++-
 .../broadcom/brcm80211/brcmfmac/fwil_types.h  | 83 +++++++++++++++++++
 2 files changed, 132 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..6dc194924bc1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4029,6 +4029,37 @@ 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);
+	int ret;
+
+	pmk_op = kzalloc(sizeof(*pmk_op), GFP_KERNEL);
+	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);
+
+	ret = brcmf_fil_iovar_data_set(ifp, "pmkid_info", pmk_op, sizeof(*pmk_op));
+	kfree(pmk_op);
+	return ret;
+}
+
 static __used s32
 brcmf_update_pmklist(struct brcmf_cfg80211_info *cfg, struct brcmf_if *ifp)
 {
@@ -4065,6 +4096,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 +4120,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 +4143,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 +4184,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] 122+ messages in thread

* [PATCH v2 26/35] brcmfmac: cfg80211: Pass the PMK in binary instead of hex
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (24 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 25/35] brcmfmac: cfg80211: Add support for PMKID_V3 operations Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-21  7:35   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 27/35] brcmfmac: pcie: Add IDs/properties for BCM4387 Hector Martin
                   ` (10 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 6dc194924bc1..3e66eb31e4d0 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] 122+ messages in thread

* [PATCH v2 27/35] brcmfmac: pcie: Add IDs/properties for BCM4387
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (25 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 26/35] brcmfmac: cfg80211: Pass the PMK in binary instead of hex Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-21  7:35   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 28/35] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio Hector Martin
                   ` (9 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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)

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 e4f2aff3c0d5..0d76440ec228 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;
@@ -2566,6 +2573,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] 122+ messages in thread

* [PATCH v2 28/35] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (26 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 27/35] brcmfmac: pcie: Add IDs/properties for BCM4387 Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04  7:26 ` [PATCH v2 29/35] brcmfmac: pcie: Read the console on init and shutdown Hector Martin
                   ` (8 subsequent siblings)
  36 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 0d76440ec228..c052f7961f44 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] 122+ messages in thread

* [PATCH v2 29/35] brcmfmac: pcie: Read the console on init and shutdown
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (27 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 28/35] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04  7:26 ` [PATCH v2 30/35] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path Hector Martin
                   ` (7 subsequent siblings)
  36 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 c052f7961f44..b3c780608e80 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;
 }
@@ -2387,6 +2390,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] 122+ messages in thread

* [PATCH v2 30/35] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (28 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 29/35] brcmfmac: pcie: Read the console on init and shutdown Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04  7:26 ` [PATCH v2 31/35] brcmfmac: firmware: Allocate space for default boardrev in nvram Hector Martin
                   ` (6 subsequent siblings)
  36 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 b3c780608e80..18903906de55 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] 122+ messages in thread

* [PATCH v2 31/35] brcmfmac: firmware: Allocate space for default boardrev in nvram
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (29 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 30/35] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04  7:26 ` [PATCH v2 32/35] brcmfmac: fwil: Constify iovar name arguments Hector Martin
                   ` (5 subsequent siblings)
  36 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

If boardrev is missing from the NVRAM we add a default one, but this
might need more space in the output buffer than was allocated. Ensure
we have enough padding for this in the buffer.

Fixes: 46f2b38a91b0 ("brcmfmac: insert default boardrev in nvram data if missing")
Signed-off-by: Hector Martin <marcan@marcan.st>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index e3f7ac0f5671..5addb1bc3a80 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -215,6 +215,7 @@ static int brcmf_init_nvram_parser(struct nvram_parser *nvp,
 	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);
-- 
2.33.0


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

* [PATCH v2 32/35] brcmfmac: fwil: Constify iovar name arguments
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (30 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 31/35] brcmfmac: firmware: Allocate space for default boardrev in nvram Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-04  7:26 ` [PATCH v2 33/35] brcmfmac: common: Add support for downloading TxCap blobs Hector Martin
                   ` (4 subsequent siblings)
  36 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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 *.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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] 122+ messages in thread

* [PATCH v2 33/35] brcmfmac: common: Add support for downloading TxCap blobs
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (31 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 32/35] brcmfmac: fwil: Constify iovar name arguments Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-21  7:36   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 34/35] brcmfmac: pcie: Load and provide " Hector Martin
                   ` (3 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
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] 122+ messages in thread

* [PATCH v2 34/35] brcmfmac: pcie: Load and provide TxCap blobs
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (32 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 33/35] brcmfmac: common: Add support for downloading TxCap blobs Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-21  7:36   ` Arend van Spriel
  2022-01-04  7:26 ` [PATCH v2 35/35] brcmfmac: common: Add support for external calibration blobs Hector Martin
                   ` (2 subsequent siblings)
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 18903906de55..ee0b68f5e28e 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;
@@ -2412,6 +2424,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] 122+ messages in thread

* [PATCH v2 35/35] brcmfmac: common: Add support for external calibration blobs
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (33 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 34/35] brcmfmac: pcie: Load and provide " Hector Martin
@ 2022-01-04  7:26 ` Hector Martin
  2022-01-21  7:35   ` Arend van Spriel
  2022-01-04 14:28 ` [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Andy Shevchenko
  2022-01-10 10:14 ` Kalle Valo
  36 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04  7:26 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, Dmitry Osipenko
  Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, 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.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 085d34176b78..6f885c3210c3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -78,6 +78,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] 122+ messages in thread

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-04  7:26 ` [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths Hector Martin
@ 2022-01-04  8:26   ` Dmitry Osipenko
  2022-01-04  8:43     ` Hector Martin
  2022-01-04 22:38   ` Dmitry Osipenko
  2022-01-06 10:43   ` Arend van Spriel
  2 siblings, 1 reply; 122+ messages in thread
From: Dmitry Osipenko @ 2022-01-04  8: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,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

04.01.2022 10:26, 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.
> 
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>  .../broadcom/brcm80211/brcmfmac/firmware.c    | 75 ++++++++++++++-----
>  .../broadcom/brcm80211/brcmfmac/firmware.h    |  2 +
>  2 files changed, 59 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> index 0497b721136a..7570dbf22cdd 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[BRCMF_FW_MAX_ALT_PATHS];
> +	int alt_index;

unsigned int

>  	u32 curpos;
>  	void (*done)(struct device *dev, int err, struct brcmf_fw_request *req);
>  };
> @@ -592,14 +594,18 @@ 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 int brcm_alt_fw_paths(const char *path, const char *board_type,
> +			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])>  {
>  	char alt_path[BRCMF_FW_NAME_LEN];
>  	const char *suffix;
>  
> +	memset(alt_paths, 0, array_size(sizeof(*alt_paths),
> +					BRCMF_FW_MAX_ALT_PATHS));
You don't need to use array_size() since size of a fixed array is
already known.

memset(alt_paths, 0, sizeof(alt_paths));

...
> +static void
> +brcm_free_alt_fw_paths(const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
> +{
> +	unsigned int i;
> +
> +	for (i = 0; alt_paths[i]; i++)

What if array is fully populated and there is no null in the end? Please
don't do this, use BRCMF_FW_MAX_ALT_PATHS or ARRAY_SIZE().

> +		kfree(alt_paths[i]);
>  }
>  
>  static int brcmf_fw_request_firmware(const struct firmware **fw,
> @@ -617,19 +634,25 @@ static int brcmf_fw_request_firmware(const struct firmware **fw,
>  {
>  	struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
>  	int ret;
> +	unsigned int i;

Keep reverse Xmas tree coding style.

...
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
> @@ -11,6 +11,8 @@
>  
>  #define BRCMF_FW_DEFAULT_PATH		"brcm/"
>  
> +#define BRCMF_FW_MAX_ALT_PATHS	8

Two tabs are needed here.

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-04  8:26   ` Dmitry Osipenko
@ 2022-01-04  8:43     ` Hector Martin
  2022-01-04 22:09       ` Dmitry Osipenko
  2022-01-04 22:36       ` Dmitry Osipenko
  0 siblings, 2 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04  8:43 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,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/04 17:26, Dmitry Osipenko wrote:
> 04.01.2022 10:26, 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.
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Hector Martin <marcan@marcan.st>
>> ---
>>  .../broadcom/brcm80211/brcmfmac/firmware.c    | 75 ++++++++++++++-----
>>  .../broadcom/brcm80211/brcmfmac/firmware.h    |  2 +
>>  2 files changed, 59 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>> index 0497b721136a..7570dbf22cdd 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[BRCMF_FW_MAX_ALT_PATHS];
>> +	int alt_index;
> 
> unsigned int

Ack.

> 
>>  	u32 curpos;
>>  	void (*done)(struct device *dev, int err, struct brcmf_fw_request *req);
>>  };
>> @@ -592,14 +594,18 @@ 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 int brcm_alt_fw_paths(const char *path, const char *board_type,
>> +			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])>  {
>>  	char alt_path[BRCMF_FW_NAME_LEN];
>>  	const char *suffix;
>>  
>> +	memset(alt_paths, 0, array_size(sizeof(*alt_paths),
>> +					BRCMF_FW_MAX_ALT_PATHS));
> You don't need to use array_size() since size of a fixed array is
> already known.
> 
> memset(alt_paths, 0, sizeof(alt_paths));

It's a function argument, so that doesn't work and actually throws a
warning. Array function argument notation is informative only; they
behave strictly equivalent to pointers. Try it:

$ cat test.c
#include <stdio.h>

void foo(char x[42])
{
	printf("%ld\n", sizeof(x));
}

int main() {
	char x[42];

	foo(x);
}
$ gcc test.c
test.c: In function ‘foo’:
test.c:5:31: warning: ‘sizeof’ on array function parameter ‘x’ will
return size of ‘char *’ [-Wsizeof-array-argument]
    5 |         printf("%ld\n", sizeof(x));
      |                               ^
test.c:3:15: note: declared here
    3 | void foo(char x[42])
      |          ~~~~~^~~~~
$ ./a.out
8


> 
> ...
>> +static void
>> +brcm_free_alt_fw_paths(const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
>> +{
>> +	unsigned int i;
>> +
>> +	for (i = 0; alt_paths[i]; i++)
> 
> What if array is fully populated and there is no null in the end? Please
> don't do this, use BRCMF_FW_MAX_ALT_PATHS or ARRAY_SIZE().

Argh, forgot to change this one. I used BRCMF_FW_MAX_ALT_PATHS
elsewhere; ARRAY_SIZE won't work as I explained above.

> 
>> +		kfree(alt_paths[i]);
>>  }
>>  
>>  static int brcmf_fw_request_firmware(const struct firmware **fw,
>> @@ -617,19 +634,25 @@ static int brcmf_fw_request_firmware(const struct firmware **fw,
>>  {
>>  	struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
>>  	int ret;
>> +	unsigned int i;
> 
> Keep reverse Xmas tree coding style.

First time I hear this one, heh. Sure.

> 
> ...
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
>> @@ -11,6 +11,8 @@
>>  
>>  #define BRCMF_FW_DEFAULT_PATH		"brcm/"
>>  
>> +#define BRCMF_FW_MAX_ALT_PATHS	8
> 
> Two tabs are needed here.

Will do.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties
  2022-01-04  7:26 ` [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
@ 2022-01-04 10:21   ` Arend van Spriel
  2022-01-04 11:00     ` Hector Martin
  2022-01-10  9:11   ` Arend van Spriel
  1 sibling, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-04 10:21 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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        | 47 +++++++++++++++++++
>   .../broadcom/brcm80211/brcmfmac/common.c      |  1 +
>   .../broadcom/brcm80211/brcmfmac/common.h      |  9 ++++
>   4 files changed, 59 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..2b1a4448b291
> --- /dev/null
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: ISC
> +/*
> + * Copyright The Asahi Linux Contributors
> + */

Common format for copyright statement (in this folder) seems to be:

Copyright (c) <YEAR> <COPYRIGHT_HOLDER>

Regards,
Arend

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

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

* Re: [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types
  2022-01-04  7:26 ` [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
@ 2022-01-04 10:22   ` Arend van Spriel
  2022-01-04 10:30     ` Hector Martin
  2022-01-04 11:28   ` Andy Shevchenko
  2022-01-06 12:16   ` Arend van Spriel
  2 siblings, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-04 10:22 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.
> 
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 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        |  4 ++-
>   .../broadcom/brcm80211/brcmfmac/sdio.c        |  2 +-
>   4 files changed, 27 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> index 7570dbf22cdd..054ea3ed133e 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> @@ -594,28 +594,39 @@ static int brcmf_fw_complete_request(const struct firmware *fw,
>   	return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
>   }
>   
> -static int brcm_alt_fw_paths(const char *path, const char *board_type,
> +static int brcm_alt_fw_paths(const char *path, struct brcmf_fw *fwctx,
>   			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
>   {
> +	const char **board_types = fwctx->req->board_types;
> +	unsigned int i;
>   	char alt_path[BRCMF_FW_NAME_LEN];
>   	const char *suffix;
>   
>   	memset(alt_paths, 0, array_size(sizeof(*alt_paths),
>   					BRCMF_FW_MAX_ALT_PATHS));
>   
> +	if (!board_types[0])
> +		return -ENOENT;
> +
>   	suffix = strrchr(path, '.');
>   	if (!suffix || suffix == path)
>   		return -EINVAL;
>   
> -	/* strip extension at the end */
> -	strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
> -	alt_path[suffix - path] = 0;
> +	for (i = 0; i < BRCMF_FW_MAX_ALT_PATHS; i++) {
> +		if (!board_types[i])
> +		    break;

Indentation error

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

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

* Re: [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types
  2022-01-04 10:22   ` Arend van Spriel
@ 2022-01-04 10:30     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-04 10:30 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/04 19:22, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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.
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> 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        |  4 ++-
>>   .../broadcom/brcm80211/brcmfmac/sdio.c        |  2 +-
>>   4 files changed, 27 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>> index 7570dbf22cdd..054ea3ed133e 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>> @@ -594,28 +594,39 @@ static int brcmf_fw_complete_request(const struct firmware *fw,
>>   	return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
>>   }
>>   
>> -static int brcm_alt_fw_paths(const char *path, const char *board_type,
>> +static int brcm_alt_fw_paths(const char *path, struct brcmf_fw *fwctx,
>>   			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
>>   {
>> +	const char **board_types = fwctx->req->board_types;
>> +	unsigned int i;
>>   	char alt_path[BRCMF_FW_NAME_LEN];
>>   	const char *suffix;
>>   
>>   	memset(alt_paths, 0, array_size(sizeof(*alt_paths),
>>   					BRCMF_FW_MAX_ALT_PATHS));
>>   
>> +	if (!board_types[0])
>> +		return -ENOENT;
>> +
>>   	suffix = strrchr(path, '.');
>>   	if (!suffix || suffix == path)
>>   		return -EINVAL;
>>   
>> -	/* strip extension at the end */
>> -	strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
>> -	alt_path[suffix - path] = 0;
>> +	for (i = 0; i < BRCMF_FW_MAX_ALT_PATHS; i++) {
>> +		if (!board_types[i])
>> +		    break;
> 
> Indentation error

I knew I had a feeling I was forgetting to do something... that was
running v2 through checkpatch. Sigh. Thanks for catching that, fixed :)

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties
  2022-01-04 10:21   ` Arend van Spriel
@ 2022-01-04 11:00     ` Hector Martin
  2022-01-10 14:01       ` Kalle Valo
  0 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-04 11:00 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/04 19:21, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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        | 47 +++++++++++++++++++
>>   .../broadcom/brcm80211/brcmfmac/common.c      |  1 +
>>   .../broadcom/brcm80211/brcmfmac/common.h      |  9 ++++
>>   4 files changed, 59 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..2b1a4448b291
>> --- /dev/null
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
>> @@ -0,0 +1,47 @@
>> +// SPDX-License-Identifier: ISC
>> +/*
>> + * Copyright The Asahi Linux Contributors
>> + */
> 
> Common format for copyright statement (in this folder) seems to be:
> 
> Copyright (c) <YEAR> <COPYRIGHT_HOLDER>
> 
> Regards,
> Arend

I get this every time I submit a patch to a new subsystem :-)

This is based on this best practice:

https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/

Basically, the year format quickly becomes outdated and is rather
useless, and listing specific names also ends up missing every
subsequent contributor, so more general copyright statements work better
for this kind of use case. In the end we all know git history is the
proper record of copyright status.

I don't have a super strong opinion here, but we've been trying to
standardize on this format for contributions coming from our subproject,
and it feels more useful than a random contributor's name with a date 5
years in the past :)

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 08/35] brcmfmac: of: Fetch Apple properties
  2022-01-04  7:26 ` [PATCH v2 08/35] brcmfmac: of: Fetch Apple properties Hector Martin
@ 2022-01-04 11:17   ` Andy Shevchenko
  2022-01-07  3:54     ` Hector Martin
  2022-01-08 20:03   ` Arend van Spriel
  1 sibling, 1 reply; 122+ messages in thread
From: Andy Shevchenko @ 2022-01-04 11: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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On Tue, Jan 4, 2022 at 9:28 AM 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.
> We map Apple's module codenames to board_types in the form
> "apple,<module-instance>".
>
> The mapped board_type is added to the DTS file in that form, while the
> antenna-sku is forwarded by our bootloader from the Apple Device Tree
> into the FDT. Grab them from the DT so firmware selection can use
> them.

> +       /* 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, "brcm,board-type", &prop))
> +               settings->board_type = devm_kstrdup(dev, prop, GFP_KERNEL);
> +
> +       if (!of_property_read_string(np, "apple,antenna-sku", &prop))
> +               settings->antenna_sku = devm_kstrdup(dev, prop, GFP_KERNEL);

No error checks?
But hold on, why do you need to copy them? Are you expecting this to be in DTO?

-- 
With Best Regards,
Andy Shevchenko

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

* Re: [PATCH v2 07/35] brcmfmac: pcie: Read Apple OTP information
  2022-01-04  7:26 ` [PATCH v2 07/35] brcmfmac: pcie: Read Apple OTP information Hector Martin
@ 2022-01-04 11:26   ` Andy Shevchenko
  2022-01-07  3:53     ` Hector Martin
  2022-01-06 12:37   ` Arend van Spriel
  1 sibling, 1 reply; 122+ messages in thread
From: Andy Shevchenko @ 2022-01-04 11:26 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On Tue, Jan 4, 2022 at 9:28 AM 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.

...

> +static int
> +brcmf_pcie_parse_otp_sys_vendor(struct brcmf_pciedev_info *devinfo,
> +                               u8 *data, size_t size)
> +{
> +       int idx = 4;

Can you rather have a structure

struct my_cool_and_strange_blob {
__le32 hdr;
const char ...[];
...
}

and then cast your data to this struct?

> +       const char *chip_params;
> +       const char *board_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;

strsep() ?

> +       if (idx >= size)
> +               return -EINVAL;
> +
> +       board_params = &data[idx];
> +
> +       /* Skip to terminator of second string */
> +       idx += strnlen(board_params, size - idx);
> +       if (idx >= size)
> +               return -EINVAL;
> +
> +       /* At this point both strings are guaranteed NUL-terminated */
> +       brcmf_dbg(PCIE, "OTP: chip_params='%s' board_params='%s'\n",
> +                 chip_params, board_params);
> +
> +       p = board_params;
> +       while (*p) {
> +               char tag = *p++;
> +               const char *end;
> +               size_t len;
> +
> +               if (tag == ' ') /* Skip extra spaces */
> +                       continue;

skip_spaces()

> +
> +               if (*p++ != '=') /* implicit NUL check */
> +                       return -EINVAL;

Have you checked the next_arg() implementation?

> +               /* *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;

Use proper error codes.

> +       brcmf_dbg(PCIE, "parse_otp size=%ld\n", size);
> +
> +       while (p < (size - 1)) {

too many parentheses

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

length as hex a bit harder to parse

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


length + 2 is easier to read.

> +       }
> +
> +       return ret;
> +}

...

> +               /* Map OTP to shadow area */
> +               WRITECC32(devinfo, sromcontrol,
> +                         sromctl | BCMA_CC_SROM_CONTROL_OTPSEL);

One line?

...

> +       otp = kzalloc(sizeof(u16) * words, GFP_KERNEL);

No check, why? I see in many places you forgot to check for NULL from
allocator functions.
Moreover here you should use kcalloc() which does overflow protection.

-- 
With Best Regards,
Andy Shevchenko

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

* Re: [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types
  2022-01-04  7:26 ` [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
  2022-01-04 10:22   ` Arend van Spriel
@ 2022-01-04 11:28   ` Andy Shevchenko
  2022-01-07  2:50     ` Hector Martin
  2022-01-06 12:16   ` Arend van Spriel
  2 siblings, 1 reply; 122+ messages in thread
From: Andy Shevchenko @ 2022-01-04 11:28 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On Tue, Jan 4, 2022 at 9:28 AM 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.

> +               /* strip extension at the end */
> +               strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
> +               alt_path[suffix - path] = 0;
>
> -       alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
> +               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[i] = kstrdup(alt_path, GFP_KERNEL);
> +               brcmf_dbg(TRACE, "FW alt path: %s\n", alt_paths[i]);

Consider replacing these string manipulations with kasprintf().

-- 
With Best Regards,
Andy Shevchenko

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

* Re: [PATCH v2 12/35] brcmfmac: pcie: Fix crashes due to early IRQs
  2022-01-04  7:26 ` [PATCH v2 12/35] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
@ 2022-01-04 14:12   ` Andy Shevchenko
  2022-01-06 13:10     ` Hector Martin
  2022-01-10  7:19   ` Arend van Spriel
  1 sibling, 1 reply; 122+ messages in thread
From: Andy Shevchenko @ 2022-01-04 14: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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On Tue, Jan 4, 2022 at 9:29 AM 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.")

You should gather fixes at the beginning of the series, and even
possible to send them as a separate series. In the current state it's
unclear if there are dependencies on your new feature (must not be for
fixes that meant to be backported).

-- 
With Best Regards,
Andy Shevchenko

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

* Re: [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr
  2022-01-04  7:26 ` [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
@ 2022-01-04 14:23   ` Andy Shevchenko
  2022-01-05 13:26     ` Hector Martin
  2022-01-08 20:14   ` Arend van Spriel
  1 sibling, 1 reply; 122+ messages in thread
From: Andy Shevchenko @ 2022-01-04 14: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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On Tue, Jan 4, 2022 at 9:29 AM 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).

...

> +#define BRCMF_FW_MACADDR_FMT                   "macaddr=%pM"
> +#define BRCMF_FW_MACADDR_LEN                   (7 + ETH_ALEN * 3)

...

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

If it has no side effects, I would rather swap the operands of && so
you match string first (it will be in align with above code at least,
although I haven't checked bigger context).

....

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

Please, avoid using implict format string, it's dangerous from security p.o.v.

> +       nvp->nvram_len += BRCMF_FW_MACADDR_LEN + 1;

Also, with temporary variable the code can be better to read

size_t mac_len = ...;

> +}

-- 
With Best Regards,
Andy Shevchenko

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

* Re: [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms
  2022-01-04  7:26 ` [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
@ 2022-01-04 14:24   ` Andy Shevchenko
  2022-01-06 13:12     ` Hector Martin
  2022-01-08 20:03   ` Arend van Spriel
  1 sibling, 1 reply; 122+ messages in thread
From: Andy Shevchenko @ 2022-01-04 14:24 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On Tue, Jan 4, 2022 at 9:28 AM 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 ACPI (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.
>
> 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.

...

> +       /* 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);

NIH devm_kasprrintf() ?

> +               /* 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;

-- 
With Best Regards,
Andy Shevchenko

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

* Re: [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (34 preceding siblings ...)
  2022-01-04  7:26 ` [PATCH v2 35/35] brcmfmac: common: Add support for external calibration blobs Hector Martin
@ 2022-01-04 14:28 ` Andy Shevchenko
  2022-01-10 10:14 ` Kalle Valo
  36 siblings, 0 replies; 122+ messages in thread
From: Andy Shevchenko @ 2022-01-04 14:28 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On Tue, Jan 4, 2022 at 9:27 AM Hector Martin <marcan@marcan.st> wrote:
>
> Hi everyone,
>
> Happy new year! This 35-patch series adds 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:
>
> - brcm,board-type: Overrides the board-type which is used for firmware
>   selection on all platforms, which normally comes from the DMI device
>   name or the root node compatible. Apple have their own
>   mapping/identifier here ("island" name), so we prefix it with "apple,"
>   and use it as the board-type override.
>
> - 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~32: 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.
>
> # 33-35: 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.

I looked into the ~half of the series and basically common mistakes
you have are (but not limited to):
 - missed checks for error from allocator calls
 - NIH devm_kasprintf()
 - quite possible reinveting a wheel of many functions we have already
implemented in the kernel.

Suggestion for the last one is to use `git grep ...`, which is very
powerful instrument, and just always questioning yourself "I'm doing
XYZ and my gut feeling is that XYZ is (so) generic I can't believe
there is no implementation of it already exists in the kernel". This
is how I come up with a lot of cleanups done in the past.

-- 
With Best Regards,
Andy Shevchenko

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

* Re: [PATCH v2 23/35] brcmfmac: cfg80211: Add support for scan params v2
  2022-01-04  7:26 ` [PATCH v2 23/35] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
@ 2022-01-04 19:46   ` Arend Van Spriel
  2022-01-17  6:57     ` Hector Martin
  2022-01-11  8:50   ` Arend van Spriel
  1 sibling, 1 reply; 122+ messages in thread
From: Arend Van Spriel @ 2022-01-04 19:46 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On January 4, 2022 8:30:51 AM 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.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 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(-)

Compiling this patch with C=2 gives following warnings:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1086:28: 
warning: incorrect type in assignment (different base types)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1086:28: 
expected restricted __le16 [usertype] version
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1086:28: got int
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1148:38: 
warning: incorrect type in assignment (different base types)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1148:38: 
expected restricted __le32 [usertype] scan_type
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1148:38: got int
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:789:30: 
warning: incorrect type in assignment (different base types)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:789:30: 
expected unsigned char [usertype] scan_type
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:789:30: got 
restricted __le32 [usertype] scan_type

Will check if this is a valid warning.

Regards,
Arend




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

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-04  8:43     ` Hector Martin
@ 2022-01-04 22:09       ` Dmitry Osipenko
  2022-01-05 13:22         ` Hector Martin
  2022-01-04 22:36       ` Dmitry Osipenko
  1 sibling, 1 reply; 122+ messages in thread
From: Dmitry Osipenko @ 2022-01-04 22:09 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,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

04.01.2022 11:43, Hector Martin пишет:
>>> +static int brcm_alt_fw_paths(const char *path, const char *board_type,
>>> +			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])>  {
>>>  	char alt_path[BRCMF_FW_NAME_LEN];
>>>  	const char *suffix;
>>>  
>>> +	memset(alt_paths, 0, array_size(sizeof(*alt_paths),
>>> +					BRCMF_FW_MAX_ALT_PATHS));
>> You don't need to use array_size() since size of a fixed array is
>> already known.
>>
>> memset(alt_paths, 0, sizeof(alt_paths));
> It's a function argument, so that doesn't work and actually throws a
> warning. Array function argument notation is informative only; they
> behave strictly equivalent to pointers. Try it:
> 
> $ cat test.c
> #include <stdio.h>
> 
> void foo(char x[42])
> {
> 	printf("%ld\n", sizeof(x));
> }
> 
> int main() {
> 	char x[42];
> 
> 	foo(x);
> }
> $ gcc test.c
> test.c: In function ‘foo’:
> test.c:5:31: warning: ‘sizeof’ on array function parameter ‘x’ will
> return size of ‘char *’ [-Wsizeof-array-argument]
>     5 |         printf("%ld\n", sizeof(x));
>       |                               ^
> test.c:3:15: note: declared here
>     3 | void foo(char x[42])
>       |          ~~~~~^~~~~
> $ ./a.out
> 8

Then please use "const char **alt_paths" for the function argument to
make code cleaner and add another argument to pass the number of array
elements.

static int brcm_alt_fw_paths(const char *path, const char *board_type,
			     const char **alt_paths, unsigned int num_paths)
{
	size_t alt_paths_size = array_size(sizeof(*alt_paths), num_paths);
	
	memset(alt_paths, 0, alt_paths_size);
}

...

Maybe even better create a dedicated struct for the alt_paths:

struct brcmf_fw_alt_paths {
	const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS];
	unsigned int index;
};

and then use the ".index" in the brcm_free_alt_fw_paths(). I suppose
this will make code a bit nicer and easier to follow.

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-04  8:43     ` Hector Martin
  2022-01-04 22:09       ` Dmitry Osipenko
@ 2022-01-04 22:36       ` Dmitry Osipenko
  1 sibling, 0 replies; 122+ messages in thread
From: Dmitry Osipenko @ 2022-01-04 22:36 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,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

04.01.2022 11:43, Hector Martin пишет:
>>> @@ -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[BRCMF_FW_MAX_ALT_PATHS];
>>> +	int alt_index;
>> unsigned int
> Ack.
> 

The same applies to the rest of the patches. If value can't be negative,
then please use unsigned type. This makes code more consistent.

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-04  7:26 ` [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths Hector Martin
  2022-01-04  8:26   ` Dmitry Osipenko
@ 2022-01-04 22:38   ` Dmitry Osipenko
  2022-01-06 10:43   ` Arend van Spriel
  2 siblings, 0 replies; 122+ messages in thread
From: Dmitry Osipenko @ 2022-01-04 22: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
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

04.01.2022 10:26, Hector Martin пишет:
> +static int brcm_alt_fw_paths(const char *path, const char *board_type,
> +			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
>  {
...
> +static void
> +brcm_free_alt_fw_paths(const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
> +{

I'd rename this funcs to brcm_init/deinit_alt_fw_paths(), for
consistency and clarity.

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-04 22:09       ` Dmitry Osipenko
@ 2022-01-05 13:22         ` Hector Martin
  2022-01-06 17:40           ` Dmitry Osipenko
  0 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-05 13:22 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,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 05/01/2022 07.09, Dmitry Osipenko wrote:
> 04.01.2022 11:43, Hector Martin пишет:
>>>> +static int brcm_alt_fw_paths(const char *path, const char *board_type,
>>>> +			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])>  {
>>>>  	char alt_path[BRCMF_FW_NAME_LEN];
>>>>  	const char *suffix;
>>>>  
>>>> +	memset(alt_paths, 0, array_size(sizeof(*alt_paths),
>>>> +					BRCMF_FW_MAX_ALT_PATHS));
>>> You don't need to use array_size() since size of a fixed array is
>>> already known.
>>>
>>> memset(alt_paths, 0, sizeof(alt_paths));
>> It's a function argument, so that doesn't work and actually throws a
>> warning. Array function argument notation is informative only; they
>> behave strictly equivalent to pointers. Try it:
>>
>> $ cat test.c
>> #include <stdio.h>
>>
>> void foo(char x[42])
>> {
>> 	printf("%ld\n", sizeof(x));
>> }
>>
>> int main() {
>> 	char x[42];
>>
>> 	foo(x);
>> }
>> $ gcc test.c
>> test.c: In function ‘foo’:
>> test.c:5:31: warning: ‘sizeof’ on array function parameter ‘x’ will
>> return size of ‘char *’ [-Wsizeof-array-argument]
>>     5 |         printf("%ld\n", sizeof(x));
>>       |                               ^
>> test.c:3:15: note: declared here
>>     3 | void foo(char x[42])
>>       |          ~~~~~^~~~~
>> $ ./a.out
>> 8
> 
> Then please use "const char **alt_paths" for the function argument to
> make code cleaner and add another argument to pass the number of array
> elements.

So you want me to do the ARRAY_SIZE at the caller side then?

> 
> static int brcm_alt_fw_paths(const char *path, const char *board_type,
> 			     const char **alt_paths, unsigned int num_paths)
> {
> 	size_t alt_paths_size = array_size(sizeof(*alt_paths), num_paths);
> 	
> 	memset(alt_paths, 0, alt_paths_size);
> }
> 
> ...
> 
> Maybe even better create a dedicated struct for the alt_paths:
> 
> struct brcmf_fw_alt_paths {
> 	const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS];
> 	unsigned int index;
> };
> 
> and then use the ".index" in the brcm_free_alt_fw_paths(). I suppose
> this will make code a bit nicer and easier to follow.
> 

I'm confused; the array size is constant. What would index contain and
why would would brcm_free_alt_fw_paths use it? Just as an iterator
variable instead of using a local variable? Or do you mean count?

Though, to be honest, at this point I'm considering rethinking the whole
patch for this mechanism because I'm not terribly happy with the current
approach and clearly you aren't either :-) Maybe it makes more sense to
stop trying to compute all the alt_paths ahead of time, and just have
the function compute a single one to be used just-in-time at firmware
request time, and just iterate over board_types.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr
  2022-01-04 14:23   ` Andy Shevchenko
@ 2022-01-05 13:26     ` Hector Martin
  2022-01-06 14:20       ` Andy Shevchenko
  0 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-05 13:26 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On 04/01/2022 23.23, Andy Shevchenko wrote:
> On Tue, Jan 4, 2022 at 9:29 AM 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).
> 
> ...
> 
>> +#define BRCMF_FW_MACADDR_FMT                   "macaddr=%pM"
>> +#define BRCMF_FW_MACADDR_LEN                   (7 + ETH_ALEN * 3)
> 
> ...
> 
>>                 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)
> 
> If it has no side effects, I would rather swap the operands of && so
> you match string first (it will be in align with above code at least,
> although I haven't checked bigger context).

I usually check for trivial flags before calling more expensive
functions because it's more efficient in the common case. Obviously here
performance doesn't matter though.

> 
> ....
> 
>> +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);
> 
> Please, avoid using implict format string, it's dangerous from security p.o.v.

What do you mean by implicit format string? The format string is at the
top of the file and its length is right next to it, which makes it
harder for them to accidentally fall out of sync.

+#define BRCMF_FW_MACADDR_FMT			"macaddr=%pM"
+#define BRCMF_FW_MACADDR_LEN			(7 + ETH_ALEN * 3)

> 
>> +       nvp->nvram_len += BRCMF_FW_MACADDR_LEN + 1;
> 
> Also, with temporary variable the code can be better to read
> 
> size_t mac_len = ...;
> 

Sure.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 02/35] brcmfmac: pcie: Declare missing firmware files in pcie.c
  2022-01-04  7:26 ` [PATCH v2 02/35] brcmfmac: pcie: Declare missing firmware files in pcie.c Hector Martin
@ 2022-01-06  9:56   ` Arend van Spriel
  2022-01-06 11:10     ` Hector Martin
  0 siblings, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-06  9:56 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Actually, any bus is optional so each bus should indeed declare the 
applicable firmware names/patterns.

> Fixes: 75729e110e68 ("brcmfmac: expose firmware config files through modinfo")
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   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");

what is this one for? Those would be covered by the specific 
BRCMF_FW_DEF() macro instances, no?

> +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");

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

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

* Re: [PATCH v2 03/35] brcmfmac: firmware: Handle per-board clm_blob files
  2022-01-04  7:26 ` [PATCH v2 03/35] brcmfmac: firmware: Handle per-board clm_blob files Hector Martin
@ 2022-01-06 10:19   ` Arend van Spriel
  2022-01-06 10:59     ` Hector Martin
  0 siblings, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-06 10:19 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Are you sure? I am not involved in development for Apple platforms, but 
in general we build a CLM blob specific for a chip revision. As always 
with the blobs they are created at a certain point in time and that is 
mostly why you need another one for a newer platform. Apple tends to do 
things a bit different so you could be right though. Anyway, despite my 
doubts on this it does not change the need for per-board firmware files.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 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 0eb13e5df517..0497b721136a 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> @@ -595,16 +595,16 @@ static int brcmf_fw_complete_request(const struct firmware *fw,
>   static char *brcm_alt_fw_path(const char *path, const char *board_type)
>   {
>   	char alt_path[BRCMF_FW_NAME_LEN];
> -	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);
> @@ -619,7 +619,7 @@ static int brcmf_fw_request_firmware(const struct firmware **fw,
>   	int ret;
>   
>   	/* 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) {
>   		char *alt_path;
>   
>   		alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);

So all firmware files are attempted with board-specific path now.

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

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-04  7:26 ` [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths Hector Martin
  2022-01-04  8:26   ` Dmitry Osipenko
  2022-01-04 22:38   ` Dmitry Osipenko
@ 2022-01-06 10:43   ` Arend van Spriel
  2022-01-06 11:12     ` Hector Martin
  2 siblings, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-06 10:43 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   .../broadcom/brcm80211/brcmfmac/firmware.c    | 75 ++++++++++++++-----
>   .../broadcom/brcm80211/brcmfmac/firmware.h    |  2 +
>   2 files changed, 59 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> index 0497b721136a..7570dbf22cdd 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[BRCMF_FW_MAX_ALT_PATHS];
> +	int alt_index;
>   	u32 curpos;
>   	void (*done)(struct device *dev, int err, struct brcmf_fw_request *req);
>   };
> @@ -592,14 +594,18 @@ 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 int brcm_alt_fw_paths(const char *path, const char *board_type,
> +			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
>   {
>   	char alt_path[BRCMF_FW_NAME_LEN];
>   	const char *suffix;
>   
> +	memset(alt_paths, 0, array_size(sizeof(*alt_paths),
> +					BRCMF_FW_MAX_ALT_PATHS));
> +
>   	suffix = strrchr(path, '.');
>   	if (!suffix || suffix == path)
> -		return NULL;
> +		return -EINVAL;
>   
>   	/* strip extension at the end */
>   	strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
> @@ -609,7 +615,18 @@ 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[0] = kstrdup(alt_path, GFP_KERNEL);
> +
> +	return 0;
> +}
> +
> +static void
> +brcm_free_alt_fw_paths(const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
> +{
> +	unsigned int i;
> +
> +	for (i = 0; alt_paths[i]; i++)
> +		kfree(alt_paths[i]);
>   }
>   
>   static int brcmf_fw_request_firmware(const struct firmware **fw,
> @@ -617,19 +634,25 @@ static int brcmf_fw_request_firmware(const struct firmware **fw,
>   {
>   	struct brcmf_fw_item *cur = &fwctx->req->items[fwctx->curpos];
>   	int ret;
> +	unsigned int i;
>   
>   	/* Files can be board-specific, first try a board-specific path */
>   	if (fwctx->req->board_type) {
> -		char *alt_path;
> +		const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS];
>   
> -		alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);
> -		if (!alt_path)
> +		if (brcm_alt_fw_paths(cur->path, fwctx->req->board_type,
> +				      alt_paths) != 0)
>   			goto fallback;
>   
> -		ret = request_firmware(fw, alt_path, fwctx->dev);
> -		kfree(alt_path);
> -		if (ret == 0)
> -			return ret;
> +		for (i = 0; i < BRCMF_FW_MAX_ALT_PATHS && 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 +664,8 @@ 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);
> +
>   	ret = brcmf_fw_complete_request(fw, fwctx);
>   
>   	while (ret == 0 && ++fwctx->curpos < fwctx->req->n_items) {
> @@ -662,13 +687,27 @@ 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_index < BRCMF_FW_MAX_ALT_PATHS &&
> +	    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 +732,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 +750,13 @@ 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,
> +	if (brcm_alt_fw_paths(first->path, req->board_type,
> +			      fwctx->alt_paths) == 0) {
> +		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,
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
> index e290dec9c53d..7f4e6e359c82 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
> @@ -11,6 +11,8 @@
>   
>   #define BRCMF_FW_DEFAULT_PATH		"brcm/"
>   
> +#define BRCMF_FW_MAX_ALT_PATHS	8
> +

Any motivation to have 8 here today? In patch #9 I see a list of 6 paths 
in the commit message so you need 6 and rounded up here to power of 2?

>   /**
>    * struct brcmf_firmware_mapping - Used to map chipid/revmask to firmware
>    *	filename and nvram filename. Each bus type implementation should create

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

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

* Re: [PATCH v2 05/35] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism
  2022-01-04  7:26 ` [PATCH v2 05/35] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism Hector Martin
@ 2022-01-06 10:48   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-06 10:48 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Looks good to me.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 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(-)

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

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

* Re: [PATCH v2 03/35] brcmfmac: firmware: Handle per-board clm_blob files
  2022-01-06 10:19   ` Arend van Spriel
@ 2022-01-06 10:59     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-06 10:59 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/06 19:19, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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.
> 
> Are you sure? I am not involved in development for Apple platforms, but 
> in general we build a CLM blob specific for a chip revision. As always 
> with the blobs they are created at a certain point in time and that is 
> mostly why you need another one for a newer platform. Apple tends to do 
> things a bit different so you could be right though. Anyway, despite my 
> doubts on this it does not change the need for per-board firmware files.

Yup, I'm sure. The 2021 MacBook Pro 14" and the MacBook Pro 16", both
using BCM4387 and both released simultaneously, have different CLM
blobs; they're even a significantly different size. Running `strings` on
the files yields:

CLM DATA
Oly.Maldives
1.61.4
ClmImport: 1.63.1
v3 Final 210923

CLM DATA
Oly.Madagascar
1.61.4
ClmImport: 1.63.1
v4 Final 210923

The data shows significant differences and since the file format is
opaque I can't know what's going on. Even if it's safe to use one file
for both, unless there is some way for me to programmatically identify
this fact so I can incorporate that logic into my firmware copier, I
would much rather just keep them separate like Apple does.

> So all firmware files are attempted with board-specific path now.

Yes, I figured I'd keep things uniform. Technically for Apple platforms
the CLM blob and firmware are only per-board and possibly per-antenna
(they don't need the module variants, those are for nvram only), but
there's no real harm in unifying it and using the same firmware naming
alt path list for everything.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 02/35] brcmfmac: pcie: Declare missing firmware files in pcie.c
  2022-01-06  9:56   ` Arend van Spriel
@ 2022-01-06 11:10     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-06 11:10 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/06 18:56, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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.
> 
> Actually, any bus is optional so each bus should indeed declare the 
> applicable firmware names/patterns.

Of course; I didn't mean *only* SDIO support is optional :)

>> +/* firmware config files */
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.txt");
> 
> what is this one for? Those would be covered by the specific 
> BRCMF_FW_DEF() macro instances, no?

The BRCMF_FW_DEF() macro only declares the .bin file; BRCMF_FW_CLM_DEF
declares that and the .clm_blob. Neither declare the NVRAM .txt.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-06 10:43   ` Arend van Spriel
@ 2022-01-06 11:12     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-06 11:12 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/06 19:43, Arend van Spriel wrote:
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
>> index e290dec9c53d..7f4e6e359c82 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
>> @@ -11,6 +11,8 @@
>>   
>>   #define BRCMF_FW_DEFAULT_PATH		"brcm/"
>>   
>> +#define BRCMF_FW_MAX_ALT_PATHS	8
>> +
> 
> Any motivation to have 8 here today? In patch #9 I see a list of 6 paths 
> in the commit message so you need 6 and rounded up here to power of 2?
> 

Heh, yeah, that's just my powers-of-two-are-nice-numbers habit. I can
drop it down to 6 if you prefer.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types
  2022-01-04  7:26 ` [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
  2022-01-04 10:22   ` Arend van Spriel
  2022-01-04 11:28   ` Andy Shevchenko
@ 2022-01-06 12:16   ` Arend van Spriel
  2022-01-07  4:02     ` Hector Martin
  2 siblings, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-06 12:16 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 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        |  4 ++-
>   .../broadcom/brcm80211/brcmfmac/sdio.c        |  2 +-
>   4 files changed, 27 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> index 7570dbf22cdd..054ea3ed133e 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> @@ -594,28 +594,39 @@ static int brcmf_fw_complete_request(const struct firmware *fw,
>   	return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
>   }
>   
> -static int brcm_alt_fw_paths(const char *path, const char *board_type,
> +static int brcm_alt_fw_paths(const char *path, struct brcmf_fw *fwctx,
>   			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
>   {
> +	const char **board_types = fwctx->req->board_types;
> +	unsigned int i;
>   	char alt_path[BRCMF_FW_NAME_LEN];
>   	const char *suffix;

[...]

> +	for (i = 0; i < BRCMF_FW_MAX_ALT_PATHS; i++) {
> +		if (!board_types[i])
> +		    break;
>   
> -	strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);
> -	strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
> -	strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
> +		/* strip extension at the end */
> +		strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
> +		alt_path[suffix - path] = 0;
>   
> -	alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
> +		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[i] = kstrdup(alt_path, GFP_KERNEL);
> +		brcmf_dbg(TRACE, "FW alt path: %s\n", alt_paths[i]);

Could use alt_path in the debug print thus avoiding additional array 
access (working hard to find those nits to pick ;-) ).

> +	}

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

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

* Re: [PATCH v2 07/35] brcmfmac: pcie: Read Apple OTP information
  2022-01-04  7:26 ` [PATCH v2 07/35] brcmfmac: pcie: Read Apple OTP information Hector Martin
  2022-01-04 11:26   ` Andy Shevchenko
@ 2022-01-06 12:37   ` Arend van Spriel
  2022-01-06 13:08     ` Hector Martin
  1 sibling, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-06 12:37 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> 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 a52a6f8081eb..74c9a4f74813 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c

[...]

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

Does not seem this code is put to work yet. Will dive into it later on.

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

I guess this changes the bar window...

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

... which is why you need to reselect the core. Otherwise it makes no 
sense to me.

> +		WRITECC32(devinfo, sromcontrol, sromctl);
> +	}
> +
> +	ret = brcmf_pcie_parse_otp(devinfo, (u8 *)otp, 2 * words);
> +	kfree(otp);
> +
> +	return ret;
> +}

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

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

* Re: [PATCH v2 07/35] brcmfmac: pcie: Read Apple OTP information
  2022-01-06 12:37   ` Arend van Spriel
@ 2022-01-06 13:08     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-06 13:08 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 06/01/2022 21.37, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin wrote:
>> +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;
>> +	}
> 
> Does not seem this code is put to work yet. Will dive into it later on.

The specific OTP ranges and cores are added by the subsequent patches
that add support for individual chips, once all the scaffolding is in place.

> 
>> +	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);
> 
> I guess this changes the bar window...
> 
>> +	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);
> 
> ... which is why you need to reselect the core. Otherwise it makes no 
> sense to me.

Yes; *technically* with the BCMA_CORE_CHIPCOMMON core the OTP is always
within the first 0x1000 and so I wouldn't have to reselect it, since
it'd end up with the same window, but that is not the case with
BCMA_CORE_GCI used on other chips (where the OTP offset is >0x1000),
although those don't hit this code path. So while this line could be
removed without causing any issues, I find it more orthogonal and safer
to keep the pattern where I select the core before accessing
core-relative fixed registers, and treat brcmf_pcie_buscore_prep_addr as
invalidating the BAR window for all intents and purposes.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 12/35] brcmfmac: pcie: Fix crashes due to early IRQs
  2022-01-04 14:12   ` Andy Shevchenko
@ 2022-01-06 13:10     ` Hector Martin
  2022-01-10 13:54       ` Kalle Valo
  0 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-06 13:10 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On 04/01/2022 23.12, Andy Shevchenko wrote:
> On Tue, Jan 4, 2022 at 9:29 AM 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.")
> 
> You should gather fixes at the beginning of the series, and even
> possible to send them as a separate series. In the current state it's
> unclear if there are dependencies on your new feature (must not be for
> fixes that meant to be backported).
> 

Thanks, I wasn't sure what order you wanted those in. I'll put them at
the top for v3. I think none of those should have any dependencies on
the rest of the patches, modulo some trivial rebase wrangling.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms
  2022-01-04 14:24   ` Andy Shevchenko
@ 2022-01-06 13:12     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-06 13:12 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On 04/01/2022 23.24, Andy Shevchenko wrote:
> On Tue, Jan 4, 2022 at 9:28 AM Hector Martin <marcan@marcan.st> wrote:

>> +               /* 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);
> 
> NIH devm_kasprrintf() ?

This one builds it incrementally, but you're right, kasprintf is
probably more readable here and fewer lines even though it'll duplicate
all the previous argument references for each pattern. I'll redo it with
devm_kasprintf().

> 
>> +               /* 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;
> 


-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr
  2022-01-05 13:26     ` Hector Martin
@ 2022-01-06 14:20       ` Andy Shevchenko
  2022-01-07  2:39         ` Hector Martin
  0 siblings, 1 reply; 122+ messages in thread
From: Andy Shevchenko @ 2022-01-06 14: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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On Wed, Jan 5, 2022 at 3:26 PM Hector Martin <marcan@marcan.st> wrote:
> On 04/01/2022 23.23, Andy Shevchenko wrote:
> > On Tue, Jan 4, 2022 at 9:29 AM Hector Martin <marcan@marcan.st> wrote:

...

> >> +#define BRCMF_FW_MACADDR_FMT                   "macaddr=%pM"

> >> +       snprintf(&nvp->nvram[nvp->nvram_len], BRCMF_FW_MACADDR_LEN + 1,
> >> +                BRCMF_FW_MACADDR_FMT, mac);
> >
> > Please, avoid using implict format string, it's dangerous from security p.o.v.
>
> What do you mean by implicit format string?

When I read the above code I feel uncomfortable because no-one can see
(without additional action and more reading and checking) if it's
correct or not. This is potential to be error prone.

> The format string is at the
> top of the file and its length is right next to it, which makes it
> harder for them to accidentally fall out of sync.

It is not an argument. Just you may do the same in the code directly
and more explicitly:

Also you don't check the return code of snprintf which means that you
don't care about the result, which seems to me wrong approach. If you
don't care about the result, so it means it's not very important,
right?

> +#define BRCMF_FW_MACADDR_FMT                   "macaddr=%pM"
> +#define BRCMF_FW_MACADDR_LEN                   (7 + ETH_ALEN * 3)



-- 
With Best Regards,
Andy Shevchenko

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-05 13:22         ` Hector Martin
@ 2022-01-06 17:40           ` Dmitry Osipenko
  2022-01-06 17:58             ` Andy Shevchenko
  0 siblings, 1 reply; 122+ messages in thread
From: Dmitry Osipenko @ 2022-01-06 17:40 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,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

05.01.2022 16:22, Hector Martin пишет:
> On 05/01/2022 07.09, Dmitry Osipenko wrote:
>> 04.01.2022 11:43, Hector Martin пишет:
>>>>> +static int brcm_alt_fw_paths(const char *path, const char *board_type,
>>>>> +			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])>  {
>>>>>  	char alt_path[BRCMF_FW_NAME_LEN];
>>>>>  	const char *suffix;
>>>>>  
>>>>> +	memset(alt_paths, 0, array_size(sizeof(*alt_paths),
>>>>> +					BRCMF_FW_MAX_ALT_PATHS));
>>>> You don't need to use array_size() since size of a fixed array is
>>>> already known.
>>>>
>>>> memset(alt_paths, 0, sizeof(alt_paths));
>>> It's a function argument, so that doesn't work and actually throws a
>>> warning. Array function argument notation is informative only; they
>>> behave strictly equivalent to pointers. Try it:
>>>
>>> $ cat test.c
>>> #include <stdio.h>
>>>
>>> void foo(char x[42])
>>> {
>>> 	printf("%ld\n", sizeof(x));
>>> }
>>>
>>> int main() {
>>> 	char x[42];
>>>
>>> 	foo(x);
>>> }
>>> $ gcc test.c
>>> test.c: In function ‘foo’:
>>> test.c:5:31: warning: ‘sizeof’ on array function parameter ‘x’ will
>>> return size of ‘char *’ [-Wsizeof-array-argument]
>>>     5 |         printf("%ld\n", sizeof(x));
>>>       |                               ^
>>> test.c:3:15: note: declared here
>>>     3 | void foo(char x[42])
>>>       |          ~~~~~^~~~~
>>> $ ./a.out
>>> 8
>>
>> Then please use "const char **alt_paths" for the function argument to
>> make code cleaner and add another argument to pass the number of array
>> elements.
> 
> So you want me to do the ARRAY_SIZE at the caller side then?
> 
>>
>> static int brcm_alt_fw_paths(const char *path, const char *board_type,
>> 			     const char **alt_paths, unsigned int num_paths)
>> {
>> 	size_t alt_paths_size = array_size(sizeof(*alt_paths), num_paths);
>> 	
>> 	memset(alt_paths, 0, alt_paths_size);
>> }
>>
>> ...
>>
>> Maybe even better create a dedicated struct for the alt_paths:
>>
>> struct brcmf_fw_alt_paths {
>> 	const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS];
>> 	unsigned int index;
>> };
>>
>> and then use the ".index" in the brcm_free_alt_fw_paths(). I suppose
>> this will make code a bit nicer and easier to follow.
>>
> 
> I'm confused; the array size is constant. What would index contain and
> why would would brcm_free_alt_fw_paths use it? Just as an iterator
> variable instead of using a local variable? Or do you mean count?

Yes, use index for the count of active entries in the alt_paths[].

for (i = 0; i < alt_paths.index; i++)
	kfree(alt_paths.path[i]);

alt_paths.index = 0;

or

while (alt_paths.index)
	kfree(alt_paths.path[--alt_paths.index]);

> Though, to be honest, at this point I'm considering rethinking the whole
> patch for this mechanism because I'm not terribly happy with the current
> approach and clearly you aren't either :-) Maybe it makes more sense to
> stop trying to compute all the alt_paths ahead of time, and just have
> the function compute a single one to be used just-in-time at firmware
> request time, and just iterate over board_types.
> 

The just-in-time approach sounds like a good idea.

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-06 17:40           ` Dmitry Osipenko
@ 2022-01-06 17:58             ` Andy Shevchenko
  2022-01-07  3:12               ` Dmitry Osipenko
  0 siblings, 1 reply; 122+ messages in thread
From: Andy Shevchenko @ 2022-01-06 17:58 UTC (permalink / raw)
  To: Dmitry Osipenko
  Cc: 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,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On Thu, Jan 6, 2022 at 7:40 PM Dmitry Osipenko <digetx@gmail.com> wrote:
> 05.01.2022 16:22, Hector Martin пишет:
> > On 05/01/2022 07.09, Dmitry Osipenko wrote:

...

> > I'm confused; the array size is constant. What would index contain and
> > why would would brcm_free_alt_fw_paths use it? Just as an iterator
> > variable instead of using a local variable? Or do you mean count?
>
> Yes, use index for the count of active entries in the alt_paths[].
>
> for (i = 0; i < alt_paths.index; i++)
>         kfree(alt_paths.path[i]);
>
> alt_paths.index = 0;
>
> or
>
> while (alt_paths.index)
>         kfree(alt_paths.path[--alt_paths.index]);

Usual pattern is

  while (x--)
    kfree(x);

easier to read, extend (if needed).

-- 
With Best Regards,
Andy Shevchenko

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

* Re: [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr
  2022-01-06 14:20       ` Andy Shevchenko
@ 2022-01-07  2:39         ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-07  2:39 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On 2022/01/06 23:20, Andy Shevchenko wrote:
> On Wed, Jan 5, 2022 at 3:26 PM Hector Martin <marcan@marcan.st> wrote:
>> On 04/01/2022 23.23, Andy Shevchenko wrote:
>>> On Tue, Jan 4, 2022 at 9:29 AM Hector Martin <marcan@marcan.st> wrote:
> 
> ...
> 
>>>> +#define BRCMF_FW_MACADDR_FMT                   "macaddr=%pM"
> 
>>>> +       snprintf(&nvp->nvram[nvp->nvram_len], BRCMF_FW_MACADDR_LEN + 1,
>>>> +                BRCMF_FW_MACADDR_FMT, mac);
>>>
>>> Please, avoid using implict format string, it's dangerous from security p.o.v.
>>
>> What do you mean by implicit format string?
> 
> When I read the above code I feel uncomfortable because no-one can see
> (without additional action and more reading and checking) if it's
> correct or not. This is potential to be error prone.
> 
>> The format string is at the
>> top of the file and its length is right next to it, which makes it
>> harder for them to accidentally fall out of sync.
> 
> It is not an argument. Just you may do the same in the code directly
> and more explicitly:

The point is that BRCMF_FW_MACADDR_LEN and BRCMF_FW_MACADDR_FMT need to
be in sync, and BRCMF_FW_MACADDR_LEN is used in two different places. If
I inline the format string into the code, someone could change it
without changing the length, or changing the length inline only next to
the format string. Then we overflow the NVRAM buffer because the
allocation is not sized properly.

By having them as defines, it is obvious that they go together, and if
one changes the other one has to change too, and the nvram allocation
can't end up improperly sized as long as they are kept in sync.

> Also you don't check the return code of snprintf which means that you
> don't care about the result, which seems to me wrong approach. If you
> don't care about the result, so it means it's not very important,
> right?
> 

That snprintf can never fail as long as the format string/length are in
sync. I'll make it BUG_ON(... != size), so it complains loudly if
someone screws up the format string in the future.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types
  2022-01-04 11:28   ` Andy Shevchenko
@ 2022-01-07  2:50     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-07  2:50 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On 2022/01/04 20:28, Andy Shevchenko wrote:
> On Tue, Jan 4, 2022 at 9:28 AM 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.
> 
>> +               /* strip extension at the end */
>> +               strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
>> +               alt_path[suffix - path] = 0;
>>
>> -       alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
>> +               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[i] = kstrdup(alt_path, GFP_KERNEL);
>> +               brcmf_dbg(TRACE, "FW alt path: %s\n", alt_paths[i]);
> 
> Consider replacing these string manipulations with kasprintf().
> 

Done, thanks!

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-06 17:58             ` Andy Shevchenko
@ 2022-01-07  3:12               ` Dmitry Osipenko
  2022-01-07  9:55                 ` Andy Shevchenko
  0 siblings, 1 reply; 122+ messages in thread
From: Dmitry Osipenko @ 2022-01-07  3:12 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: 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,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

06.01.2022 20:58, Andy Shevchenko пишет:
> On Thu, Jan 6, 2022 at 7:40 PM Dmitry Osipenko <digetx@gmail.com> wrote:
>> 05.01.2022 16:22, Hector Martin пишет:
>>> On 05/01/2022 07.09, Dmitry Osipenko wrote:
> 
> ...
> 
>>> I'm confused; the array size is constant. What would index contain and
>>> why would would brcm_free_alt_fw_paths use it? Just as an iterator
>>> variable instead of using a local variable? Or do you mean count?
>>
>> Yes, use index for the count of active entries in the alt_paths[].
>>
>> for (i = 0; i < alt_paths.index; i++)
>>         kfree(alt_paths.path[i]);
>>
>> alt_paths.index = 0;
>>
>> or
>>
>> while (alt_paths.index)
>>         kfree(alt_paths.path[--alt_paths.index]);
> 
> Usual pattern is
> 
>   while (x--)
>     kfree(x);
> 
> easier to read, extend (if needed).
> 

That is indeed a usual patter for the driver removal code paths. I
didn't like to have index of struct brcmf_fw underflowed, but I see now
that fwctx is dynamically created and freed during driver probe, so it
should be fine to use that usual pattern here too.

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

* Re: [PATCH v2 07/35] brcmfmac: pcie: Read Apple OTP information
  2022-01-04 11:26   ` Andy Shevchenko
@ 2022-01-07  3:53     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-07  3:53 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On 2022/01/04 20:26, Andy Shevchenko wrote:
> On Tue, Jan 4, 2022 at 9:28 AM 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.
> 
> ...
> 
>> +static int
>> +brcmf_pcie_parse_otp_sys_vendor(struct brcmf_pciedev_info *devinfo,
>> +                               u8 *data, size_t size)
>> +{
>> +       int idx = 4;
> 
> Can you rather have a structure
> 
> struct my_cool_and_strange_blob {
> __le32 hdr;
> const char ...[];
> ...
> }
> 
> and then cast your data to this struct?

That would mean I need to copy, since the original data is not aligned.
Since it's just one u32 header (which we don't even truly know the
interpretation of), it seems get_unaligned_le32 is easier.

> 
>> +       const char *chip_params;
>> +       const char *board_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;
> 
> strsep() ?

We're splitting on \0 here, so that won't work.

> 
>> +       if (idx >= size)
>> +               return -EINVAL;
>> +
>> +       board_params = &data[idx];
>> +
>> +       /* Skip to terminator of second string */
>> +       idx += strnlen(board_params, size - idx);
>> +       if (idx >= size)
>> +               return -EINVAL;
>> +
>> +       /* At this point both strings are guaranteed NUL-terminated */
>> +       brcmf_dbg(PCIE, "OTP: chip_params='%s' board_params='%s'\n",
>> +                 chip_params, board_params);
>> +
>> +       p = board_params;
>> +       while (*p) {
>> +               char tag = *p++;
>> +               const char *end;
>> +               size_t len;
>> +
>> +               if (tag == ' ') /* Skip extra spaces */
>> +                       continue;
> 
> skip_spaces()

Sure.

> 
>> +
>> +               if (*p++ != '=') /* implicit NUL check */
>> +                       return -EINVAL;
> 
> Have you checked the next_arg() implementation?

That function has a lot more logic (handling quotes, etc) and no other
hardware drivers use it. I'm not sure I feel comfortable using it to
parse untrusted data from a potentially compromised device. The parsing
we need to do here is much simpler.

> 
>> +               /* *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;
> 
> Use proper error codes.

Ack.

> 
>> +       brcmf_dbg(PCIE, "parse_otp size=%ld\n", size);
>> +
>> +       while (p < (size - 1)) {
> 
> too many parentheses

Really? I see this is all over kernel code. I know it's redundant, but I
find parentheses around expressions used for one side of a comparison to
be a lot more readable since you don't have to start doubting whether
that particular operator has higher precedence than the comparison (+
does but & does not).

> 
>> +               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",
> 
> length as hex a bit harder to parse

Not so sure about that, especially if you're trying to mentally add it
to offsets... but sure, I can make it decimal.

> 
>> +                                 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;
> 
> 
> length + 2 is easier to read.

I was following the data order here; 2 header bytes and then length
payload bytes. Same reason I used p + 2 + length above.

> 
>> +       }
>> +
>> +       return ret;
>> +}
> 
> ...
> 
>> +               /* Map OTP to shadow area */
>> +               WRITECC32(devinfo, sromcontrol,
>> +                         sromctl | BCMA_CC_SROM_CONTROL_OTPSEL);
> 
> One line?

That exceeds 80 chars, which seems to be the standard in this file which
I'm trying to stick to. If people are okay with pushing to 100 lines,
there are lots of other places I could unwrap lines in this series.

> 
> ...
> 
>> +       otp = kzalloc(sizeof(u16) * words, GFP_KERNEL);
> 
> No check, why? I see in many places you forgot to check for NULL from
> allocator functions.

I think at some point something convinced me that kzalloc and friends
don't fail with GFP_KERNEL... which they rarely do, but they do. I'll
fix it, and add a few missing checks to the existing code while I'm at it.

> Moreover here you should use kzalloc() which does overflow protection.
words is a constant from the switch statement so this could never
overflow anyway, but sure.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 08/35] brcmfmac: of: Fetch Apple properties
  2022-01-04 11:17   ` Andy Shevchenko
@ 2022-01-07  3:54     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-07  3:54 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, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On 2022/01/04 20:17, Andy Shevchenko wrote:
> On Tue, Jan 4, 2022 at 9:28 AM 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.
>> We map Apple's module codenames to board_types in the form
>> "apple,<module-instance>".
>>
>> The mapped board_type is added to the DTS file in that form, while the
>> antenna-sku is forwarded by our bootloader from the Apple Device Tree
>> into the FDT. Grab them from the DT so firmware selection can use
>> them.
> 
>> +       /* 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, "brcm,board-type", &prop))
>> +               settings->board_type = devm_kstrdup(dev, prop, GFP_KERNEL);
>> +
>> +       if (!of_property_read_string(np, "apple,antenna-sku", &prop))
>> +               settings->antenna_sku = devm_kstrdup(dev, prop, GFP_KERNEL);
> 
> No error checks?
> But hold on, why do you need to copy them? Are you expecting this to be in DTO?

Yeah, I was wondering about that... indeed it shouldn't be necessary to
copy them.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types
  2022-01-06 12:16   ` Arend van Spriel
@ 2022-01-07  4:02     ` Hector Martin
  2022-01-07  6:17       ` Arend Van Spriel
  0 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-07  4:02 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/06 21:16, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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.
> 
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> 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        |  4 ++-
>>   .../broadcom/brcm80211/brcmfmac/sdio.c        |  2 +-
>>   4 files changed, 27 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>> index 7570dbf22cdd..054ea3ed133e 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>> @@ -594,28 +594,39 @@ static int brcmf_fw_complete_request(const struct firmware *fw,
>>   	return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
>>   }
>>   
>> -static int brcm_alt_fw_paths(const char *path, const char *board_type,
>> +static int brcm_alt_fw_paths(const char *path, struct brcmf_fw *fwctx,
>>   			     const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
>>   {
>> +	const char **board_types = fwctx->req->board_types;
>> +	unsigned int i;
>>   	char alt_path[BRCMF_FW_NAME_LEN];
>>   	const char *suffix;
> 
> [...]
> 
>> +	for (i = 0; i < BRCMF_FW_MAX_ALT_PATHS; i++) {
>> +		if (!board_types[i])
>> +		    break;
>>   
>> -	strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);
>> -	strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
>> -	strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
>> +		/* strip extension at the end */
>> +		strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
>> +		alt_path[suffix - path] = 0;
>>   
>> -	alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
>> +		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[i] = kstrdup(alt_path, GFP_KERNEL);
>> +		brcmf_dbg(TRACE, "FW alt path: %s\n", alt_paths[i]);
> 
> Could use alt_path in the debug print thus avoiding additional array 
> access (working hard to find those nits to pick ;-) ).
> 

So you're saying my code is so good you have to resort to nits on this
level to make it clear you read it, right? ;-)

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types
  2022-01-07  4:02     ` Hector Martin
@ 2022-01-07  6:17       ` Arend Van Spriel
  2022-01-07  7:12         ` Hector Martin
  0 siblings, 1 reply; 122+ messages in thread
From: Arend Van Spriel @ 2022-01-07  6:17 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On January 7, 2022 5:02:13 AM Hector Martin <marcan@marcan.st> wrote:

> On 2022/01/06 21:16, Arend van Spriel wrote:
>> On 1/4/2022 8:26 AM, Hector Martin 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.
>>
>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>> 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        |  4 ++-
>>> .../broadcom/brcm80211/brcmfmac/sdio.c        |  2 +-
>>> 4 files changed, 27 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>>> index 7570dbf22cdd..054ea3ed133e 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>>> @@ -594,28 +594,39 @@ static int brcmf_fw_complete_request(const struct 
>>> firmware *fw,
>>> return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
>>> }
>>>
>>> -static int brcm_alt_fw_paths(const char *path, const char *board_type,
>>> +static int brcm_alt_fw_paths(const char *path, struct brcmf_fw *fwctx,
>>>   const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
>>> {
>>> + const char **board_types = fwctx->req->board_types;
>>> + unsigned int i;
>>> char alt_path[BRCMF_FW_NAME_LEN];
>>> const char *suffix;
>>
>> [...]
>>
>>> + for (i = 0; i < BRCMF_FW_MAX_ALT_PATHS; i++) {
>>> + if (!board_types[i])
>>> +    break;
>>>
>>> - strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);
>>> - strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
>>> - strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
>>> + /* strip extension at the end */
>>> + strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
>>> + alt_path[suffix - path] = 0;
>>>
>>> - alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
>>> + 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[i] = kstrdup(alt_path, GFP_KERNEL);
>>> + brcmf_dbg(TRACE, "FW alt path: %s\n", alt_paths[i]);
>>
>> Could use alt_path in the debug print thus avoiding additional array
>> access (working hard to find those nits to pick ;-) ).
>
> So you're saying my code is so good you have to resort to nits on this
> level to make it clear you read it, right? ;-)

Don't read too much into this :-p Actually never liked the alt_path 
approach, but didn't come up with a better solution.

Regards,
Arend




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

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

* Re: [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types
  2022-01-07  6:17       ` Arend Van Spriel
@ 2022-01-07  7:12         ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-07  7:12 UTC (permalink / raw)
  To: Arend Van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/07 15:17, Arend Van Spriel wrote:
> On January 7, 2022 5:02:13 AM Hector Martin <marcan@marcan.st> wrote:
> 
>> On 2022/01/06 21:16, Arend van Spriel wrote:
>>> On 1/4/2022 8:26 AM, Hector Martin 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.
>>>
>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>>> 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        |  4 ++-
>>>> .../broadcom/brcm80211/brcmfmac/sdio.c        |  2 +-
>>>> 4 files changed, 27 insertions(+), 16 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
>>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>>>> index 7570dbf22cdd..054ea3ed133e 100644
>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>>>> @@ -594,28 +594,39 @@ static int brcmf_fw_complete_request(const struct 
>>>> firmware *fw,
>>>> return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
>>>> }
>>>>
>>>> -static int brcm_alt_fw_paths(const char *path, const char *board_type,
>>>> +static int brcm_alt_fw_paths(const char *path, struct brcmf_fw *fwctx,
>>>>   const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])
>>>> {
>>>> + const char **board_types = fwctx->req->board_types;
>>>> + unsigned int i;
>>>> char alt_path[BRCMF_FW_NAME_LEN];
>>>> const char *suffix;
>>>
>>> [...]
>>>
>>>> + for (i = 0; i < BRCMF_FW_MAX_ALT_PATHS; i++) {
>>>> + if (!board_types[i])
>>>> +    break;
>>>>
>>>> - strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);
>>>> - strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN);
>>>> - strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN);
>>>> + /* strip extension at the end */
>>>> + strscpy(alt_path, path, BRCMF_FW_NAME_LEN);
>>>> + alt_path[suffix - path] = 0;
>>>>
>>>> - alt_paths[0] = kstrdup(alt_path, GFP_KERNEL);
>>>> + 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[i] = kstrdup(alt_path, GFP_KERNEL);
>>>> + brcmf_dbg(TRACE, "FW alt path: %s\n", alt_paths[i]);
>>>
>>> Could use alt_path in the debug print thus avoiding additional array
>>> access (working hard to find those nits to pick ;-) ).
>>
>> So you're saying my code is so good you have to resort to nits on this
>> level to make it clear you read it, right? ;-)
> 
> Don't read too much into this :-p Actually never liked the alt_path 
> approach, but didn't come up with a better solution.

Yeah, it's not the prettiest approach. I redid this part of the patchset
for v3 though, as I mentioned to Dmitry. Now I just iterate over
board_types, which ends up being a lot cleaner as far as the changes
required.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
  2022-01-07  3:12               ` Dmitry Osipenko
@ 2022-01-07  9:55                 ` Andy Shevchenko
  0 siblings, 0 replies; 122+ messages in thread
From: Andy Shevchenko @ 2022-01-07  9:55 UTC (permalink / raw)
  To: Dmitry Osipenko
  Cc: 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,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

On Fri, Jan 7, 2022 at 5:12 AM Dmitry Osipenko <digetx@gmail.com> wrote:
> 06.01.2022 20:58, Andy Shevchenko пишет:
> > On Thu, Jan 6, 2022 at 7:40 PM Dmitry Osipenko <digetx@gmail.com> wrote:
> >> 05.01.2022 16:22, Hector Martin пишет:

...

> >> while (alt_paths.index)
> >>         kfree(alt_paths.path[--alt_paths.index]);
> >
> > Usual pattern is
> >
> >   while (x--)
> >     kfree(x);

I have to elaborate that my point is to have postdecrement in the
while() instead of doing predecrement in its body. So the above
example will look

  while (alt_paths.index--)
    kfree(alt_paths.path[alt_paths.index]);

> > easier to read, extend (if needed).
>
> That is indeed a usual patter for the driver removal code paths. I
> didn't like to have index of struct brcmf_fw underflowed, but I see now
> that fwctx is dynamically created and freed during driver probe, so it
> should be fine to use that usual pattern here too.



-- 
With Best Regards,
Andy Shevchenko

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

* Re: [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms
  2022-01-04  7:26 ` [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
  2022-01-04 14:24   ` Andy Shevchenko
@ 2022-01-08 20:03   ` Arend van Spriel
  2022-01-17  6:36     ` Hector Martin
  1 sibling, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-08 20:03 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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 ACPI (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.
> 
> 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.

Not sure I understand this. The chip revision comes from the chipcommon 
register [1]. Maybe that is what you mean by "PCI revision number". For 
some chips it is possible OTP is used to override that.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   .../broadcom/brcm80211/brcmfmac/pcie.c        | 58 ++++++++++++++++++-
>   1 file changed, 56 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 74c9a4f74813..250e0bd40cb3 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -2094,8 +2094,62 @@ 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[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);

maybe good to use local reference for devinfo->settings->board_type, 
which is used several times below.

> +
> +		/* 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);
> +
> +		/* apple,shikoku */
> +		fwreq->board_types[5] = devinfo->settings->board_type;

[1] 
https://elixir.bootlin.com/linux/latest/source/include/linux/bcma/bcma_driver_chipcommon.h#L12

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

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

* Re: [PATCH v2 08/35] brcmfmac: of: Fetch Apple properties
  2022-01-04  7:26 ` [PATCH v2 08/35] brcmfmac: of: Fetch Apple properties Hector Martin
  2022-01-04 11:17   ` Andy Shevchenko
@ 2022-01-08 20:03   ` Arend van Spriel
  1 sibling, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-08 20:03 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.
> We map Apple's module codenames to board_types in the form
> "apple,<module-instance>".
> 
> The mapped board_type is added to the DTS file in that form, while the
> antenna-sku is forwarded by our bootloader from the Apple Device Tree
> into the FDT. Grab them from the DT so firmware selection can use
> them.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   .../wireless/broadcom/brcm80211/brcmfmac/common.h    |  1 +
>   .../net/wireless/broadcom/brcm80211/brcmfmac/of.c    | 12 +++++++++++-
>   2 files changed, 12 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..085d34176b78 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> @@ -63,14 +63,24 @@ 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, "brcm,board-type", &prop))
> +		settings->board_type = devm_kstrdup(dev, prop, GFP_KERNEL);
> +
> +	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("/");

I assume this only returns NULL when there is no device tree. Is that a 
safe assumption (Rob)? If so you could bail out here if root is NULL...

> -	if (root) {
> +	if (root && !settings->board_type) {

...and only check the board_type here. Or only check board_type and 
lookup the root node inside this if-statement if it is not needed 
elsewhere in this probe function.

>   		int i, len;
>   		char *board_type;
>   		const char *tmp;

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

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

* Re: [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr
  2022-01-04  7:26 ` [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
  2022-01-04 14:23   ` Andy Shevchenko
@ 2022-01-08 20:14   ` Arend van Spriel
  2022-01-17  6:38     ` Hector Martin
  1 sibling, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-08 20:14 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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).

What overrides what. Can you elaborate a bit?

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   .../broadcom/brcm80211/brcmfmac/firmware.c    | 29 +++++++++++++++++--
>   1 file changed, 27 insertions(+), 2 deletions(-)

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

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

* Re: [PATCH v2 11/35] brcmfmac: msgbuf: Increase RX ring sizes to 1024
  2022-01-04  7:26 ` [PATCH v2 11/35] brcmfmac: msgbuf: Increase RX ring sizes to 1024 Hector Martin
@ 2022-01-10  7:17   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10  7:17 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin wrote:
> Newer chips used on Apple platforms have a max_rxbufpost greater than
> 512, which causes warnings when brcmf_msgbuf_rxbuf_data_fill tries to
> put more entries in the ring than will fit. Increase the ring sizes
> to 1024.

Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)

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

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

* Re: [PATCH v2 12/35] brcmfmac: pcie: Fix crashes due to early IRQs
  2022-01-04  7:26 ` [PATCH v2 12/35] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
  2022-01-04 14:12   ` Andy Shevchenko
@ 2022-01-10  7:19   ` Arend van Spriel
  1 sibling, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10  7:19 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.")
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   .../wireless/broadcom/brcm80211/brcmfmac/pcie.c  | 16 +++++++++++++---
>   1 file changed, 13 insertions(+), 3 deletions(-)

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

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

* Re: [PATCH v2 13/35] brcmfmac: pcie: Support PCIe core revisions >= 64
  2022-01-04  7:26 ` [PATCH v2 13/35] brcmfmac: pcie: Support PCIe core revisions >= 64 Hector Martin
@ 2022-01-10  7:31   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10  7:31 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 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 595815164e18..f3744e806157 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

Just an observation. So these are legacy ones with a 16 bit right shift...

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

...and these are new doorbell interrupts.

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

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

* Re: [PATCH v2 14/35] brcmfmac: pcie: Add IDs/properties for BCM4378
  2022-01-04  7:26 ` [PATCH v2 14/35] brcmfmac: pcie: Add IDs/properties for BCM4378 Hector Martin
@ 2022-01-10  9:10   ` Arend van Spriel
  2022-01-10 11:04     ` Hector Martin
  0 siblings, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10  9:10 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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)

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 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/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index f3744e806157..cc76f00724e6 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 */

what does the trailing comment reflect?

>   };
>   
>   #define BRCMF_PCIE_FW_UP_TIMEOUT		5000 /* msec */

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

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

* Re: [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties
  2022-01-04  7:26 ` [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
  2022-01-04 10:21   ` Arend van Spriel
@ 2022-01-10  9:11   ` Arend van Spriel
  2022-01-10 11:07     ` Hector Martin
  1 sibling, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10  9: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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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        | 47 +++++++++++++++++++
>   .../broadcom/brcm80211/brcmfmac/common.c      |  1 +
>   .../broadcom/brcm80211/brcmfmac/common.h      |  9 ++++
>   4 files changed, 59 insertions(+)
>   create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c

[...]

> 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..2b1a4448b291
> --- /dev/null
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
> @@ -0,0 +1,47 @@
> +// 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;
> +	const union acpi_object *o;
> +	struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL};
> +	struct acpi_device *adev = ACPI_COMPANION(dev);
> +
> +	if (!adev)
> +		return;
> +
> +	if (!ACPI_FAILURE(acpi_dev_get_property(adev, "module-instance",
> +						ACPI_TYPE_STRING, &o))) {
> +		brcmf_dbg(INFO, "ACPI module-instance=%s\n", o->string.pointer);
> +		settings->board_type = devm_kasprintf(dev, GFP_KERNEL,
> +						      "apple,%s",
> +						      o->string.pointer);
> +	} else {
> +		brcmf_dbg(INFO, "No ACPI module-instance\n");

Do you need to obtain the antenna-sku when there is no module-instance?

> +	}
> +
> +	status = acpi_evaluate_object(adev->handle, "RWCV", NULL, &buf);

Can you clarify what the above does? What does the "RWCV" mean?

> +	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");
> +	}
> +}

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

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

* Re: [PATCH v2 17/35] brcmfmac: pcie: Provide a buffer of random bytes to the device
  2022-01-04  7:26 ` [PATCH v2 17/35] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
@ 2022-01-10  9:11   ` Arend van Spriel
  2022-01-10 11:09     ` Hector Martin
  0 siblings, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10  9: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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Not sure what the general opinion is here, but pulling random bytes for 
naught seems wasteful to me. So if there is a way of knowing it is 
needed please make it conditional.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   .../broadcom/brcm80211/brcmfmac/pcie.c        | 30 +++++++++++++++++++
>   1 file changed, 30 insertions(+)

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

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

* Re: [PATCH v2 18/35] brcmfmac: pcie: Add IDs/properties for BCM4355
  2022-01-04  7:26 ` [PATCH v2 18/35] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
@ 2022-01-10  9:12   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10  9: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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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)

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 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/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index a8cccfbea20b..fdba2b5b46f0 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 */

still intrigued what that trailing number means ;-)

>   	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),

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

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

* Re: [PATCH v2 19/35] brcmfmac: pcie: Add IDs/properties for BCM4377
  2022-01-04  7:26 ` [PATCH v2 19/35] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
@ 2022-01-10  9:12   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10  9: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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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)

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 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(+)

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

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

* Re: [PATCH v2 20/35] brcmfmac: pcie: Perform correct BCM4364 firmware selection
  2022-01-04  7:26 ` [PATCH v2 20/35] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin
@ 2022-01-10  9:12   ` Arend van Spriel
  2022-01-10 11:20     ` Hector Martin
  0 siblings, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10  9: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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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")
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 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 87daabb15cd0..e4f2aff3c0d5 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");

would this break things for people. Maybe better to keep the old name 
for the B2 variant.

>   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 */

okay. so it is the numerical chip revision. If so, please drop that comment.

>   	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),

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

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

* Re: [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms
  2022-01-04  7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
                   ` (35 preceding siblings ...)
  2022-01-04 14:28 ` [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Andy Shevchenko
@ 2022-01-10 10:14 ` Kalle Valo
  2022-01-10 11:21   ` Hector Martin
  36 siblings, 1 reply; 122+ messages in thread
From: Kalle Valo @ 2022-01-10 10:14 UTC (permalink / raw)
  To: Hector Martin
  Cc: David S. Miller, Jakub Kicinski, Rob Herring, Rafael J. Wysocki,
	Len Brown, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-hsien Lin, Wright Feng, Dmitry Osipenko, Sven Peter,
	Alyssa Rosenzweig, Mark Kettenis, Rafał Miłecki,
	Pieter-Paul Giesberts, Linus Walleij, Hans de Goede,
	John W. Linville, brian m. carlson, Andy Shevchenko,
	linux-wireless, netdev, devicetree, linux-kernel, linux-acpi,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list

Hector Martin <marcan@marcan.st> writes:

> Hi everyone,
>
> Happy new year! This 35-patch series adds proper support for the
> Broadcom FullMAC chips used on Apple T2 and M1 platforms:
>
> - BCM4355C1
> - BCM4364B2/B3
> - BCM4377B3
> - BCM4378B1
> - BCM4387C2

35 patches is a lot to review. It would make things easier for reviewers
if you can split this into smaller patchsets, 10-12 patches per set is
what I usually recommend. More info in the wiki link below.

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

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

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

* Re: [PATCH v2 14/35] brcmfmac: pcie: Add IDs/properties for BCM4378
  2022-01-10  9:10   ` Arend van Spriel
@ 2022-01-10 11:04     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-10 11:04 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/10 18:10, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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)
> 
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> 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/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> index f3744e806157..cc76f00724e6 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 */
> 
> what does the trailing comment reflect?

PCI revision IDs seen in the wild. The mask currently accepts all of
them, but B1 specifically seems to map to rev3. This is important for
4364 since there are two revisions in the wild, and so that one has more
selective masks. I can change it to "rev3" to make it more obvious.

I'm actually not sure what the best approach for the masks is. We could
also only accept known exact revisions; that would be better if a newer
revision is incompatible, but worse if it is and would otherwise just work.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties
  2022-01-10  9:11   ` Arend van Spriel
@ 2022-01-10 11:07     ` Hector Martin
  2022-01-10 11:26       ` Arend van Spriel
  0 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-10 11:07 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/10 18:11, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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        | 47 +++++++++++++++++++
>>   .../broadcom/brcm80211/brcmfmac/common.c      |  1 +
>>   .../broadcom/brcm80211/brcmfmac/common.h      |  9 ++++
>>   4 files changed, 59 insertions(+)
>>   create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
> 
> [...]
> 
>> 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..2b1a4448b291
>> --- /dev/null
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
>> @@ -0,0 +1,47 @@
>> +// 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;
>> +	const union acpi_object *o;
>> +	struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL};
>> +	struct acpi_device *adev = ACPI_COMPANION(dev);
>> +
>> +	if (!adev)
>> +		return;
>> +
>> +	if (!ACPI_FAILURE(acpi_dev_get_property(adev, "module-instance",
>> +						ACPI_TYPE_STRING, &o))) {
>> +		brcmf_dbg(INFO, "ACPI module-instance=%s\n", o->string.pointer);
>> +		settings->board_type = devm_kasprintf(dev, GFP_KERNEL,
>> +						      "apple,%s",
>> +						      o->string.pointer);
>> +	} else {
>> +		brcmf_dbg(INFO, "No ACPI module-instance\n");
> 
> Do you need to obtain the antenna-sku when there is no module-instance?

In principle I don't think any machines would have antenna-sku and no
module-instance, though the firmware selection will still work without
it (it'll just end up using the DMI machine name instead).

> 
>> +	}
>> +
>> +	status = acpi_evaluate_object(adev->handle, "RWCV", NULL, &buf);
> 
> Can you clarify what the above does? What does the "RWCV" mean?

No idea what it *means* :-)

What it is, though, is the ACPI method name to get the antenna-sku.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 17/35] brcmfmac: pcie: Provide a buffer of random bytes to the device
  2022-01-10  9:11   ` Arend van Spriel
@ 2022-01-10 11:09     ` Hector Martin
  2022-01-10 11:28       ` Arend van Spriel
  0 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-10 11:09 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/10 18:11, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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.
> 
> Not sure what the general opinion is here, but pulling random bytes for 
> naught seems wasteful to me. So if there is a way of knowing it is 
> needed please make it conditional.

We could gate it on specific chips only, if you don't mind maintaining a
list of those. AIUI that would be all the T2 platform chips or so (the
newer two don't seem to need it).

Alternatively we could just do this only if an Apple OTP is detected.
That is already implicitly gated by the OTP offset chip list.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 20/35] brcmfmac: pcie: Perform correct BCM4364 firmware selection
  2022-01-10  9:12   ` Arend van Spriel
@ 2022-01-10 11:20     ` Hector Martin
  2022-01-10 12:02       ` Arend van Spriel
  0 siblings, 1 reply; 122+ messages in thread
From: Hector Martin @ 2022-01-10 11:20 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 2022/01/10 18:12, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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")
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> 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 87daabb15cd0..e4f2aff3c0d5 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");
> 
> would this break things for people. Maybe better to keep the old name 
> for the B2 variant.

Or the B3 variant... people have been using random copied firmwares with
the same name, I guess. Probably even the wrong NVRAMs in some cases.
And then I'd have to add a special case to the firmware extraction
script to rename one of these two to not include the revision...

Plus, newer firmwares require the random blob, so this only ever worked
with old, obsolete firmwares... which I think have security
vulnerabilities (there was an AWDL exploit recently IIRC).

Honestly though, there are probably rather few people using upstream
kernels on T2s. Certainly on the MacBooks, since the keyboard/touchpad
aren't supported upstream yet... plus given that there was never any
"official" firmware distributed under the revision-less name, none of
this would work out of the box with upstream kernels anyway.

FWIW, I've been in contact with the t2linux folks and users have been
testing this patchset (that's how I got it tested on all the chips), so
at least some people are already aware of the story and how to get the
firmware named properly :-)

>> -	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 */
> 
> okay. so it is the numerical chip revision. If so, please drop that comment.
> 

I figured it would be useful to document this somewhere, since the
alphanumeric code -> rev number mapping doesn't seem to be consistent
from chip to chip, and we might have to add a new revision in the future
for an existing chip (which would require knowing the rev for the old
one). Do you have any ideas?

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

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

On 2022/01/10 19:14, Kalle Valo wrote:
> Hector Martin <marcan@marcan.st> writes:
> 
>> Hi everyone,
>>
>> Happy new year! This 35-patch series adds proper support for the
>> Broadcom FullMAC chips used on Apple T2 and M1 platforms:
>>
>> - BCM4355C1
>> - BCM4364B2/B3
>> - BCM4377B3
>> - BCM4378B1
>> - BCM4387C2
> 
> 35 patches is a lot to review. It would make things easier for reviewers
> if you can split this into smaller patchsets, 10-12 patches per set is
> what I usually recommend. More info in the wiki link below.

The patches are already split into logical groupings, so I think there
isn't much more to be gained by sending them separately. As I described
in the cover letter:

01~09: Firmware selection stuff
10~14: Add support for BCM4378
15~20: Add BCM4355/4364/4377 on top
21~27: Add BCM4387 and its newer requirements
28~32: Misc fixes
33~35: TxCap & calibration support

If you want to review the series piecemeal, feel free to stop at any of
those boundaries; the series will still make sense and is useful at any
of those stopping points.

Note that the firmware selection stuff (in particular patches #4 and #6)
will change quite a bit in v3 from the review feedback so far, so you
might want to skip reviewing those in detail for v2.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties
  2022-01-10 11:07     ` Hector Martin
@ 2022-01-10 11:26       ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10 11: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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/10/2022 12:07 PM, Hector Martin wrote:
> On 2022/01/10 18:11, Arend van Spriel wrote:
>> On 1/4/2022 8:26 AM, Hector Martin 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        | 47 +++++++++++++++++++
>>>    .../broadcom/brcm80211/brcmfmac/common.c      |  1 +
>>>    .../broadcom/brcm80211/brcmfmac/common.h      |  9 ++++
>>>    4 files changed, 59 insertions(+)
>>>    create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
>>
>> [...]
>>
>>> 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..2b1a4448b291
>>> --- /dev/null
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
>>> @@ -0,0 +1,47 @@
>>> +// 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;
>>> +	const union acpi_object *o;
>>> +	struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL};
>>> +	struct acpi_device *adev = ACPI_COMPANION(dev);
>>> +
>>> +	if (!adev)
>>> +		return;
>>> +
>>> +	if (!ACPI_FAILURE(acpi_dev_get_property(adev, "module-instance",
>>> +						ACPI_TYPE_STRING, &o))) {
>>> +		brcmf_dbg(INFO, "ACPI module-instance=%s\n", o->string.pointer);
>>> +		settings->board_type = devm_kasprintf(dev, GFP_KERNEL,
>>> +						      "apple,%s",
>>> +						      o->string.pointer);
>>> +	} else {
>>> +		brcmf_dbg(INFO, "No ACPI module-instance\n");
>>
>> Do you need to obtain the antenna-sku when there is no module-instance?
> 
> In principle I don't think any machines would have antenna-sku and no
> module-instance, though the firmware selection will still work without
> it (it'll just end up using the DMI machine name instead).

Right. That was my assumption as well. I would bail out here and skip 
obtaining the antenna-sku.

>>
>>> +	}
>>> +
>>> +	status = acpi_evaluate_object(adev->handle, "RWCV", NULL, &buf);
>>
>> Can you clarify what the above does? What does the "RWCV" mean?
> 
> No idea what it *means* :-)
> 
> What it is, though, is the ACPI method name to get the antenna-sku.

Wow. So much for meaning-full naming ;-)

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

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

* Re: [PATCH v2 17/35] brcmfmac: pcie: Provide a buffer of random bytes to the device
  2022-01-10 11:09     ` Hector Martin
@ 2022-01-10 11:28       ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10 11:28 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/10/2022 12:09 PM, Hector Martin wrote:
> On 2022/01/10 18:11, Arend van Spriel wrote:
>> On 1/4/2022 8:26 AM, Hector Martin 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.
>>
>> Not sure what the general opinion is here, but pulling random bytes for
>> naught seems wasteful to me. So if there is a way of knowing it is
>> needed please make it conditional.
> 
> We could gate it on specific chips only, if you don't mind maintaining a
> list of those. AIUI that would be all the T2 platform chips or so (the
> newer two don't seem to need it).
> 
> Alternatively we could just do this only if an Apple OTP is detected.
> That is already implicitly gated by the OTP offset chip list.

That sounds like a good approach.

Regards,
Arend

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

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

* Re: [PATCH v2 20/35] brcmfmac: pcie: Perform correct BCM4364 firmware selection
  2022-01-10 11:20     ` Hector Martin
@ 2022-01-10 12:02       ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-10 12:02 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/10/2022 12:20 PM, Hector Martin wrote:
> On 2022/01/10 18:12, Arend van Spriel wrote:
>> On 1/4/2022 8:26 AM, Hector Martin 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")
>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>> 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 87daabb15cd0..e4f2aff3c0d5 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");
>>
>> would this break things for people. Maybe better to keep the old name
>> for the B2 variant.
> 
> Or the B3 variant... people have been using random copied firmwares with
> the same name, I guess. Probably even the wrong NVRAMs in some cases.
> And then I'd have to add a special case to the firmware extraction
> script to rename one of these two to not include the revision...
> 
> Plus, newer firmwares require the random blob, so this only ever worked
> with old, obsolete firmwares... which I think have security
> vulnerabilities (there was an AWDL exploit recently IIRC).
> 
> Honestly though, there are probably rather few people using upstream
> kernels on T2s. Certainly on the MacBooks, since the keyboard/touchpad
> aren't supported upstream yet... plus given that there was never any
> "official" firmware distributed under the revision-less name, none of
> this would work out of the box with upstream kernels anyway.
> 
> FWIW, I've been in contact with the t2linux folks and users have been
> testing this patchset (that's how I got it tested on all the chips), so
> at least some people are already aware of the story and how to get the
> firmware named properly :-)

Ok. When there is no brcmfmac4364-pcie.bin in linux-firmware repo we can 
safely rename.

>>> -	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 */
>>
>> okay. so it is the numerical chip revision. If so, please drop that comment.
>>
> 
> I figured it would be useful to document this somewhere, since the
> alphanumeric code -> rev number mapping doesn't seem to be consistent
> from chip to chip, and we might have to add a new revision in the future
> for an existing chip (which would require knowing the rev for the old
> one). Do you have any ideas?

Indeed the alphanumeric code differs from chip to chip depending on how 
much respins are necessary and what type of respin. We start a 'a0' aka 
numeric rev 0. For minor fixes we increase the digit, but for major 
fixes or new functionality we move to the next letter whereas the 
numeric revision simply increases.

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

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

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

Hector Martin <marcan@marcan.st> writes:

> On 2022/01/10 19:14, Kalle Valo wrote:
>> Hector Martin <marcan@marcan.st> writes:
>> 
>>> Hi everyone,
>>>
>>> Happy new year! This 35-patch series adds proper support for the
>>> Broadcom FullMAC chips used on Apple T2 and M1 platforms:
>>>
>>> - BCM4355C1
>>> - BCM4364B2/B3
>>> - BCM4377B3
>>> - BCM4378B1
>>> - BCM4387C2
>> 
>> 35 patches is a lot to review. It would make things easier for reviewers
>> if you can split this into smaller patchsets, 10-12 patches per set is
>> what I usually recommend. More info in the wiki link below.
>
> The patches are already split into logical groupings, so I think there
> isn't much more to be gained by sending them separately. As I described
> in the cover letter:
>
> 01~09: Firmware selection stuff
> 10~14: Add support for BCM4378
> 15~20: Add BCM4355/4364/4377 on top
> 21~27: Add BCM4387 and its newer requirements
> 28~32: Misc fixes
> 33~35: TxCap & calibration support
>
> If you want to review the series piecemeal, feel free to stop at any of
> those boundaries; the series will still make sense and is useful at any
> of those stopping points.

Really, having smaller patchsets makes the patch flow so much smoother
for everyone. If you want to submit huge patchsets then go ahead, but
that will automatically drop the patches to the bottom of my queue.

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

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

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

* Re: [PATCH v2 12/35] brcmfmac: pcie: Fix crashes due to early IRQs
  2022-01-06 13:10     ` Hector Martin
@ 2022-01-10 13:54       ` Kalle Valo
  0 siblings, 0 replies; 122+ messages in thread
From: Kalle Valo @ 2022-01-10 13:54 UTC (permalink / raw)
  To: Hector Martin
  Cc: Andy Shevchenko, David S. Miller, Jakub Kicinski, Rob Herring,
	Rafael J. Wysocki, Len Brown, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Dmitry Osipenko,
	Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	open list:TI WILINK WIRELES...,
	netdev, devicetree, Linux Kernel Mailing List,
	ACPI Devel Maling List,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	SHA-cyfmac-dev-list

Hector Martin <marcan@marcan.st> writes:

> On 04/01/2022 23.12, Andy Shevchenko wrote:
>> On Tue, Jan 4, 2022 at 9:29 AM 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.")
>> 
>> You should gather fixes at the beginning of the series, and even
>> possible to send them as a separate series. In the current state it's
>> unclear if there are dependencies on your new feature (must not be for
>> fixes that meant to be backported).
>> 
>
> Thanks, I wasn't sure what order you wanted those in. I'll put them at
> the top for v3. I think none of those should have any dependencies on
> the rest of the patches, modulo some trivial rebase wrangling.

If there are no dependencies, please send the brcmfmac fixes separately
so that I can apply them earlier.

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

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

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

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

Hector Martin <marcan@marcan.st> writes:

> On 2022/01/04 19:21, Arend van Spriel wrote:
>> On 1/4/2022 8:26 AM, Hector Martin 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        | 47 +++++++++++++++++++
>>>   .../broadcom/brcm80211/brcmfmac/common.c      |  1 +
>>>   .../broadcom/brcm80211/brcmfmac/common.h      |  9 ++++
>>>   4 files changed, 59 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..2b1a4448b291
>>> --- /dev/null
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
>>> @@ -0,0 +1,47 @@
>>> +// SPDX-License-Identifier: ISC
>>> +/*
>>> + * Copyright The Asahi Linux Contributors
>>> + */
>> 
>> Common format for copyright statement (in this folder) seems to be:
>> 
>> Copyright (c) <YEAR> <COPYRIGHT_HOLDER>
>> 
>> Regards,
>> Arend
>
> I get this every time I submit a patch to a new subsystem :-)
>
> This is based on this best practice:
>
> https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/

I didn't know about this recommendation, thanks.

> Basically, the year format quickly becomes outdated and is rather
> useless, and listing specific names also ends up missing every
> subsequent contributor, so more general copyright statements work better
> for this kind of use case. In the end we all know git history is the
> proper record of copyright status.
>
> I don't have a super strong opinion here, but we've been trying to
> standardize on this format for contributions coming from our subproject,
> and it feels more useful than a random contributor's name with a date 5
> years in the past :)

If LF is fine with this approach, then it's good enough also for me. So
at least from my point of view no need to make any changes.

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

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

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

* Re: [PATCH v2 23/35] brcmfmac: cfg80211: Add support for scan params v2
  2022-01-04  7:26 ` [PATCH v2 23/35] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
  2022-01-04 19:46   ` Arend Van Spriel
@ 2022-01-11  8:50   ` Arend van Spriel
  2022-01-17  6:58     ` Hector Martin
  1 sibling, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-11  8:50 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin wrote:
> This new API version is required for at least the BCM4387 firmware. Add
> support for it, with a fallback to the v1 API.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 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);

I am not a fan of function prototypes so if it can be avoided by simply 
moving the function that would be preferred over this.

> +static void brcmf_scan_params_v2_to_v1(struct brcmf_scan_params_v2_le *params_v2_le,
> +				       struct brcmf_scan_params_le *params_le)
> +{

[...]

> +	if (!brcmf_feat_is_enabled(ifp, BRCMF_FEAT_SCAN_V2)) {

Okay. So it is not really a fallback. Phew!

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

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

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

* Re: [PATCH v2 01/35] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
  2022-01-04  7:26 ` [PATCH v2 01/35] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
@ 2022-01-11 18:45   ` Rob Herring
  0 siblings, 0 replies; 122+ messages in thread
From: Rob Herring @ 2022-01-11 18:45 UTC (permalink / raw)
  To: Hector Martin
  Cc: Andy Shevchenko, Wright Feng, Franky Lin, Arend van Spriel,
	Jakub Kicinski, Linus Walleij, Mark Kettenis,
	Pieter-Paul Giesberts, netdev, devicetree, SHA-cyfmac-dev-list,
	Rob Herring, linux-acpi, brian m. carlson, John W. Linville,
	Chi-hsien Lin, linux-kernel, linux-wireless,
	brcm80211-dev-list.pdl, Len Brown, Kalle Valo, David S. Miller,
	Alyssa Rosenzweig, Rafał Miłecki, Hante Meuleman,
	Dmitry Osipenko, Sven Peter, Rafael J. Wysocki, Hans de Goede

On Tue, 04 Jan 2022 16:26:24 +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.
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>  .../net/wireless/brcm,bcm4329-fmac.yaml       | 37 +++++++++++++++++--
>  1 file changed, 34 insertions(+), 3 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

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

* Re: [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms
  2022-01-08 20:03   ` Arend van Spriel
@ 2022-01-17  6:36     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-17  6:36 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 09/01/2022 05.03, Arend van Spriel wrote:
>> 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.
> 
> Not sure I understand this. The chip revision comes from the chipcommon 
> register [1]. Maybe that is what you mean by "PCI revision number". For 
> some chips it is possible OTP is used to override that.

What I mean is the Apple custom OTP segment stores a textual revision
number, like "C0". Apple's driver uses this to pick a firmware. There is
an ad-hoc mapping between this and the numeric revision (which as you
say is present in chipcommon but AFAICT the same number also ends up as
the Revision ID in PCI config space).

> 
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Hector Martin <marcan@marcan.st>
>> ---
>>   .../broadcom/brcm80211/brcmfmac/pcie.c        | 58 ++++++++++++++++++-
>>   1 file changed, 56 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> index 74c9a4f74813..250e0bd40cb3 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> @@ -2094,8 +2094,62 @@ 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[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);
> 
> maybe good to use local reference for devinfo->settings->board_type, 
> which is used several times below.

Yup, and also antenna_sku.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr
  2022-01-08 20:14   ` Arend van Spriel
@ 2022-01-17  6:38     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-17  6:38 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 09/01/2022 05.14, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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).
> 
> What overrides what. Can you elaborate a bit?

The behavior seems to be:

- Use the NVRAM MAC address, if any
- Use the SROM MAC address, if any
- Fail to boot

So a platform with a module containing a MAC address may choose to
override it using the DT mechanism with this patch. This is consistent
with the behavior of other drivers implementing platform MAC support.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 23/35] brcmfmac: cfg80211: Add support for scan params v2
  2022-01-04 19:46   ` Arend Van Spriel
@ 2022-01-17  6:57     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-17  6:57 UTC (permalink / raw)
  To: Arend Van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 05/01/2022 04.46, Arend Van Spriel wrote:
> On January 4, 2022 8:30:51 AM 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.
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> 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(-)
> 
> Compiling this patch with C=2 gives following warnings:
> 
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1086:28: 
> warning: incorrect type in assignment (different base types)
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1086:28: 
> expected restricted __le16 [usertype] version
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1086:28: got int
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1148:38: 
> warning: incorrect type in assignment (different base types)
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1148:38: 
> expected restricted __le32 [usertype] scan_type
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1148:38: got int
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:789:30: 
> warning: incorrect type in assignment (different base types)
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:789:30: 
> expected unsigned char [usertype] scan_type
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:789:30: got 
> restricted __le32 [usertype] scan_type
> 
> Will check if this is a valid warning.

Those are valid bugs (it'd break on big endian platforms), thanks for
checking this. Fixed for v3 :)

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 23/35] brcmfmac: cfg80211: Add support for scan params v2
  2022-01-11  8:50   ` Arend van Spriel
@ 2022-01-17  6:58     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-17  6:58 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 11/01/2022 17.50, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin wrote:
>> This new API version is required for at least the BCM4387 firmware. Add
>> support for it, with a fallback to the v1 API.
> 
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> 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);
> 
> I am not a fan of function prototypes so if it can be avoided by simply 
> moving the function that would be preferred over this.

Moved the function for v3 :)

>> +	if (!brcmf_feat_is_enabled(ifp, BRCMF_FEAT_SCAN_V2)) {
> 
> Okay. So it is not really a fallback. Phew!

I meant fallback in case the feature is not present, not fallback from
trying to use it without checking. Thankfully we can use a feature test
for this :-)


-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 21/35] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number
  2022-01-04  7:26 ` [PATCH v2 21/35] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number Hector Martin
@ 2022-01-19 12:36   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-19 12:36 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Makes sense.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   .../net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 13 ++++++++-----
>   1 file changed, 8 insertions(+), 5 deletions(-)

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

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

* Re: [PATCH v2 22/35] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks
  2022-01-04  7:26 ` [PATCH v2 22/35] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks Hector Martin
@ 2022-01-19 12:36   ` Arend van Spriel
  2022-01-20  8:49     ` Arend van Spriel
  2022-01-31 16:21     ` Hector Martin
  0 siblings, 2 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-19 12:36 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 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)

Not sure why you add ci parameter here. It is not used below or am I 
overlooking something.

>   {
>   	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;

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

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

* Re: [PATCH v2 22/35] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks
  2022-01-19 12:36   ` Arend van Spriel
@ 2022-01-20  8:49     ` Arend van Spriel
  2022-01-31 16:21     ` Hector Martin
  1 sibling, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-20  8:49 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, Wright Feng, Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/19/2022 1:36 PM, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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.

So that is the deal. Wish someone over here told me about that :-p Gave 
my blessing already, but do have some remarks.

> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> 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

Instead of deleting can we leave it here and...

>> +#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)
> 
> Not sure why you add ci parameter here. It is not used below or am I 
> overlooking something.
> 
>>   {
>>       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;

... do following here instead:

		blksize = 8192;
		if (bxinfo & ARMCR4_BLK_1K_MASK)
			blksize >>= 3;

[not sure if mailreader is screwing with indentation or what]

>> +
>> +        memsize += ((bxinfo & ARMCR4_BSZ_MASK) + 1) * blksize;
>>       }
>>       return memsize;

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

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

* Re: [PATCH v2 35/35] brcmfmac: common: Add support for external calibration blobs
  2022-01-04  7:26 ` [PATCH v2 35/35] brcmfmac: common: Add support for external calibration blobs Hector Martin
@ 2022-01-21  7:35   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-21  7:35 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> 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(+)

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

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

* Re: [PATCH v2 24/35] brcmfmac: feature: Add support for setting feats based on WLC version
  2022-01-04  7:26 ` [PATCH v2 24/35] brcmfmac: feature: Add support for setting feats based on WLC version Hector Martin
@ 2022-01-21  7:35   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-21  7:35 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

I have my doubts whether this mechanism will be reliable, but we can 
wait and see whatever hits the fan over time. I stayed away from this 
because it is not well guarded. Especially when there are 4 entities 
these days spinning firmware and tinkering on the firmware api without 
much collaboration.

Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 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(-)

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

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

* Re: [PATCH v2 25/35] brcmfmac: cfg80211: Add support for PMKID_V3 operations
  2022-01-04  7:26 ` [PATCH v2 25/35] brcmfmac: cfg80211: Add support for PMKID_V3 operations Hector Martin
@ 2022-01-21  7:35   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-21  7:35 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   .../broadcom/brcm80211/brcmfmac/cfg80211.c    | 52 +++++++++++-
>   .../broadcom/brcm80211/brcmfmac/fwil_types.h  | 83 +++++++++++++++++++
>   2 files changed, 132 insertions(+), 3 deletions(-)

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

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

* Re: [PATCH v2 26/35] brcmfmac: cfg80211: Pass the PMK in binary instead of hex
  2022-01-04  7:26 ` [PATCH v2 26/35] brcmfmac: cfg80211: Pass the PMK in binary instead of hex Hector Martin
@ 2022-01-21  7:35   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-21  7:35 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   .../wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 13 +++++++------
>   1 file changed, 7 insertions(+), 6 deletions(-)

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

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

* Re: [PATCH v2 27/35] brcmfmac: pcie: Add IDs/properties for BCM4387
  2022-01-04  7:26 ` [PATCH v2 27/35] brcmfmac: pcie: Add IDs/properties for BCM4387 Hector Martin
@ 2022-01-21  7:35   ` Arend van Spriel
  2022-01-31 16:37     ` Hector Martin
  0 siblings, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-21  7:35 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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)
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>> 
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/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index e4f2aff3c0d5..0d76440ec228 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 */

Regarding the revmask in this firmware mapping table my common practice 
was to disable older revisions and enable for given revision and newer 
until proven otherwise. So for the 4387c2 that would have to following 
mask 0xFFFFFF80 (if rev 7 indeed matches with c2).

>   };
>   
>   #define BRCMF_PCIE_FW_UP_TIMEOUT		5000 /* msec */

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

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

* Re: [PATCH v2 33/35] brcmfmac: common: Add support for downloading TxCap blobs
  2022-01-04  7:26 ` [PATCH v2 33/35] brcmfmac: common: Add support for downloading TxCap blobs Hector Martin
@ 2022-01-21  7:36   ` Arend van Spriel
  2022-01-31 16:28     ` Hector Martin
  0 siblings, 1 reply; 122+ messages in thread
From: Arend van Spriel @ 2022-01-21  7:36 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 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

[...]

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

[...]

> +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");

Although unlikely that we end up here with a firmware that does not 
support this command it is not impossible. Should we handle that here or 
introduce a feature flag for txcap loading?

> +	release_firmware(fw);
>   	return err;
>   }

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

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

* Re: [PATCH v2 34/35] brcmfmac: pcie: Load and provide TxCap blobs
  2022-01-04  7:26 ` [PATCH v2 34/35] brcmfmac: pcie: Load and provide " Hector Martin
@ 2022-01-21  7:36   ` Arend van Spriel
  0 siblings, 0 replies; 122+ messages in thread
From: Arend van Spriel @ 2022-01-21  7:36 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

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

On 1/4/2022 8:26 AM, Hector Martin 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.
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   .../net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 13 +++++++++++++
>   1 file changed, 13 insertions(+)

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

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

* Re: [PATCH v2 22/35] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks
  2022-01-19 12:36   ` Arend van Spriel
  2022-01-20  8:49     ` Arend van Spriel
@ 2022-01-31 16:21     ` Hector Martin
  1 sibling, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-31 16:21 UTC (permalink / raw)
  To: Arend van Spriel, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Wright Feng, Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 19/01/2022 21.36, Arend van Spriel wrote:
>>   /** 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)
> 
> Not sure why you add ci parameter here. It is not used below or am I 
> overlooking something.

Oops, looks like junk left behind from when I was trying to figure this
out. Removed. Sorry about that.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 33/35] brcmfmac: common: Add support for downloading TxCap blobs
  2022-01-21  7:36   ` Arend van Spriel
@ 2022-01-31 16:28     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-31 16:28 UTC (permalink / raw)
  To: Arend van Spriel, Kalle Valo, David S. Miller, Jakub Kicinski,
	Rob Herring, Rafael J. Wysocki, Len Brown, Arend van Spriel,
	Franky Lin, Hante Meuleman, Wright Feng, Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 21/01/2022 16.36, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin 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.
> 
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> 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
> 
> [...]
> 
>> @@ -165,20 +157,64 @@ static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
>>   	} while ((datalen > 0) && (err == 0));
>>   
> 
> [...]
> 
>> +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");
> 
> Although unlikely that we end up here with a firmware that does not 
> support this command it is not impossible. Should we handle that here or 
> introduce a feature flag for txcap loading?

Hmm, like trying to read txcapload_status to set the feature flag?

Honestly though, if we end up here on an unsupported firmware that
sounds like a firmware loading error, since if we have a TxCap blob for
a given board we better have a firmware that supports it. So it doesn't
feel too wrong to just error out entirely so the user knows something is
horribly wrong, instead of trying to use what is probably the wrong
firmware.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

* Re: [PATCH v2 27/35] brcmfmac: pcie: Add IDs/properties for BCM4387
  2022-01-21  7:35   ` Arend van Spriel
@ 2022-01-31 16:37     ` Hector Martin
  0 siblings, 0 replies; 122+ messages in thread
From: Hector Martin @ 2022-01-31 16:37 UTC (permalink / raw)
  To: Arend van Spriel, 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,
	Dmitry Osipenko
  Cc: Sven Peter, Alyssa Rosenzweig, Mark Kettenis,
	Rafał Miłecki, Pieter-Paul Giesberts, Linus Walleij,
	Hans de Goede, John W. Linville, brian m. carlson,
	Andy Shevchenko, linux-wireless, netdev, devicetree,
	linux-kernel, linux-acpi, brcm80211-dev-list.pdl,
	SHA-cyfmac-dev-list

On 21/01/2022 16.35, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin wrote:
>> @@ -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 */
> 
> Regarding the revmask in this firmware mapping table my common practice 
> was to disable older revisions and enable for given revision and newer 
> until proven otherwise. So for the 4387c2 that would have to following 
> mask 0xFFFFFF80 (if rev 7 indeed matches with c2).
> 

Makes sense, I changed it to that for all the additions :)

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

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

end of thread, other threads:[~2022-01-31 16:37 UTC | newest]

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

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