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 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. This also drops the RAW device ID (just for this one
chip), as there's no reason to add it unless we find actual hardware
in the wild that uses it, and besides the raw device ID is already
there twice (with a subvendor match), which was added by 2fef681a4cf7
("brcmfmac: add CYW89342 mini-PCIe device").
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.
v3: Dropped the raw cleanup commit because apparently some platforms
rely on those. Still removing the redundant raw ID for CYW89459,
though. It seems highly unlikely that will break anything, as it'd
have to be a device with no proper ID programmed *and* a custom
subvendor programmed.
Hector Martin (4):
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 | 33 +++++++++++++++----
.../broadcom/brcm80211/include/brcm_hw_ids.h | 8 +++--
3 files changed, 34 insertions(+), 13 deletions(-)
--
2.35.1
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.
v3: Drop the RAW device ID in this commit. We don't do this for the
other chips since apparently some devices with them exist in the wild,
but there is already a 4355 entry with the Broadcom subvendor and WCC
firmware vendor, so adding a generic fallback to Cypress seems
redundant (no reason why a device would have the raw device ID *and* an
explicitly programmed subvendor).
Fixes: dce45ded7619 ("brcmfmac: Support 89459 pcie")
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Hector Martin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 5 ++---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 7 +++----
.../net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 5 ++---
3 files changed, 7 insertions(+), 10 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 ae57a9a3ab05..96608174a123 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 */
@@ -2609,9 +2609,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),
- 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..28b6cf8ff286 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
@@ -90,9 +90,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
-#define CY_PCIE_89459_RAW_DEVICE_ID 0x4355
/* brcmsmac IDs */
#define BCM4313_D11N2G_ID 0x4727 /* 4313 802.11n 2.4G device */
--
2.35.1
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 <[email protected]>
Signed-off-by: Hector Martin <[email protected]>
---
.../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 96608174a123..7135f889907a 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;
@@ -2590,6 +2597,7 @@ 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_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 28b6cf8ff286..6e27e3966655 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -72,6 +72,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.35.1
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 <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Hector Martin <[email protected]>
---
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 7135f889907a..d54394885af7 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;
@@ -2618,7 +2621,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 6e27e3966655..896615f57952 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
@@ -92,6 +93,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
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 <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Hector Martin <[email protected]>
---
.../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 d54394885af7..f320b6ce8bff 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;
@@ -2611,7 +2618,7 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
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_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
> -----Original Message-----
> From: Hector Martin <[email protected]>
> Sent: Friday, February 10, 2023 10:50 AM
> To: Arend van Spriel <[email protected]>; Franky Lin <[email protected]>; Hante Meuleman
> <[email protected]>; Kalle Valo <[email protected]>; David S. Miller <[email protected]>; Eric
> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo Abeni <[email protected]>
> Cc: Alexander Prutskov <[email protected]>; Chi-Hsien Lin <[email protected]>; Wright Feng
> <[email protected]>; Ian Lin <[email protected]>; Soontak Lee <[email protected]>; Joseph
> chuang <[email protected]>; Sven Peter <[email protected]>; Alyssa Rosenzweig <[email protected]>;
> Aditya Garg <[email protected]>; Jonas Gorski <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Hector Martin <[email protected]>; Arend van Spriel
> <[email protected]>
> Subject: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
>
> 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.
>
> v3: Drop the RAW device ID in this commit. We don't do this for the
> other chips since apparently some devices with them exist in the wild,
> but there is already a 4355 entry with the Broadcom subvendor and WCC
> firmware vendor, so adding a generic fallback to Cypress seems
> redundant (no reason why a device would have the raw device ID *and* an
> explicitly programmed subvendor).
Do you really want to add changes of v2 and v3 to commit message? Or,
just want to let reviewers know that? If latter one is what you want,
move them after s-o-b with delimiter ---
>
> Fixes: dce45ded7619 ("brcmfmac: Support 89459 pcie")
> Reviewed-by: Arend van Spriel <[email protected]>
> Signed-off-by: Hector Martin <[email protected]>
---
I mean here.
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 5 ++---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 7 +++----
> .../net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 5 ++---
> 3 files changed, 7 insertions(+), 10 deletions(-)
>
On 10/02/2023 12.42, Ping-Ke Shih wrote:
>
>
>> -----Original Message-----
>> From: Hector Martin <[email protected]>
>> Sent: Friday, February 10, 2023 10:50 AM
>> To: Arend van Spriel <[email protected]>; Franky Lin <[email protected]>; Hante Meuleman
>> <[email protected]>; Kalle Valo <[email protected]>; David S. Miller <[email protected]>; Eric
>> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo Abeni <[email protected]>
>> Cc: Alexander Prutskov <[email protected]>; Chi-Hsien Lin <[email protected]>; Wright Feng
>> <[email protected]>; Ian Lin <[email protected]>; Soontak Lee <[email protected]>; Joseph
>> chuang <[email protected]>; Sven Peter <[email protected]>; Alyssa Rosenzweig <[email protected]>;
>> Aditya Garg <[email protected]>; Jonas Gorski <[email protected]>; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; Hector Martin <[email protected]>; Arend van Spriel
>> <[email protected]>
>> Subject: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
>>
>> 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.
>>
>> v3: Drop the RAW device ID in this commit. We don't do this for the
>> other chips since apparently some devices with them exist in the wild,
>> but there is already a 4355 entry with the Broadcom subvendor and WCC
>> firmware vendor, so adding a generic fallback to Cypress seems
>> redundant (no reason why a device would have the raw device ID *and* an
>> explicitly programmed subvendor).
>
> Do you really want to add changes of v2 and v3 to commit message? Or,
> just want to let reviewers know that? If latter one is what you want,
> move them after s-o-b with delimiter ---
Both; I thought those things were worth mentioning in the commit message
as it stands on its own, and left the version tags in so reviewers know
when they were introduced.
- Hector
On February 11, 2023 11:09:02 AM Hector Martin <[email protected]> wrote:
> On 10/02/2023 12.42, Ping-Ke Shih wrote:
>>
>>
>>> -----Original Message-----
>>> From: Hector Martin <[email protected]>
>>> Sent: Friday, February 10, 2023 10:50 AM
>>> To: Arend van Spriel <[email protected]>; Franky Lin
>>> <[email protected]>; Hante Meuleman
>>> <[email protected]>; Kalle Valo <[email protected]>; David S.
>>> Miller <[email protected]>; Eric
>>> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo
>>> Abeni <[email protected]>
>>> Cc: Alexander Prutskov <[email protected]>; Chi-Hsien Lin
>>> <[email protected]>; Wright Feng
>>> <[email protected]>; Ian Lin <[email protected]>; Soontak Lee
>>> <[email protected]>; Joseph
>>> chuang <[email protected]>; Sven Peter <[email protected]>; Alyssa
>>> Rosenzweig <[email protected]>;
>>> Aditya Garg <[email protected]>; Jonas Gorski <[email protected]>;
>>> [email protected];
>>> [email protected]; [email protected];
>>> [email protected];
>>> [email protected]; [email protected]; Hector Martin
>>> <[email protected]>; Arend van Spriel
>>> <[email protected]>
>>> Subject: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
>>>
>>> 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.
>>>
>>> v3: Drop the RAW device ID in this commit. We don't do this for the
>>> other chips since apparently some devices with them exist in the wild,
>>> but there is already a 4355 entry with the Broadcom subvendor and WCC
>>> firmware vendor, so adding a generic fallback to Cypress seems
>>> redundant (no reason why a device would have the raw device ID *and* an
>>> explicitly programmed subvendor).
>>
>> Do you really want to add changes of v2 and v3 to commit message? Or,
>> just want to let reviewers know that? If latter one is what you want,
>> move them after s-o-b with delimiter ---
>
> Both; I thought those things were worth mentioning in the commit message
> as it stands on its own, and left the version tags in so reviewers know
> when they were introduced.
The commit message is documenting what we end up with post reviewing so
patch versions are meaningless there. Of course useful information that
came up in review cycles should end up in the commit message.
Regards,
Arend
On 11/02/2023 20.23, Arend Van Spriel wrote:
> On February 11, 2023 11:09:02 AM Hector Martin <[email protected]> wrote:
>
>> On 10/02/2023 12.42, Ping-Ke Shih wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Hector Martin <[email protected]>
>>>> Sent: Friday, February 10, 2023 10:50 AM
>>>> To: Arend van Spriel <[email protected]>; Franky Lin
>>>> <[email protected]>; Hante Meuleman
>>>> <[email protected]>; Kalle Valo <[email protected]>; David S.
>>>> Miller <[email protected]>; Eric
>>>> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo
>>>> Abeni <[email protected]>
>>>> Cc: Alexander Prutskov <[email protected]>; Chi-Hsien Lin
>>>> <[email protected]>; Wright Feng
>>>> <[email protected]>; Ian Lin <[email protected]>; Soontak Lee
>>>> <[email protected]>; Joseph
>>>> chuang <[email protected]>; Sven Peter <[email protected]>; Alyssa
>>>> Rosenzweig <[email protected]>;
>>>> Aditya Garg <[email protected]>; Jonas Gorski <[email protected]>;
>>>> [email protected];
>>>> [email protected]; [email protected];
>>>> [email protected];
>>>> [email protected]; [email protected]; Hector Martin
>>>> <[email protected]>; Arend van Spriel
>>>> <[email protected]>
>>>> Subject: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
>>>>
>>>> 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.
>>>>
>>>> v3: Drop the RAW device ID in this commit. We don't do this for the
>>>> other chips since apparently some devices with them exist in the wild,
>>>> but there is already a 4355 entry with the Broadcom subvendor and WCC
>>>> firmware vendor, so adding a generic fallback to Cypress seems
>>>> redundant (no reason why a device would have the raw device ID *and* an
>>>> explicitly programmed subvendor).
>>>
>>> Do you really want to add changes of v2 and v3 to commit message? Or,
>>> just want to let reviewers know that? If latter one is what you want,
>>> move them after s-o-b with delimiter ---
>>
>> Both; I thought those things were worth mentioning in the commit message
>> as it stands on its own, and left the version tags in so reviewers know
>> when they were introduced.
>
> The commit message is documenting what we end up with post reviewing so
> patch versions are meaningless there. Of course useful information that
> came up in review cycles should end up in the commit message.
>
Do you really want me to respin this again just to remove 8 characters
from the commit message? I know it doesn't have much meaning post review
but it's not unheard of either, grep git logs and you'll find plenty of
examples.
- Hector
> On 11-Feb-2023, at 6:16 PM, Hector Martin <[email protected]> wrote:
>
> On 11/02/2023 20.23, Arend Van Spriel wrote:
>>> On February 11, 2023 11:09:02 AM Hector Martin <[email protected]> wrote:
>>>
>>> On 10/02/2023 12.42, Ping-Ke Shih wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Hector Martin <[email protected]>
>>>>> Sent: Friday, February 10, 2023 10:50 AM
>>>>> To: Arend van Spriel <[email protected]>; Franky Lin
>>>>> <[email protected]>; Hante Meuleman
>>>>> <[email protected]>; Kalle Valo <[email protected]>; David S.
>>>>> Miller <[email protected]>; Eric
>>>>> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo
>>>>> Abeni <[email protected]>
>>>>> Cc: Alexander Prutskov <[email protected]>; Chi-Hsien Lin
>>>>> <[email protected]>; Wright Feng
>>>>> <[email protected]>; Ian Lin <[email protected]>; Soontak Lee
>>>>> <[email protected]>; Joseph
>>>>> chuang <[email protected]>; Sven Peter <[email protected]>; Alyssa
>>>>> Rosenzweig <[email protected]>;
>>>>> Aditya Garg <[email protected]>; Jonas Gorski <[email protected]>;
>>>>> [email protected];
>>>>> [email protected]; [email protected];
>>>>> [email protected];
>>>>> [email protected]; [email protected]; Hector Martin
>>>>> <[email protected]>; Arend van Spriel
>>>>> <[email protected]>
>>>>> Subject: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
>>>>>
>>>>> 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.
>>>>>
>>>>> v3: Drop the RAW device ID in this commit. We don't do this for the
>>>>> other chips since apparently some devices with them exist in the wild,
>>>>> but there is already a 4355 entry with the Broadcom subvendor and WCC
>>>>> firmware vendor, so adding a generic fallback to Cypress seems
>>>>> redundant (no reason why a device would have the raw device ID *and* an
>>>>> explicitly programmed subvendor).
>>>>
>>>> Do you really want to add changes of v2 and v3 to commit message? Or,
>>>> just want to let reviewers know that? If latter one is what you want,
>>>> move them after s-o-b with delimiter ---
>>>
>>> Both; I thought those things were worth mentioning in the commit message
>>> as it stands on its own, and left the version tags in so reviewers know
>>> when they were introduced.
>>
>> The commit message is documenting what we end up with post reviewing so
>> patch versions are meaningless there. Of course useful information that
>> came up in review cycles should end up in the commit message.
>>
>
> Do you really want me to respin this again just to remove 8 characters
> from the commit message? I know it doesn't have much meaning post review
> but it's not unheard of either, grep git logs and you'll find plenty of
> examples.
>
> - Hector
Adding to that, I guess the maintainers can do a bit on their part. Imao it’s
really frustrating preparing the same patch again and again, especially for
bits like these.
On February 11, 2023 1:50:00 PM Aditya Garg <[email protected]> wrote:
>> On 11-Feb-2023, at 6:16 PM, Hector Martin <[email protected]> wrote:
>>
>> On 11/02/2023 20.23, Arend Van Spriel wrote:
>>>> On February 11, 2023 11:09:02 AM Hector Martin <[email protected]> wrote:
>>>>
>>>> On 10/02/2023 12.42, Ping-Ke Shih wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Hector Martin <[email protected]>
>>>>>> Sent: Friday, February 10, 2023 10:50 AM
>>>>>> To: Arend van Spriel <[email protected]>; Franky Lin
>>>>>> <[email protected]>; Hante Meuleman
>>>>>> <[email protected]>; Kalle Valo <[email protected]>; David S.
>>>>>> Miller <[email protected]>; Eric
>>>>>> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo
>>>>>> Abeni <[email protected]>
>>>>>> Cc: Alexander Prutskov <[email protected]>; Chi-Hsien Lin
>>>>>> <[email protected]>; Wright Feng
>>>>>> <[email protected]>; Ian Lin <[email protected]>; Soontak Lee
>>>>>> <[email protected]>; Joseph
>>>>>> chuang <[email protected]>; Sven Peter <[email protected]>; Alyssa
>>>>>> Rosenzweig <[email protected]>;
>>>>>> Aditya Garg <[email protected]>; Jonas Gorski <[email protected]>;
>>>>>> [email protected];
>>>>>> [email protected]; [email protected];
>>>>>> [email protected];
>>>>>> [email protected]; [email protected]; Hector Martin
>>>>>> <[email protected]>; Arend van Spriel
>>>>>> <[email protected]>
>>>>>> Subject: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> v3: Drop the RAW device ID in this commit. We don't do this for the
>>>>>> other chips since apparently some devices with them exist in the wild,
>>>>>> but there is already a 4355 entry with the Broadcom subvendor and WCC
>>>>>> firmware vendor, so adding a generic fallback to Cypress seems
>>>>>> redundant (no reason why a device would have the raw device ID *and* an
>>>>>> explicitly programmed subvendor).
>>>>>
>>>>> Do you really want to add changes of v2 and v3 to commit message? Or,
>>>>> just want to let reviewers know that? If latter one is what you want,
>>>>> move them after s-o-b with delimiter ---
>>>>
>>>> Both; I thought those things were worth mentioning in the commit message
>>>> as it stands on its own, and left the version tags in so reviewers know
>>>> when they were introduced.
>>>
>>> The commit message is documenting what we end up with post reviewing so
>>> patch versions are meaningless there. Of course useful information that
>>> came up in review cycles should end up in the commit message.
>>
>> Do you really want me to respin this again just to remove 8 characters
>> from the commit message? I know it doesn't have much meaning post review
>> but it's not unheard of either, grep git logs and you'll find plenty of
>> examples.
>>
>> - Hector
>
> Adding to that, I guess the maintainers can do a bit on their part. Imao it’s
> really frustrating preparing the same patch again and again, especially for
> bits like these.
Frustrating? I am sure that maintainers have another view on that when they
have to mention the same type of submission errors again and again. That's
why there is a wireless wiki page on the subject:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
If Kalle is willing to cleanup the commit message in the current patch you
are lucky. You are free to ask. Otherwise it should be not too much trouble
resubmitting it.
Regards,
Arend
On 11/02/2023 23.00, Arend Van Spriel wrote:
> On February 11, 2023 1:50:00 PM Aditya Garg <[email protected]> wrote:
>
>>> On 11-Feb-2023, at 6:16 PM, Hector Martin <[email protected]> wrote:
>>>
>>> On 11/02/2023 20.23, Arend Van Spriel wrote:
>>>>> On February 11, 2023 11:09:02 AM Hector Martin <[email protected]> wrote:
>>>>>
>>>>> On 10/02/2023 12.42, Ping-Ke Shih wrote:
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Hector Martin <[email protected]>
>>>>>>> Sent: Friday, February 10, 2023 10:50 AM
>>>>>>> To: Arend van Spriel <[email protected]>; Franky Lin
>>>>>>> <[email protected]>; Hante Meuleman
>>>>>>> <[email protected]>; Kalle Valo <[email protected]>; David S.
>>>>>>> Miller <[email protected]>; Eric
>>>>>>> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo
>>>>>>> Abeni <[email protected]>
>>>>>>> Cc: Alexander Prutskov <[email protected]>; Chi-Hsien Lin
>>>>>>> <[email protected]>; Wright Feng
>>>>>>> <[email protected]>; Ian Lin <[email protected]>; Soontak Lee
>>>>>>> <[email protected]>; Joseph
>>>>>>> chuang <[email protected]>; Sven Peter <[email protected]>; Alyssa
>>>>>>> Rosenzweig <[email protected]>;
>>>>>>> Aditya Garg <[email protected]>; Jonas Gorski <[email protected]>;
>>>>>>> [email protected];
>>>>>>> [email protected]; [email protected];
>>>>>>> [email protected];
>>>>>>> [email protected]; [email protected]; Hector Martin
>>>>>>> <[email protected]>; Arend van Spriel
>>>>>>> <[email protected]>
>>>>>>> Subject: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> v3: Drop the RAW device ID in this commit. We don't do this for the
>>>>>>> other chips since apparently some devices with them exist in the wild,
>>>>>>> but there is already a 4355 entry with the Broadcom subvendor and WCC
>>>>>>> firmware vendor, so adding a generic fallback to Cypress seems
>>>>>>> redundant (no reason why a device would have the raw device ID *and* an
>>>>>>> explicitly programmed subvendor).
>>>>>>
>>>>>> Do you really want to add changes of v2 and v3 to commit message? Or,
>>>>>> just want to let reviewers know that? If latter one is what you want,
>>>>>> move them after s-o-b with delimiter ---
>>>>>
>>>>> Both; I thought those things were worth mentioning in the commit message
>>>>> as it stands on its own, and left the version tags in so reviewers know
>>>>> when they were introduced.
>>>>
>>>> The commit message is documenting what we end up with post reviewing so
>>>> patch versions are meaningless there. Of course useful information that
>>>> came up in review cycles should end up in the commit message.
>>>
>>> Do you really want me to respin this again just to remove 8 characters
>>> from the commit message? I know it doesn't have much meaning post review
>>> but it's not unheard of either, grep git logs and you'll find plenty of
>>> examples.
>>>
>>> - Hector
>>
>> Adding to that, I guess the maintainers can do a bit on their part. Imao it’s
>> really frustrating preparing the same patch again and again, especially for
>> bits like these.
>
> Frustrating? I am sure that maintainers have another view on that when they
> have to mention the same type of submission errors again and again. That's
> why there is a wireless wiki page on the subject:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Which does not mention this particular issue as far as I can tell. How
exactly is this a "submission error"? Neither you nor Kalle pointed it
out through two revisions, only a drive-by reviewer did.
> If Kalle is willing to cleanup the commit message in the current patch you
> are lucky. You are free to ask. Otherwise it should be not too much trouble
> resubmitting it.
It's even less trouble to just take it as is, since an extra "v2: " in
the commit message doesn't hurt anyone other than those who choose to be
hurt by it. And as I said there's *tons* of commits with a changelog
like this in Linux. It's not uncommon.
I swear, some maintainers seem to take a perverse delight in making
things as painful as possible for submitters, even when there is
approximately zero benefit to the end result. And I say this as a
maintainer myself.
Maybe y'all should be the ones feeling lucky that so many people are
willing to put up with all this bullshit to get things upstreamed to
Linux. It's literally the worst open source project to upstream things
to, by a *very long* shot. I'll respin a v4 if I must, but but it's.
Just. This. Kind. Of. Nonsense. Every. Single. Time. And. Every. Single.
Time. It's. Something. Different. This stuff burns people out and
discourages submissions and turns huge numbers of people off from ever
contributing to Linux, and you all need to seriously be aware of that.
- Hector
On 2/11/2023 8:15 PM, Hector Martin wrote:
> On 11/02/2023 23.00, Arend Van Spriel wrote:
>> On February 11, 2023 1:50:00 PM Aditya Garg <[email protected]> wrote:
>>
>>>> On 11-Feb-2023, at 6:16 PM, Hector Martin <[email protected]> wrote:
>>>>
>>>> On 11/02/2023 20.23, Arend Van Spriel wrote:
>>>>>> On February 11, 2023 11:09:02 AM Hector Martin <[email protected]> wrote:
>>>>>>
>>>>>> On 10/02/2023 12.42, Ping-Ke Shih wrote:
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Hector Martin <[email protected]>
>>>>>>>> Sent: Friday, February 10, 2023 10:50 AM
>>>>>>>> To: Arend van Spriel <[email protected]>; Franky Lin
>>>>>>>> <[email protected]>; Hante Meuleman
>>>>>>>> <[email protected]>; Kalle Valo <[email protected]>; David S.
>>>>>>>> Miller <[email protected]>; Eric
>>>>>>>> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo
>>>>>>>> Abeni <[email protected]>
>>>>>>>> Cc: Alexander Prutskov <[email protected]>; Chi-Hsien Lin
>>>>>>>> <[email protected]>; Wright Feng
>>>>>>>> <[email protected]>; Ian Lin <[email protected]>; Soontak Lee
>>>>>>>> <[email protected]>; Joseph
>>>>>>>> chuang <[email protected]>; Sven Peter <[email protected]>; Alyssa
>>>>>>>> Rosenzweig <[email protected]>;
>>>>>>>> Aditya Garg <[email protected]>; Jonas Gorski <[email protected]>;
>>>>>>>> [email protected];
>>>>>>>> [email protected]; [email protected];
>>>>>>>> [email protected];
>>>>>>>> [email protected]; [email protected]; Hector Martin
>>>>>>>> <[email protected]>; Arend van Spriel
>>>>>>>> <[email protected]>
>>>>>>>> Subject: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> v3: Drop the RAW device ID in this commit. We don't do this for the
>>>>>>>> other chips since apparently some devices with them exist in the wild,
>>>>>>>> but there is already a 4355 entry with the Broadcom subvendor and WCC
>>>>>>>> firmware vendor, so adding a generic fallback to Cypress seems
>>>>>>>> redundant (no reason why a device would have the raw device ID *and* an
>>>>>>>> explicitly programmed subvendor).
>>>>>>>
>>>>>>> Do you really want to add changes of v2 and v3 to commit message? Or,
>>>>>>> just want to let reviewers know that? If latter one is what you want,
>>>>>>> move them after s-o-b with delimiter ---
>>>>>>
>>>>>> Both; I thought those things were worth mentioning in the commit message
>>>>>> as it stands on its own, and left the version tags in so reviewers know
>>>>>> when they were introduced.
>>>>>
>>>>> The commit message is documenting what we end up with post reviewing so
>>>>> patch versions are meaningless there. Of course useful information that
>>>>> came up in review cycles should end up in the commit message.
>>>>
>>>> Do you really want me to respin this again just to remove 8 characters
>>>> from the commit message? I know it doesn't have much meaning post review
>>>> but it's not unheard of either, grep git logs and you'll find plenty of
>>>> examples.
>>>>
>>>> - Hector
>>>
>>> Adding to that, I guess the maintainers can do a bit on their part. Imao it’s
>>> really frustrating preparing the same patch again and again, especially for
>>> bits like these.
>>
>> Frustrating? I am sure that maintainers have another view on that when they
>> have to mention the same type of submission errors again and again. That's
>> why there is a wireless wiki page on the subject:
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
> Which does not mention this particular issue as far as I can tell. How
> exactly is this a "submission error"? Neither you nor Kalle pointed it
> out through two revisions, only a drive-by reviewer did.
It does mention how to provide the changelog and I would have guessed
you were smart enough to see the reason behind it. It is a bit lame to
say it is not mentioned.
>> If Kalle is willing to cleanup the commit message in the current patch you
>> are lucky. You are free to ask. Otherwise it should be not too much trouble
>> resubmitting it.
>
> It's even less trouble to just take it as is, since an extra "v2: " in
> the commit message doesn't hurt anyone other than those who choose to be
> hurt by it. And as I said there's *tons* of commits with a changelog
> like this in Linux. It's not uncommon.
>
> I swear, some maintainers seem to take a perverse delight in making
> things as painful as possible for submitters, even when there is
> approximately zero benefit to the end result. And I say this as a
> maintainer myself.
>
> Maybe y'all should be the ones feeling lucky that so many people are
> willing to put up with all this bullshit to get things upstreamed to
> Linux. It's literally the worst open source project to upstream things
> to, by a *very long* shot. I'll respin a v4 if I must, but but it's.
> Just. This. Kind. Of. Nonsense. Every. Single. Time. And. Every. Single.
> Time. It's. Something. Different. This stuff burns people out and
> discourages submissions and turns huge numbers of people off from ever
> contributing to Linux, and you all need to seriously be aware of that.
I leave this to Kalle. Personally I do not have a problem with it, but
the drive-by reviewer, Ping-Ke Shih, did have a point and respinning a
patch series really is not a big effort. In 30+ years of programming I
have been annoyed many times about seemingly trivial review comments or
straight bullshit remarks or even solid remarks, but you learn to
swallow that, make the changes, and move forward. Don't get discouraged.
Regards,
Arend
> -----Original Message-----
> From: Hector Martin <[email protected]>
> Sent: Saturday, February 11, 2023 6:09 PM
> To: Ping-Ke Shih <[email protected]>; Arend van Spriel <[email protected]>; Franky Lin
> <[email protected]>; Hante Meuleman <[email protected]>; Kalle Valo <[email protected]>;
> David S. Miller <[email protected]>; Eric Dumazet <[email protected]>; Jakub Kicinski
> <[email protected]>; Paolo Abeni <[email protected]>
> Cc: Alexander Prutskov <[email protected]>; Chi-Hsien Lin <[email protected]>; Wright Feng
> <[email protected]>; Ian Lin <[email protected]>; Soontak Lee <[email protected]>; Joseph
> chuang <[email protected]>; Sven Peter <[email protected]>; Alyssa Rosenzweig <[email protected]>;
> Aditya Garg <[email protected]>; Jonas Gorski <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Arend van Spriel <[email protected]>
> Subject: Re: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
>
> On 10/02/2023 12.42, Ping-Ke Shih wrote:
> >
> >
> >> -----Original Message-----
> >> From: Hector Martin <[email protected]>
> >> Sent: Friday, February 10, 2023 10:50 AM
> >> To: Arend van Spriel <[email protected]>; Franky Lin <[email protected]>; Hante Meuleman
> >> <[email protected]>; Kalle Valo <[email protected]>; David S. Miller <[email protected]>;
> Eric
> >> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo Abeni <[email protected]>
> >> Cc: Alexander Prutskov <[email protected]>; Chi-Hsien Lin <[email protected]>; Wright Feng
> >> <[email protected]>; Ian Lin <[email protected]>; Soontak Lee <[email protected]>;
> Joseph
> >> chuang <[email protected]>; Sven Peter <[email protected]>; Alyssa Rosenzweig <[email protected]>;
> >> Aditya Garg <[email protected]>; Jonas Gorski <[email protected]>; [email protected];
> >> [email protected]; [email protected];
> [email protected];
> >> [email protected]; [email protected]; Hector Martin <[email protected]>; Arend van
> Spriel
> >> <[email protected]>
> >> Subject: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
> >>
> >> 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.
> >>
> >> v3: Drop the RAW device ID in this commit. We don't do this for the
> >> other chips since apparently some devices with them exist in the wild,
> >> but there is already a 4355 entry with the Broadcom subvendor and WCC
> >> firmware vendor, so adding a generic fallback to Cypress seems
> >> redundant (no reason why a device would have the raw device ID *and* an
> >> explicitly programmed subvendor).
> >
> > Do you really want to add changes of v2 and v3 to commit message? Or,
> > just want to let reviewers know that? If latter one is what you want,
> > move them after s-o-b with delimiter ---
>
> Both; I thought those things were worth mentioning in the commit message
> as it stands on its own, and left the version tags in so reviewers know
> when they were introduced.
>
With this reply, it is clear that you did those intentionally, not forgot
something, so things are clear to me. The further discussion in different
aspects of view in thread are also helpful for me to get much.
Ping-Ke
Hector Martin <[email protected]> writes:
>> If Kalle is willing to cleanup the commit message in the current patch you
>> are lucky. You are free to ask. Otherwise it should be not too much trouble
>> resubmitting it.
FWIW I can edit commit logs as long as the changes are simple and the
edit instructions are clear, ie. it takes no more than a minute for me
to do the edit.
> It's even less trouble to just take it as is, since an extra "v2: " in
> the commit message doesn't hurt anyone other than those who choose to be
> hurt by it. And as I said there's *tons* of commits with a changelog
> like this in Linux. It's not uncommon.
>
> I swear, some maintainers seem to take a perverse delight in making
> things as painful as possible for submitters, even when there is
> approximately zero benefit to the end result. And I say this as a
> maintainer myself.
>
> Maybe y'all should be the ones feeling lucky that so many people are
> willing to put up with all this bullshit to get things upstreamed to
> Linux. It's literally the worst open source project to upstream things
> to, by a *very long* shot. I'll respin a v4 if I must, but but it's.
> Just. This. Kind. Of. Nonsense. Every. Single. Time. And. Every. Single.
> Time. It's. Something. Different. This stuff burns people out and
> discourages submissions and turns huge numbers of people off from ever
> contributing to Linux, and you all need to seriously be aware of that.
I understand it's frustrating but please also try understand us
maintainers. For example, I have 150 patches in patchwork right now. So
it's not easy for us maintainers either, far from it.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On Fri, 10 Feb 2023 at 02:59, Hector Martin <[email protected]> wrote:
>
> 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.
>
> v3: Drop the RAW device ID in this commit. We don't do this for the
> other chips since apparently some devices with them exist in the wild,
> but there is already a 4355 entry with the Broadcom subvendor and WCC
> firmware vendor, so adding a generic fallback to Cypress seems
> redundant (no reason why a device would have the raw device ID *and* an
> explicitly programmed subvendor).
>
> Fixes: dce45ded7619 ("brcmfmac: Support 89459 pcie")
> Reviewed-by: Arend van Spriel <[email protected]>
> Signed-off-by: Hector Martin <[email protected]>
LGTM
Reviewed-by: Eric Curtin <[email protected]>
Is mise le meas/Regards,
Eric Curtin
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 5 ++---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 7 +++----
> .../net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 5 ++---
> 3 files changed, 7 insertions(+), 10 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 ae57a9a3ab05..96608174a123 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 */
> @@ -2609,9 +2609,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),
> - 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..28b6cf8ff286 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
> @@ -90,9 +90,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
> -#define CY_PCIE_89459_RAW_DEVICE_ID 0x4355
>
> /* brcmsmac IDs */
> #define BCM4313_D11N2G_ID 0x4727 /* 4313 802.11n 2.4G device */
> --
> 2.35.1
>
>