[PATCH v2 0/5] BCM4355/4364/4377 support & identification fixes

[PATCH v2 0/5] BCM4355/4364/4377 support & identification fixes

[Hector Martin]

Hi all,

This series adds support for the BCM4355, BCM4364, and BCM4377 variants
found on Intel Apple Macs of the T2 era (and a few pre-T2 ones).

The first patch drops the RAW device IDs, as discussed in the v1 thread.

The second patch fixes a bunch of confusion introduced when adding
support for the Cypress 89459 chip, which is, as far as I can tell,
just a BCM4355.

The subsequent patches add the firmware names and remaining missing
device IDs, including splitting the BCM4364 firmware name by revision
(since it was previously added without giving thought to the existence
of more than one revision in the wild with different firmwares,
resulting in different users manually copying different incompatible
firmwares as the same firmware name).

None of these devices have firmware in linux-firmware, so we should
still be able to tweak firmware filenames without breaking anyone that
matters. Apple T2 users these days are mostly using downstream trees
with the Asahi Linux WLAN patches merged anyway, so they already know
about this.

Note that these devices aren't fully usable as far as firmware
selection on these platforms without some extra patches to add support
for fetching the required info from ACPI, but I want to get the device
ID stuff out of the way first to move forward.

v2: Added a commit in front to drop all the RAW device IDs as discussed,
    and also fixed the 4364 firmware interface from BCA to WCC, as
    pointed out in the v1 thread.

Hector Martin (5):
  brcmfmac: Drop all the RAW device IDs
  wifi: brcmfmac: Rename Cypress 89459 to BCM4355
  brcmfmac: pcie: Add IDs/properties for BCM4355
  brcmfmac: pcie: Add IDs/properties for BCM4377
  brcmfmac: pcie: Perform correct BCM4364 firmware selection

 .../broadcom/brcm80211/brcmfmac/chip.c        |  6 ++--
 .../broadcom/brcm80211/brcmfmac/pcie.c        | 36 +++++++++++++------
 .../broadcom/brcm80211/include/brcm_hw_ids.h  | 11 +++---
 3 files changed, 34 insertions(+), 19 deletions(-)

-- 
2.35.1

[PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Hector Martin]

These device IDs are only supposed to be visible internally, in devices
without a proper OTP. They should never be seen in devices in the wild,
so drop them to avoid confusion.

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c       | 4 ----
 drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 4 ----
 2 files changed, 8 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index ae57a9a3ab05..93f961d484c3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -2589,17 +2589,14 @@ static const struct dev_pm_ops brcmf_pciedrvr_pm = {
 static const struct pci_device_id brcmf_pcie_devid_table[] = {
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4350_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE_SUB(0x4355, BRCM_PCIE_VENDOR_ID_BROADCOM, 0x4355, WCC),
-	BRCMF_PCIE_DEVICE(BRCM_PCIE_4354_RAW_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4356_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43567_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_DEVICE_ID, WCC),
-	BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_RAW_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4358_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4359_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_2G_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_5G_DEVICE_ID, WCC),
-	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_RAW_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4364_DEVICE_ID, BCA),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_DEVICE_ID, BCA),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_2G_DEVICE_ID, BCA),
@@ -2611,7 +2608,6 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4371_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4378_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(CY_PCIE_89459_DEVICE_ID, CYW),
-	BRCMF_PCIE_DEVICE(CY_PCIE_89459_RAW_DEVICE_ID, CYW),
 	{ /* 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 f4939cf62767..a211a72fca42 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -71,17 +71,14 @@
 /* PCIE Device IDs */
 #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_4356_DEVICE_ID	0x43ec
 #define BRCM_PCIE_43567_DEVICE_ID	0x43d3
 #define BRCM_PCIE_43570_DEVICE_ID	0x43d9
-#define BRCM_PCIE_43570_RAW_DEVICE_ID	0xaa31
 #define BRCM_PCIE_4358_DEVICE_ID	0x43e9
 #define BRCM_PCIE_4359_DEVICE_ID	0x43ef
 #define BRCM_PCIE_43602_DEVICE_ID	0x43ba
 #define BRCM_PCIE_43602_2G_DEVICE_ID	0x43bb
 #define BRCM_PCIE_43602_5G_DEVICE_ID	0x43bc
-#define BRCM_PCIE_43602_RAW_DEVICE_ID	43602
 #define BRCM_PCIE_4364_DEVICE_ID	0x4464
 #define BRCM_PCIE_4365_DEVICE_ID	0x43ca
 #define BRCM_PCIE_4365_2G_DEVICE_ID	0x43cb
@@ -92,7 +89,6 @@
 #define BRCM_PCIE_4371_DEVICE_ID	0x440d
 #define BRCM_PCIE_4378_DEVICE_ID	0x4425
 #define CY_PCIE_89459_DEVICE_ID         0x4415
-#define CY_PCIE_89459_RAW_DEVICE_ID     0x4355
 
 /* brcmsmac IDs */
 #define BCM4313_D11N2G_ID	0x4727	/* 4313 802.11n 2.4G device */
-- 
2.35.1

[PATCH v2 2/5] wifi: brcmfmac: Rename Cypress 89459 to BCM4355

[Hector Martin]

The commit that introduced support for this chip incorrectly claimed it
is a Cypress-specific part, while in actuality it is just a variant of
BCM4355 silicon (as evidenced by the chip ID).

The relationship between Cypress products and Broadcom products isn't
entirely clear but given what little information is available and prior
art in the driver, it seems the convention should be that originally
Broadcom parts should retain the Broadcom name.

Thus, rename the relevant constants and firmware file. Also rename the
specific 89459 PCIe ID to BCM43596, which seems to be the original
subvariant name for this PCI ID (as defined in the out-of-tree bcmdhd
driver).

v2: Since Cypress added this part and will presumably be providing
its supported firmware, we keep the CYW designation for this device.

Fixes: dce45ded7619 ("brcmfmac: Support 89459 pcie")
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     | 5 ++---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c     | 6 +++---
 .../net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h   | 4 ++--
 3 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 121893bbaa1d..3e42c2bd0d9a 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)
 	case BRCM_CC_43664_CHIP_ID:
 	case BRCM_CC_43666_CHIP_ID:
 		return 0x200000;
+	case BRCM_CC_4355_CHIP_ID:
 	case BRCM_CC_4359_CHIP_ID:
 		return (ci->pub.chiprev < 9) ? 0x180000 : 0x160000;
 	case BRCM_CC_4364_CHIP_ID:
@@ -735,8 +736,6 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv *ci)
 		return 0x170000;
 	case BRCM_CC_4378_CHIP_ID:
 		return 0x352000;
-	case CY_CC_89459_CHIP_ID:
-		return ((ci->pub.chiprev < 9) ? 0x180000 : 0x160000);
 	default:
 		brcmf_err("unknown chip: %s\n", ci->pub.name);
 		break;
@@ -1426,8 +1425,8 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
 		addr = CORE_CC_REG(base, sr_control1);
 		reg = chip->ops->read32(chip->ctx, addr);
 		return reg != 0;
+	case BRCM_CC_4355_CHIP_ID:
 	case CY_CC_4373_CHIP_ID:
-	case CY_CC_89459_CHIP_ID:
 		/* explicitly check SR engine enable bit */
 		addr = CORE_CC_REG(base, sr_control0);
 		reg = chip->ops->read32(chip->ctx, addr);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 93f961d484c3..6b57cb9444db 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -51,6 +51,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(4355, "brcmfmac4355-pcie");
 BRCMF_FW_CLM_DEF(4356, "brcmfmac4356-pcie");
 BRCMF_FW_CLM_DEF(43570, "brcmfmac43570-pcie");
 BRCMF_FW_DEF(4358, "brcmfmac4358-pcie");
@@ -62,7 +63,6 @@ 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");
-BRCMF_FW_DEF(4355, "brcmfmac89459-pcie");
 
 /* firmware config files */
 MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.txt");
@@ -78,6 +78,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, 4355),
 	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),
@@ -93,7 +94,6 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
 	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), /* revision ID 3 */
-	BRCMF_FW_ENTRY(CY_CC_89459_CHIP_ID, 0xFFFFFFFF, 4355),
 };
 
 #define BRCMF_PCIE_FW_UP_TIMEOUT		5000 /* msec */
@@ -2606,8 +2606,8 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_2G_DEVICE_ID, BCA),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_5G_DEVICE_ID, BCA),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4371_DEVICE_ID, WCC),
+	BRCMF_PCIE_DEVICE(BRCM_PCIE_43596_DEVICE_ID, CYW),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4378_DEVICE_ID, WCC),
-	BRCMF_PCIE_DEVICE(CY_PCIE_89459_DEVICE_ID, CYW),
 	{ /* 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 a211a72fca42..eae609d5f42d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -37,6 +37,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
@@ -56,7 +57,6 @@
 #define CY_CC_43012_CHIP_ID		43012
 #define CY_CC_43439_CHIP_ID		43439
 #define CY_CC_43752_CHIP_ID		43752
-#define CY_CC_89459_CHIP_ID		0x4355
 
 /* USB Device IDs */
 #define BRCM_USB_43143_DEVICE_ID	0xbd1e
@@ -87,8 +87,8 @@
 #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_43596_DEVICE_ID	0x4415
 #define BRCM_PCIE_4378_DEVICE_ID	0x4425
-#define CY_PCIE_89459_DEVICE_ID         0x4415
 
 /* brcmsmac IDs */
 #define BCM4313_D11N2G_ID	0x4727	/* 4313 802.11n 2.4G device */
-- 
2.35.1

[PATCH v2 3/5] brcmfmac: pcie: Add IDs/properties for BCM4355

[Hector Martin]

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

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

Users report seeing PCI revision ID 12 for this chip, which Arend
reports should be revision C2, but Apple has the firmware tagged as
revision C1. Assume the right cutoff point for firmware versions is
revision ID 11 then, and leave older revisions using the non-versioned
firmware filename (Apple only uses C1 firmware builds).

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/pcie.c    | 10 +++++++++-
 .../wireless/broadcom/brcm80211/include/brcm_hw_ids.h  |  1 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 6b57cb9444db..2b7da248fd93 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -52,6 +52,7 @@ BRCMF_FW_DEF(43602, "brcmfmac43602-pcie");
 BRCMF_FW_DEF(4350, "brcmfmac4350-pcie");
 BRCMF_FW_DEF(4350C, "brcmfmac4350c2-pcie");
 BRCMF_FW_CLM_DEF(4355, "brcmfmac4355-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");
@@ -78,7 +79,8 @@ 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, 4355),
+	BRCMF_FW_ENTRY(BRCM_CC_4355_CHIP_ID, 0x000007FF, 4355),
+	BRCMF_FW_ENTRY(BRCM_CC_4355_CHIP_ID, 0xFFFFF800, 4355C1), /* rev ID 12/C2 seen */
 	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),
@@ -1994,6 +1996,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;
@@ -2589,6 +2596,7 @@ static const struct dev_pm_ops brcmf_pciedrvr_pm = {
 static const struct pci_device_id brcmf_pcie_devid_table[] = {
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4350_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE_SUB(0x4355, BRCM_PCIE_VENDOR_ID_BROADCOM, 0x4355, WCC),
+	BRCMF_PCIE_DEVICE(BRCM_PCIE_4355_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4356_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43567_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_DEVICE_ID, WCC),
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 eae609d5f42d..f73ca914256f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -71,6 +71,7 @@
 /* PCIE Device IDs */
 #define BRCM_PCIE_4350_DEVICE_ID	0x43a3
 #define BRCM_PCIE_4354_DEVICE_ID	0x43df
+#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.35.1

[PATCH v2 4/5] brcmfmac: pcie: Add IDs/properties for BCM4377

[Hector Martin]

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>
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      | 1 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c      | 5 +++++
 .../net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h    | 2 ++
 3 files changed, 8 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 3e42c2bd0d9a..8073f31be27d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -733,6 +733,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 2b7da248fd93..141c1872b6c1 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(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 */
@@ -95,6 +96,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), /* revision ID 4 */
 	BRCMF_FW_ENTRY(BRCM_CC_4378_CHIP_ID, 0xFFFFFFFF, 4378B1), /* revision ID 3 */
 };
 
@@ -2001,6 +2003,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;
@@ -2615,7 +2618,9 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_5G_DEVICE_ID, BCA),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4371_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43596_DEVICE_ID, CYW),
+	BRCMF_PCIE_DEVICE(BRCM_PCIE_4377_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4378_DEVICE_ID, WCC),
+
 	{ /* 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 f73ca914256f..842e3d44fa49 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -52,6 +52,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
@@ -89,6 +90,7 @@
 #define BRCM_PCIE_4366_5G_DEVICE_ID	0x43c5
 #define BRCM_PCIE_4371_DEVICE_ID	0x440d
 #define BRCM_PCIE_43596_DEVICE_ID	0x4415
+#define BRCM_PCIE_4377_DEVICE_ID	0x4488
 #define BRCM_PCIE_4378_DEVICE_ID	0x4425
 
 /* brcmsmac IDs */
-- 
2.35.1

[PATCH v2 5/5] brcmfmac: pcie: Perform correct BCM4364 firmware selection

[Hector Martin]

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)

v2: Also fix the firmware interface for 4364, from BCA to WCC.

Fixes: 24f0bd136264 ("brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2")
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, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 141c1872b6c1..5ff2d7689af3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -57,7 +57,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");
@@ -88,7 +89,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),
@@ -2003,6 +2005,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;
@@ -2608,7 +2615,7 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_2G_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_5G_DEVICE_ID, WCC),
-	BRCMF_PCIE_DEVICE(BRCM_PCIE_4364_DEVICE_ID, BCA),
+	BRCMF_PCIE_DEVICE(BRCM_PCIE_4364_DEVICE_ID, WCC),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_DEVICE_ID, BCA),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_2G_DEVICE_ID, BCA),
 	BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_5G_DEVICE_ID, BCA),
-- 
2.35.1

Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Arend van Spriel]

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

On 1/31/2023 12:28 PM, 'Hector Martin' via BRCM80211-DEV-LIST,PDL wrote:
> These device IDs are only supposed to be visible internally, in devices
> without a proper OTP. They should never be seen in devices in the wild,
> so drop them to avoid confusion.

Thanks for this cleanup.

Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c       | 4 ----
>   drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 4 ----
>   2 files changed, 8 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index ae57a9a3ab05..93f961d484c3 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -2589,17 +2589,14 @@ static const struct dev_pm_ops brcmf_pciedrvr_pm = {
>   static const struct pci_device_id brcmf_pcie_devid_table[] = {
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_4350_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE_SUB(0x4355, BRCM_PCIE_VENDOR_ID_BROADCOM, 0x4355, WCC),
> -	BRCMF_PCIE_DEVICE(BRCM_PCIE_4354_RAW_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_4356_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_43567_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_DEVICE_ID, WCC),
> -	BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_RAW_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_4358_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_4359_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_2G_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_5G_DEVICE_ID, WCC),
> -	BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_RAW_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_4364_DEVICE_ID, BCA),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_DEVICE_ID, BCA),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_2G_DEVICE_ID, BCA),
> @@ -2611,7 +2608,6 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_4371_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(BRCM_PCIE_4378_DEVICE_ID, WCC),
>   	BRCMF_PCIE_DEVICE(CY_PCIE_89459_DEVICE_ID, CYW),
> -	BRCMF_PCIE_DEVICE(CY_PCIE_89459_RAW_DEVICE_ID, CYW),
>   	{ /* 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 f4939cf62767..a211a72fca42 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
> @@ -71,17 +71,14 @@
>   /* PCIE Device IDs */
>   #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_4356_DEVICE_ID	0x43ec
>   #define BRCM_PCIE_43567_DEVICE_ID	0x43d3
>   #define BRCM_PCIE_43570_DEVICE_ID	0x43d9
> -#define BRCM_PCIE_43570_RAW_DEVICE_ID	0xaa31
>   #define BRCM_PCIE_4358_DEVICE_ID	0x43e9
>   #define BRCM_PCIE_4359_DEVICE_ID	0x43ef
>   #define BRCM_PCIE_43602_DEVICE_ID	0x43ba
>   #define BRCM_PCIE_43602_2G_DEVICE_ID	0x43bb
>   #define BRCM_PCIE_43602_5G_DEVICE_ID	0x43bc
> -#define BRCM_PCIE_43602_RAW_DEVICE_ID	43602
>   #define BRCM_PCIE_4364_DEVICE_ID	0x4464
>   #define BRCM_PCIE_4365_DEVICE_ID	0x43ca
>   #define BRCM_PCIE_4365_2G_DEVICE_ID	0x43cb
> @@ -92,7 +89,6 @@
>   #define BRCM_PCIE_4371_DEVICE_ID	0x440d
>   #define BRCM_PCIE_4378_DEVICE_ID	0x4425
>   #define CY_PCIE_89459_DEVICE_ID         0x4415
> -#define CY_PCIE_89459_RAW_DEVICE_ID     0x4355
>   
>   /* brcmsmac IDs */
>   #define BCM4313_D11N2G_ID	0x4727	/* 4313 802.11n 2.4G device */

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

Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Jonas Gorski]

On Tue, 31 Jan 2023 at 12:36, Hector Martin <marcan@marcan.st> wrote:
>
> These device IDs are only supposed to be visible internally, in devices
> without a proper OTP. They should never be seen in devices in the wild,
> so drop them to avoid confusion.

I think these can still show up in embedded platforms where the
OTP/SPROM is provided on-flash.

E.g. https://forum.archive.openwrt.org/viewtopic.php?id=55367&p=4
shows this bootlog on an BCM4709A0 router with two BCM43602 wifis:

[    3.237132] pci 0000:01:00.0: [14e4:aa52] type 00 class 0x028000
[    3.237174] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
[    3.237199] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
[    3.237302] pci 0000:01:00.0: supports D1 D2
...
[    3.782384] pci 0001:03:00.0: [14e4:aa52] type 00 class 0x028000
[    3.782440] pci 0001:03:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
[    3.782474] pci 0001:03:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
[    3.782649] pci 0001:03:00.0: supports D1 D2

0xaa52 == 43602 (BRCM_PCIE_43602_RAW_DEVICE_ID)

Rafał can probably provide more info there.

Regards
Jonas

Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Hector Martin]

On 31/01/2023 23.17, Jonas Gorski wrote:
> On Tue, 31 Jan 2023 at 12:36, Hector Martin <marcan@marcan.st> wrote:
>>
>> These device IDs are only supposed to be visible internally, in devices
>> without a proper OTP. They should never be seen in devices in the wild,
>> so drop them to avoid confusion.
> 
> I think these can still show up in embedded platforms where the
> OTP/SPROM is provided on-flash.
> 
> E.g. https://forum.archive.openwrt.org/viewtopic.php?id=55367&p=4
> shows this bootlog on an BCM4709A0 router with two BCM43602 wifis:
> 
> [    3.237132] pci 0000:01:00.0: [14e4:aa52] type 00 class 0x028000
> [    3.237174] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
> [    3.237199] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
> [    3.237302] pci 0000:01:00.0: supports D1 D2
> ...
> [    3.782384] pci 0001:03:00.0: [14e4:aa52] type 00 class 0x028000
> [    3.782440] pci 0001:03:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
> [    3.782474] pci 0001:03:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
> [    3.782649] pci 0001:03:00.0: supports D1 D2
> 
> 0xaa52 == 43602 (BRCM_PCIE_43602_RAW_DEVICE_ID)
> 
> Rafał can probably provide more info there.
> 
> Regards
> Jonas
> 

Arend, any comments on these platforms?

- Hector

Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Arend Van Spriel]

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

On February 2, 2023 6:25:28 AM "'Hector Martin' via BRCM80211-DEV-LIST,PDL" 
<brcm80211-dev-list.pdl@broadcom.com> wrote:

> On 31/01/2023 23.17, Jonas Gorski wrote:
>> On Tue, 31 Jan 2023 at 12:36, Hector Martin <marcan@marcan.st> wrote:
>>>
>>> These device IDs are only supposed to be visible internally, in devices
>>> without a proper OTP. They should never be seen in devices in the wild,
>>> so drop them to avoid confusion.
>>
>> I think these can still show up in embedded platforms where the
>> OTP/SPROM is provided on-flash.
>>
>> E.g. https://forum.archive.openwrt.org/viewtopic.php?id=55367&p=4
>> shows this bootlog on an BCM4709A0 router with two BCM43602 wifis:
>>
>> [    3.237132] pci 0000:01:00.0: [14e4:aa52] type 00 class 0x028000
>> [    3.237174] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>> [    3.237199] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>> [    3.237302] pci 0000:01:00.0: supports D1 D2
>> ...
>> [    3.782384] pci 0001:03:00.0: [14e4:aa52] type 00 class 0x028000
>> [    3.782440] pci 0001:03:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>> [    3.782474] pci 0001:03:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>> [    3.782649] pci 0001:03:00.0: supports D1 D2
>>
>> 0xaa52 == 43602 (BRCM_PCIE_43602_RAW_DEVICE_ID)
>>
>> Rafał can probably provide more info there.
>>
>> Regards
>> Jonas
>
> Arend, any comments on these platforms?

Huh? I already replied to that couple of days ago or did I only imagine 
doing that.

Regards,
Arend




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

Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Hector Martin]

On 03/02/2023 02.19, Arend Van Spriel wrote:
> On February 2, 2023 6:25:28 AM "'Hector Martin' via BRCM80211-DEV-LIST,PDL" 
> <brcm80211-dev-list.pdl@broadcom.com> wrote:
> 
>> On 31/01/2023 23.17, Jonas Gorski wrote:
>>> On Tue, 31 Jan 2023 at 12:36, Hector Martin <marcan@marcan.st> wrote:
>>>>
>>>> These device IDs are only supposed to be visible internally, in devices
>>>> without a proper OTP. They should never be seen in devices in the wild,
>>>> so drop them to avoid confusion.
>>>
>>> I think these can still show up in embedded platforms where the
>>> OTP/SPROM is provided on-flash.
>>>
>>> E.g. https://forum.archive.openwrt.org/viewtopic.php?id=55367&p=4
>>> shows this bootlog on an BCM4709A0 router with two BCM43602 wifis:
>>>
>>> [    3.237132] pci 0000:01:00.0: [14e4:aa52] type 00 class 0x028000
>>> [    3.237174] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>> [    3.237199] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>> [    3.237302] pci 0000:01:00.0: supports D1 D2
>>> ...
>>> [    3.782384] pci 0001:03:00.0: [14e4:aa52] type 00 class 0x028000
>>> [    3.782440] pci 0001:03:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>> [    3.782474] pci 0001:03:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>> [    3.782649] pci 0001:03:00.0: supports D1 D2
>>>
>>> 0xaa52 == 43602 (BRCM_PCIE_43602_RAW_DEVICE_ID)
>>>
>>> Rafał can probably provide more info there.
>>>
>>> Regards
>>> Jonas
>>
>> Arend, any comments on these platforms?
> 
> Huh? I already replied to that couple of days ago or did I only imagine 
> doing that.

I don't see any replies from you on the lists (or my inbox) to Jonas' email.

- Hector

Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Arend Van Spriel]

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

- stale Cypress emails

On February 5, 2023 3:50:41 AM Hector Martin <marcan@marcan.st> wrote:

> On 03/02/2023 02.19, Arend Van Spriel wrote:
>> On February 2, 2023 6:25:28 AM "'Hector Martin' via BRCM80211-DEV-LIST,PDL"
>> <brcm80211-dev-list.pdl@broadcom.com> wrote:
>>
>>> On 31/01/2023 23.17, Jonas Gorski wrote:
>>>> On Tue, 31 Jan 2023 at 12:36, Hector Martin <marcan@marcan.st> wrote:
>>>>>
>>>>> These device IDs are only supposed to be visible internally, in devices
>>>>> without a proper OTP. They should never be seen in devices in the wild,
>>>>> so drop them to avoid confusion.
>>>>
>>>> I think these can still show up in embedded platforms where the
>>>> OTP/SPROM is provided on-flash.
>>>>
>>>> E.g. https://forum.archive.openwrt.org/viewtopic.php?id=55367&p=4
>>>> shows this bootlog on an BCM4709A0 router with two BCM43602 wifis:
>>>>
>>>> [    3.237132] pci 0000:01:00.0: [14e4:aa52] type 00 class 0x028000
>>>> [    3.237174] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>>> [    3.237199] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>>> [    3.237302] pci 0000:01:00.0: supports D1 D2
>>>> ...
>>>> [    3.782384] pci 0001:03:00.0: [14e4:aa52] type 00 class 0x028000
>>>> [    3.782440] pci 0001:03:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>>> [    3.782474] pci 0001:03:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>>> [    3.782649] pci 0001:03:00.0: supports D1 D2
>>>>
>>>> 0xaa52 == 43602 (BRCM_PCIE_43602_RAW_DEVICE_ID)
>>>>
>>>> Rafał can probably provide more info there.
>>>>
>>>> Regards
>>>> Jonas
>>>
>>> Arend, any comments on these platforms?
>>
>> Huh? I already replied to that couple of days ago or did I only imagine
>> doing that.
>
> I don't see any replies from you on the lists (or my inbox) to Jonas' email.

Accidentally sent that reply to internal mailing list. So quoting myself here:

"""
Shaking the tree helps ;-) What is meant by "OTP/SPROM is provided 
on-flash"? I assume you mean that it is on the host side and the wifi PCIe 
device can not access it when it gets powered up. Maybe for this scenario 
we should have a devicetree compatible to configure the device id, but that 
does not help any current users of these platforms. Thanks for providing 
this info.
"""

Regards,
Arend




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

Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Jonas Gorski]

On Sun, 5 Feb 2023 at 07:58, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
>
> - stale Cypress emails
>
> On February 5, 2023 3:50:41 AM Hector Martin <marcan@marcan.st> wrote:
>
> > On 03/02/2023 02.19, Arend Van Spriel wrote:
> >> On February 2, 2023 6:25:28 AM "'Hector Martin' via BRCM80211-DEV-LIST,PDL"
> >> <brcm80211-dev-list.pdl@broadcom.com> wrote:
> >>
> >>> On 31/01/2023 23.17, Jonas Gorski wrote:
> >>>> On Tue, 31 Jan 2023 at 12:36, Hector Martin <marcan@marcan.st> wrote:
> >>>>>
> >>>>> These device IDs are only supposed to be visible internally, in devices
> >>>>> without a proper OTP. They should never be seen in devices in the wild,
> >>>>> so drop them to avoid confusion.
> >>>>
> >>>> I think these can still show up in embedded platforms where the
> >>>> OTP/SPROM is provided on-flash.
> >>>>
> >>>> E.g. https://forum.archive.openwrt.org/viewtopic.php?id=55367&p=4
> >>>> shows this bootlog on an BCM4709A0 router with two BCM43602 wifis:
> >>>>
> >>>> [    3.237132] pci 0000:01:00.0: [14e4:aa52] type 00 class 0x028000
> >>>> [    3.237174] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
> >>>> [    3.237199] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
> >>>> [    3.237302] pci 0000:01:00.0: supports D1 D2
> >>>> ...
> >>>> [    3.782384] pci 0001:03:00.0: [14e4:aa52] type 00 class 0x028000
> >>>> [    3.782440] pci 0001:03:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
> >>>> [    3.782474] pci 0001:03:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
> >>>> [    3.782649] pci 0001:03:00.0: supports D1 D2
> >>>>
> >>>> 0xaa52 == 43602 (BRCM_PCIE_43602_RAW_DEVICE_ID)
> >>>>
> >>>> Rafał can probably provide more info there.
> >>>>
> >>>> Regards
> >>>> Jonas
> >>>
> >>> Arend, any comments on these platforms?
> >>
> >> Huh? I already replied to that couple of days ago or did I only imagine
> >> doing that.
> >
> > I don't see any replies from you on the lists (or my inbox) to Jonas' email.
>
> Accidentally sent that reply to internal mailing list. So quoting myself here:
>
> """
> Shaking the tree helps ;-) What is meant by "OTP/SPROM is provided
> on-flash"? I assume you mean that it is on the host side and the wifi PCIe
> device can not access it when it gets powered up. Maybe for this scenario
> we should have a devicetree compatible to configure the device id, but that
> does not help any current users of these platforms. Thanks for providing
> this info.

That's what I meant, the wifi chip itself does not have any (valid)
OTP/SPROM attached/populated, and requires the driver to setup the
values at runtime based on the host SoC's flash contents (most likely
NVRAM contents).

This was the case in about 99% of embedded systems based on MIPS
bcm47xx/bcm63xx, where the wifi chips then always identified
themselves with their raw chip IDs as PCI device IDs (even leading to
one or two ID conflicts ...).

I have to admit I don't know how much this is still an issue on
current (ARM) systems, but at least that one BCM4709A one suggests
this is still happening in "recent" designs. Probably because it saves
half a cent per board or so ;-)

Regards
Jonas

Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Hector Martin]

On 05/02/2023 21.44, Jonas Gorski wrote:
> On Sun, 5 Feb 2023 at 07:58, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>>
>> - stale Cypress emails
>>
>> On February 5, 2023 3:50:41 AM Hector Martin <marcan@marcan.st> wrote:
>>
>>> On 03/02/2023 02.19, Arend Van Spriel wrote:
>>>> On February 2, 2023 6:25:28 AM "'Hector Martin' via BRCM80211-DEV-LIST,PDL"
>>>> <brcm80211-dev-list.pdl@broadcom.com> wrote:
>>>>
>>>>> On 31/01/2023 23.17, Jonas Gorski wrote:
>>>>>> On Tue, 31 Jan 2023 at 12:36, Hector Martin <marcan@marcan.st> wrote:
>>>>>>>
>>>>>>> These device IDs are only supposed to be visible internally, in devices
>>>>>>> without a proper OTP. They should never be seen in devices in the wild,
>>>>>>> so drop them to avoid confusion.
>>>>>>
>>>>>> I think these can still show up in embedded platforms where the
>>>>>> OTP/SPROM is provided on-flash.
>>>>>>
>>>>>> E.g. https://forum.archive.openwrt.org/viewtopic.php?id=55367&p=4
>>>>>> shows this bootlog on an BCM4709A0 router with two BCM43602 wifis:
>>>>>>
>>>>>> [    3.237132] pci 0000:01:00.0: [14e4:aa52] type 00 class 0x028000
>>>>>> [    3.237174] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>>>>> [    3.237199] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>>>>> [    3.237302] pci 0000:01:00.0: supports D1 D2
>>>>>> ...
>>>>>> [    3.782384] pci 0001:03:00.0: [14e4:aa52] type 00 class 0x028000
>>>>>> [    3.782440] pci 0001:03:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>>>>> [    3.782474] pci 0001:03:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>>>>> [    3.782649] pci 0001:03:00.0: supports D1 D2
>>>>>>
>>>>>> 0xaa52 == 43602 (BRCM_PCIE_43602_RAW_DEVICE_ID)
>>>>>>
>>>>>> Rafał can probably provide more info there.
>>>>>>
>>>>>> Regards
>>>>>> Jonas
>>>>>
>>>>> Arend, any comments on these platforms?
>>>>
>>>> Huh? I already replied to that couple of days ago or did I only imagine
>>>> doing that.
>>>
>>> I don't see any replies from you on the lists (or my inbox) to Jonas' email.
>>
>> Accidentally sent that reply to internal mailing list. So quoting myself here:
>>
>> """
>> Shaking the tree helps ;-) What is meant by "OTP/SPROM is provided
>> on-flash"? I assume you mean that it is on the host side and the wifi PCIe
>> device can not access it when it gets powered up. Maybe for this scenario
>> we should have a devicetree compatible to configure the device id, but that
>> does not help any current users of these platforms. Thanks for providing
>> this info.
> 
> That's what I meant, the wifi chip itself does not have any (valid)
> OTP/SPROM attached/populated, and requires the driver to setup the
> values at runtime based on the host SoC's flash contents (most likely
> NVRAM contents).
> 
> This was the case in about 99% of embedded systems based on MIPS
> bcm47xx/bcm63xx, where the wifi chips then always identified
> themselves with their raw chip IDs as PCI device IDs (even leading to
> one or two ID conflicts ...).
> 
> I have to admit I don't know how much this is still an issue on
> current (ARM) systems, but at least that one BCM4709A one suggests
> this is still happening in "recent" designs. Probably because it saves
> half a cent per board or so ;-)
> 
> Regards
> Jonas
> 

As far as I know the OTP is built into the chips themselves, and even
Apple (who refuses to put per-device calibration data in OTP these days
and loads it from DT) still manages to burn in the proper device ID and
basic info at least... so I'm not sure how this saves any money. I
thought chips weren't supposed to even leave Broadcom without at least
an ID burned in?

- Hector

Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Hector Martin]

On 05/02/2023 22.02, Hector Martin wrote:
> On 05/02/2023 21.44, Jonas Gorski wrote:
>> On Sun, 5 Feb 2023 at 07:58, Arend Van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>>
>>> - stale Cypress emails
>>>
>>> On February 5, 2023 3:50:41 AM Hector Martin <marcan@marcan.st> wrote:
>>>
>>>> On 03/02/2023 02.19, Arend Van Spriel wrote:
>>>>> On February 2, 2023 6:25:28 AM "'Hector Martin' via BRCM80211-DEV-LIST,PDL"
>>>>> <brcm80211-dev-list.pdl@broadcom.com> wrote:
>>>>>
>>>>>> On 31/01/2023 23.17, Jonas Gorski wrote:
>>>>>>> On Tue, 31 Jan 2023 at 12:36, Hector Martin <marcan@marcan.st> wrote:
>>>>>>>>
>>>>>>>> These device IDs are only supposed to be visible internally, in devices
>>>>>>>> without a proper OTP. They should never be seen in devices in the wild,
>>>>>>>> so drop them to avoid confusion.
>>>>>>>
>>>>>>> I think these can still show up in embedded platforms where the
>>>>>>> OTP/SPROM is provided on-flash.
>>>>>>>
>>>>>>> E.g. https://forum.archive.openwrt.org/viewtopic.php?id=55367&p=4
>>>>>>> shows this bootlog on an BCM4709A0 router with two BCM43602 wifis:
>>>>>>>
>>>>>>> [    3.237132] pci 0000:01:00.0: [14e4:aa52] type 00 class 0x028000
>>>>>>> [    3.237174] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>>>>>> [    3.237199] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>>>>>> [    3.237302] pci 0000:01:00.0: supports D1 D2
>>>>>>> ...
>>>>>>> [    3.782384] pci 0001:03:00.0: [14e4:aa52] type 00 class 0x028000
>>>>>>> [    3.782440] pci 0001:03:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>>>>>> [    3.782474] pci 0001:03:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>>>>>> [    3.782649] pci 0001:03:00.0: supports D1 D2
>>>>>>>
>>>>>>> 0xaa52 == 43602 (BRCM_PCIE_43602_RAW_DEVICE_ID)
>>>>>>>
>>>>>>> Rafał can probably provide more info there.
>>>>>>>
>>>>>>> Regards
>>>>>>> Jonas
>>>>>>
>>>>>> Arend, any comments on these platforms?
>>>>>
>>>>> Huh? I already replied to that couple of days ago or did I only imagine
>>>>> doing that.
>>>>
>>>> I don't see any replies from you on the lists (or my inbox) to Jonas' email.
>>>
>>> Accidentally sent that reply to internal mailing list. So quoting myself here:
>>>
>>> """
>>> Shaking the tree helps ;-) What is meant by "OTP/SPROM is provided
>>> on-flash"? I assume you mean that it is on the host side and the wifi PCIe
>>> device can not access it when it gets powered up. Maybe for this scenario
>>> we should have a devicetree compatible to configure the device id, but that
>>> does not help any current users of these platforms. Thanks for providing
>>> this info.
>>
>> That's what I meant, the wifi chip itself does not have any (valid)
>> OTP/SPROM attached/populated, and requires the driver to setup the
>> values at runtime based on the host SoC's flash contents (most likely
>> NVRAM contents).
>>
>> This was the case in about 99% of embedded systems based on MIPS
>> bcm47xx/bcm63xx, where the wifi chips then always identified
>> themselves with their raw chip IDs as PCI device IDs (even leading to
>> one or two ID conflicts ...).
>>
>> I have to admit I don't know how much this is still an issue on
>> current (ARM) systems, but at least that one BCM4709A one suggests
>> this is still happening in "recent" designs. Probably because it saves
>> half a cent per board or so ;-)
>>
>> Regards
>> Jonas
>>
> 
> As far as I know the OTP is built into the chips themselves, and even
> Apple (who refuses to put per-device calibration data in OTP these days
> and loads it from DT) still manages to burn in the proper device ID and
> basic info at least... so I'm not sure how this saves any money. I
> thought chips weren't supposed to even leave Broadcom without at least
> an ID burned in?
> 
> - Hector

I'd like to move forward with this. Should I send a v3 without the RAW
ID removal?

- Hector

Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs

[Arend Van Spriel]

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

On February 8, 2023 5:02:32 AM Hector Martin <marcan@marcan.st> wrote:

> On 05/02/2023 22.02, Hector Martin wrote:
>> On 05/02/2023 21.44, Jonas Gorski wrote:
>>> On Sun, 5 Feb 2023 at 07:58, Arend Van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>>
>>>> - stale Cypress emails
>>>>
>>>> On February 5, 2023 3:50:41 AM Hector Martin <marcan@marcan.st> wrote:
>>>>
>>>>> On 03/02/2023 02.19, Arend Van Spriel wrote:
>>>>>> On February 2, 2023 6:25:28 AM "'Hector Martin' via BRCM80211-DEV-LIST,PDL"
>>>>>> <brcm80211-dev-list.pdl@broadcom.com> wrote:
>>>>>>
>>>>>>> On 31/01/2023 23.17, Jonas Gorski wrote:
>>>>>>>> On Tue, 31 Jan 2023 at 12:36, Hector Martin <marcan@marcan.st> wrote:
>>>>>>>>>
>>>>>>>>> These device IDs are only supposed to be visible internally, in devices
>>>>>>>>> without a proper OTP. They should never be seen in devices in the wild,
>>>>>>>>> so drop them to avoid confusion.
>>>>>>>>
>>>>>>>> I think these can still show up in embedded platforms where the
>>>>>>>> OTP/SPROM is provided on-flash.
>>>>>>>>
>>>>>>>> E.g. https://forum.archive.openwrt.org/viewtopic.php?id=55367&p=4
>>>>>>>> shows this bootlog on an BCM4709A0 router with two BCM43602 wifis:
>>>>>>>>
>>>>>>>> [    3.237132] pci 0000:01:00.0: [14e4:aa52] type 00 class 0x028000
>>>>>>>> [    3.237174] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>>>>>>> [    3.237199] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>>>>>>> [    3.237302] pci 0000:01:00.0: supports D1 D2
>>>>>>>> ...
>>>>>>>> [    3.782384] pci 0001:03:00.0: [14e4:aa52] type 00 class 0x028000
>>>>>>>> [    3.782440] pci 0001:03:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>>>>>>> [    3.782474] pci 0001:03:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>>>>>>> [    3.782649] pci 0001:03:00.0: supports D1 D2
>>>>>>>>
>>>>>>>> 0xaa52 == 43602 (BRCM_PCIE_43602_RAW_DEVICE_ID)
>>>>>>>>
>>>>>>>> Rafał can probably provide more info there.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Jonas
>>>>>>>
>>>>>>> Arend, any comments on these platforms?
>>>>>>
>>>>>> Huh? I already replied to that couple of days ago or did I only imagine
>>>>>> doing that.
>>>>>
>>>>> I don't see any replies from you on the lists (or my inbox) to Jonas' email.
>>>>
>>>> Accidentally sent that reply to internal mailing list. So quoting myself here:
>>>>
>>>> """
>>>> Shaking the tree helps ;-) What is meant by "OTP/SPROM is provided
>>>> on-flash"? I assume you mean that it is on the host side and the wifi PCIe
>>>> device can not access it when it gets powered up. Maybe for this scenario
>>>> we should have a devicetree compatible to configure the device id, but that
>>>> does not help any current users of these platforms. Thanks for providing
>>>> this info.
>>>
>>> That's what I meant, the wifi chip itself does not have any (valid)
>>> OTP/SPROM attached/populated, and requires the driver to setup the
>>> values at runtime based on the host SoC's flash contents (most likely
>>> NVRAM contents).
>>>
>>> This was the case in about 99% of embedded systems based on MIPS
>>> bcm47xx/bcm63xx, where the wifi chips then always identified
>>> themselves with their raw chip IDs as PCI device IDs (even leading to
>>> one or two ID conflicts ...).
>>>
>>> I have to admit I don't know how much this is still an issue on
>>> current (ARM) systems, but at least that one BCM4709A one suggests
>>> this is still happening in "recent" designs. Probably because it saves
>>> half a cent per board or so ;-)
>>>
>>> Regards
>>> Jonas
>>
>> As far as I know the OTP is built into the chips themselves, and even
>> Apple (who refuses to put per-device calibration data in OTP these days
>> and loads it from DT) still manages to burn in the proper device ID and
>> basic info at least... so I'm not sure how this saves any money. I
>> thought chips weren't supposed to even leave Broadcom without at least
>> an ID burned in?
>>
>> - Hector
>
> I'd like to move forward with this. Should I send a v3 without the RAW
> ID removal?

Yeah. Need to consider the options for solving this.

Programming the OTP is a manufacturing step done by OEM so I think they 
save having to implement that step in production and it is not so much chip 
cost saving.

Our proprietary driver is setup so it is probed for any PCI device with 
network class and then it uses NVRAM to obtain the PCI devid.

Regards,
Arend



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