Since kernel 6.1, Wi-Fi is failing to work on Macs with the BCM4364 rev 3 chips and journalctl reports that the firmware has crashed.
The complete journalctl is given here :- https://gist.github.com/AdityaGarg8/a25b187e7f1462798de87e048f4840db
This bug has been reported by users of iMac19,1 as well as Macmini8,1.
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; all text you find below is based on a few templates
paragraphs you might have encountered already already in similar form.
See link in footer if these mails annoy you.]
On 02.01.23 08:46, Aditya Garg wrote:
> Since kernel 6.1, Wi-Fi is failing to work on Macs with the BCM4364 rev 3 chips and journalctl reports that the firmware has crashed.
>
> The complete journalctl is given here :- https://gist.github.com/AdityaGarg8/a25b187e7f1462798de87e048f4840db
>
> This bug has been reported by users of iMac19,1 as well as Macmini8,1.
Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:
#regzbot ^introduced v6.0..v6.1
#regzbot title net: brcmfmac: Wi-Fi is failing to work on Macs with the
BCM4364 rev 3 chips
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.
Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (see page linked in footer for details).
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
Annoyed by mails like this? Feel free to send them to /dev/null:
https://linux-regtracking.leemhuis.info/about/#infomails
On 2023/01/02 16:46, Aditya Garg wrote:
> Since kernel 6.1, Wi-Fi is failing to work on Macs with the BCM4364 rev 3 chips and journalctl reports that the firmware has crashed.
>
> The complete journalctl is given here :- https://gist.github.com/AdityaGarg8/a25b187e7f1462798de87e048f4840db
>
> This bug has been reported by users of iMac19,1 as well as Macmini8,1.
You are using a downstream patched tree, specifically one with further
Broadcom patches not yet upstream from my Asahi Linux tree and probably
others.
Please do not spam upstream developers with issues from downstream
trees. If you have an issue with my tree, you can report it on GitHub.
If you are using another tree, report it to its maintainer. If you can
reproduce this with *vanilla* 6.1 then you can report it upstream.
- Hector
> You are using a downstream patched tree, specifically one with further
> Broadcom patches not yet upstream from my Asahi Linux tree and probably
> others.
>
> Please do not spam upstream developers with issues from downstream
> trees. If you have an issue with my tree, you can report it on GitHub.
> If you are using another tree, report it to its maintainer. If you can
> reproduce this with *vanilla* 6.1 then you can report it upstream.
>
> - Hector
I am sorry for the same Hector, but I sent that cause bcm4364 wifi chip is already supported upstream. If I ain't wrong, don't the Asahi Linux patches provide OTP support only for these chips?
On 2023/01/02 17:57, Aditya Garg wrote:
>
>> You are using a downstream patched tree, specifically one with further
>> Broadcom patches not yet upstream from my Asahi Linux tree and probably
>> others.
>>
>> Please do not spam upstream developers with issues from downstream
>> trees. If you have an issue with my tree, you can report it on GitHub.
>> If you are using another tree, report it to its maintainer. If you can
>> reproduce this with *vanilla* 6.1 then you can report it upstream.
>>
>> - Hector
>
> I am sorry for the same Hector, but I sent that cause bcm4364 wifi chip is already supported upstream. If I ain't wrong, don't the Asahi Linux patches provide OTP support only for these chips?
There are a pile of Broadcom patches in our tree and there is no way to
eliminate them as the cause a priori. If you think this regressed
upstream, then test it with upstream Linux 6.1 and find out.
As I mentioned to you on Discord previously, please bisect this to a
specific commit so we can do something about it. I don't have the
hardware and there's nothing I can do with a "the firmware is crashing
now" report until you at least tell me what commit caused the problem so
I can take a stab at identifying the root cause.
- Hector
On 02.01.23 09:21, Linux kernel regression tracking (#info) wrote:
> [TLDR: I'm adding this report to the list of tracked Linux kernel
> regressions; all text you find below is based on a few templates
> paragraphs you might have encountered already already in similar form.
> See link in footer if these mails annoy you.]
>
> On 02.01.23 08:46, Aditya Garg wrote:
>> Since kernel 6.1, Wi-Fi is failing to work on Macs with the BCM4364 rev 3 chips and journalctl reports that the firmware has crashed.
>>
>> The complete journalctl is given here :- https://gist.github.com/AdityaGarg8/a25b187e7f1462798de87e048f4840db
>>
>> This bug has been reported by users of iMac19,1 as well as Macmini8,1.
>
> Thanks for the report. To be sure the issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
> tracking bot:
>
> #regzbot ^introduced v6.0..v6.1
> #regzbot title net: brcmfmac: Wi-Fi is failing to work on Macs with the
> BCM4364 rev 3 chips
> #regzbot ignore-activity
#regzbot inconclusive: problem happens with a downstream tree that
patched this driver, hence might not be a upstream issue
Sorry for the noise, that wasn't obvious from the report.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
Did I miss something or do something stupid? Then reply and tell me:
https://linux-regtracking.leemhuis.info/about/#stupid
From: Aditya Garg <[email protected]>
Commit 'dce45ded7619' added support for 89459 chip pcie device. It uses the
BRCM4355 chip which is also found in Apple hardware. However this commit
causes conflicts in the firmware naming between Apple hardware, which
supports OTP and other non-Apple hardwares. So, this patch makes these
Apple chips use their own firmware table so as to avoid possible conflicts
like these in the future.
Signed-off-by: Aditya Garg <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/pcie.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index ae57a9a3a..ad7a780cd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -92,10 +92,13 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43664_CHIP_ID, 0xFFFFFFF0, 4366C),
BRCMF_FW_ENTRY(BRCM_CC_43666_CHIP_ID, 0xFFFFFFF0, 4366C),
BRCMF_FW_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371),
- BRCMF_FW_ENTRY(BRCM_CC_4378_CHIP_ID, 0xFFFFFFFF, 4378B1), /* revision ID 3 */
BRCMF_FW_ENTRY(CY_CC_89459_CHIP_ID, 0xFFFFFFFF, 4355),
};
+static const struct brcmf_firmware_mapping brcmf_pcie_otp_fwnames[] = {
+ BRCMF_FW_ENTRY(BRCM_CC_4378_CHIP_ID, 0xFFFFFFFF, 4378B1), /* revision ID 3 */
+};
+
#define BRCMF_PCIE_FW_UP_TIMEOUT 5000 /* msec */
#define BRCMF_PCIE_REG_MAP_SIZE (32 * 1024)
@@ -2165,10 +2168,16 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo)
{ ".clm_blob", devinfo->clm_name },
};
- fwreq = brcmf_fw_alloc_request(devinfo->ci->chip, devinfo->ci->chiprev,
- brcmf_pcie_fwnames,
- ARRAY_SIZE(brcmf_pcie_fwnames),
- fwnames, ARRAY_SIZE(fwnames));
+ if (devinfo->otp.valid)
+ fwreq = brcmf_fw_alloc_request(devinfo->ci->chip, devinfo->ci->chiprev,
+ brcmf_pcie_otp_fwnames,
+ ARRAY_SIZE(brcmf_pcie_otp_fwnames),
+ fwnames, ARRAY_SIZE(fwnames));
+ else
+ fwreq = brcmf_fw_alloc_request(devinfo->ci->chip, devinfo->ci->chiprev,
+ brcmf_pcie_fwnames,
+ ARRAY_SIZE(brcmf_pcie_fwnames),
+ fwnames, ARRAY_SIZE(fwnames));
if (!fwreq)
return NULL;
--
2.34.1
From: Aditya Garg <[email protected]>
Commit 'dce45ded7619' added the BCM4355 chip support. This chip is also
found in MacBookAir8,1 and MacBookAir8,2. This patch adds necessary pcie
IDs to add support for the same.
Signed-off-by: Aditya Garg <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 4 ++--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 3 ++-
drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 3 ++-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 121893bba..2f338c5d9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -735,7 +735,7 @@ 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:
+ case BRCM_CC_4355_CHIP_ID:
return ((ci->pub.chiprev < 9) ? 0x180000 : 0x160000);
default:
brcmf_err("unknown chip: %s\n", ci->pub.name);
@@ -1427,7 +1427,7 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
reg = chip->ops->read32(chip->ctx, addr);
return reg != 0;
case CY_CC_4373_CHIP_ID:
- case CY_CC_89459_CHIP_ID:
+ case BRCM_CC_4355_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 ad7a780cd..0a7410196 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -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),
@@ -92,7 +93,6 @@ 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(CY_CC_89459_CHIP_ID, 0xFFFFFFFF, 4355),
};
static const struct brcmf_firmware_mapping brcmf_pcie_otp_fwnames[] = {
@@ -2599,6 +2599,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 f4939cf62..fee1ff526 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
@@ -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.34.1
> On 02-Jan-2023, at 8:10 PM, Aditya Garg <[email protected]> wrote:
>
> From: Aditya Garg <[email protected]>
>
> Commit 'dce45ded7619' added the BCM4355 chip support. This chip is also
> found in MacBookAir8,1 and MacBookAir8,2. This patch adds necessary pcie
> IDs to add support for the same.
>
> Signed-off-by: Aditya Garg <[email protected]>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 4 ++--
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 3 ++-
> drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 3 ++-
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> index 121893bba..2f338c5d9 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> @@ -735,7 +735,7 @@ 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:
> + case BRCM_CC_4355_CHIP_ID:
> return ((ci->pub.chiprev < 9) ? 0x180000 : 0x160000);
> default:
> brcmf_err("unknown chip: %s\n", ci->pub.name);
> @@ -1427,7 +1427,7 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
> reg = chip->ops->read32(chip->ctx, addr);
> return reg != 0;
> case CY_CC_4373_CHIP_ID:
> - case CY_CC_89459_CHIP_ID:
> + case BRCM_CC_4355_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 ad7a780cd..0a7410196 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -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)
Oops, forgot to add a comma here, sending a v2
> 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),
> @@ -92,7 +93,6 @@ 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(CY_CC_89459_CHIP_ID, 0xFFFFFFFF, 4355),
> };
>
> static const struct brcmf_firmware_mapping brcmf_pcie_otp_fwnames[] = {
> @@ -2599,6 +2599,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 f4939cf62..fee1ff526 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
> @@ -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.34.1
>
From: Aditya Garg <[email protected]>
Commit 'dce45ded7619' added support for 89459 chip pcie device. It uses the
BRCM4355 chip which is also found in Apple hardware. However this commit
causes conflicts in the firmware naming between Apple hardware, which
supports OTP and other non-Apple hardwares. So, this patch makes these
Apple chips use their own firmware table so as to avoid possible conflicts
like these in the future.
Signed-off-by: Aditya Garg <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/pcie.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index ae57a9a3a..ad7a780cd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -92,10 +92,13 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43664_CHIP_ID, 0xFFFFFFF0, 4366C),
BRCMF_FW_ENTRY(BRCM_CC_43666_CHIP_ID, 0xFFFFFFF0, 4366C),
BRCMF_FW_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371),
- BRCMF_FW_ENTRY(BRCM_CC_4378_CHIP_ID, 0xFFFFFFFF, 4378B1), /* revision ID 3 */
BRCMF_FW_ENTRY(CY_CC_89459_CHIP_ID, 0xFFFFFFFF, 4355),
};
+static const struct brcmf_firmware_mapping brcmf_pcie_otp_fwnames[] = {
+ BRCMF_FW_ENTRY(BRCM_CC_4378_CHIP_ID, 0xFFFFFFFF, 4378B1), /* revision ID 3 */
+};
+
#define BRCMF_PCIE_FW_UP_TIMEOUT 5000 /* msec */
#define BRCMF_PCIE_REG_MAP_SIZE (32 * 1024)
@@ -2165,10 +2168,16 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo)
{ ".clm_blob", devinfo->clm_name },
};
- fwreq = brcmf_fw_alloc_request(devinfo->ci->chip, devinfo->ci->chiprev,
- brcmf_pcie_fwnames,
- ARRAY_SIZE(brcmf_pcie_fwnames),
- fwnames, ARRAY_SIZE(fwnames));
+ if (devinfo->otp.valid)
+ fwreq = brcmf_fw_alloc_request(devinfo->ci->chip, devinfo->ci->chiprev,
+ brcmf_pcie_otp_fwnames,
+ ARRAY_SIZE(brcmf_pcie_otp_fwnames),
+ fwnames, ARRAY_SIZE(fwnames));
+ else
+ fwreq = brcmf_fw_alloc_request(devinfo->ci->chip, devinfo->ci->chiprev,
+ brcmf_pcie_fwnames,
+ ARRAY_SIZE(brcmf_pcie_fwnames),
+ fwnames, ARRAY_SIZE(fwnames));
if (!fwreq)
return NULL;
--
2.34.1
From: Aditya Garg <[email protected]>
Commit 'dce45ded7619' added the BCM4355 chip support. This chip is also
found in MacBookAir8,1 and MacBookAir8,2. This patch adds necessary pcie
IDs to add support for the same.
Signed-off-by: Aditya Garg <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 4 ++--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 3 ++-
drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 3 ++-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 121893bba..2f338c5d9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -735,7 +735,7 @@ 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:
+ case BRCM_CC_4355_CHIP_ID:
return ((ci->pub.chiprev < 9) ? 0x180000 : 0x160000);
default:
brcmf_err("unknown chip: %s\n", ci->pub.name);
@@ -1427,7 +1427,7 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
reg = chip->ops->read32(chip->ctx, addr);
return reg != 0;
case CY_CC_4373_CHIP_ID:
- case CY_CC_89459_CHIP_ID:
+ case BRCM_CC_4355_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 ad7a780cd..0a7410196 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -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),
@@ -92,7 +93,6 @@ 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(CY_CC_89459_CHIP_ID, 0xFFFFFFFF, 4355),
};
static const struct brcmf_firmware_mapping brcmf_pcie_otp_fwnames[] = {
@@ -2599,6 +2599,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 f4939cf62..fee1ff526 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
@@ -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.34.1
On 02/01/2023 23.40, Aditya Garg wrote:
> From: Aditya Garg <[email protected]>
>
> Commit 'dce45ded7619' added support for 89459 chip pcie device. It uses the
> BRCM4355 chip which is also found in Apple hardware. However this commit
> causes conflicts in the firmware naming between Apple hardware, which
> supports OTP and other non-Apple hardwares. So, this patch makes these
> Apple chips use their own firmware table so as to avoid possible conflicts
> like these in the future.
>
I think my reply to Arend flew over your head.
My point was that I'd rather have the Broadcom/Cypress people actually
answer my question so we can figure out how to do this *properly*,
instead of doing "safer-but-dumb" things (like this patch) because we
just don't have the information to do it properly.
- Hector
> I think my reply to Arend flew over your head.
Sorry. I am not that good in English so sometimes do misinterpret things.
>
> My point was that I'd rather have the Broadcom/Cypress people actually
> answer my question so we can figure out how to do this *properly*,
> instead of doing "safer-but-dumb" things (like this patch) because we
> just don't have the information to do it properly.
>
> - Hector
On January 2, 2023 4:15:41 PM Hector Martin <[email protected]> wrote:
> On 02/01/2023 23.40, Aditya Garg wrote:
>> From: Aditya Garg <[email protected]>
>>
>> Commit 'dce45ded7619' added support for 89459 chip pcie device. It uses the
>> BRCM4355 chip which is also found in Apple hardware. However this commit
>> causes conflicts in the firmware naming between Apple hardware, which
>> supports OTP and other non-Apple hardwares. So, this patch makes these
>> Apple chips use their own firmware table so as to avoid possible conflicts
>> like these in the future.
>
> I think my reply to Arend flew over your head.
>
> My point was that I'd rather have the Broadcom/Cypress people actually
> answer my question so we can figure out how to do this *properly*,
> instead of doing "safer-but-dumb" things (like this patch) because we
> just don't have the information to do it properly.
Fair enough. Can you accurately (re)state your question and I will try to
answer it.
Regards,
Arend
> - Hector
Hi Aditya,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on wireless-next/main]
[also build test WARNING on wireless/main linus/master v6.2-rc2 next-20221226]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Aditya-Garg/brcmfmac-Add-PCIe-ID-of-BCM4355-chip-found-on-T2-Macs/20230102-234714
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/B5647DBC-3D99-412F-BD04-071950D3CD48%40live.com
patch subject: [PATCH 2/2] brcmfmac: Add PCIe ID of BCM4355 chip found on T2 Macs
config: x86_64-allyesconfig
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
# https://github.com/intel-lab-lkp/linux/commit/960ea39e9583e9a433e6fc2ad30e919cc8cdcf0c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Aditya-Garg/brcmfmac-Add-PCIe-ID-of-BCM4355-chip-found-on-T2-Macs/20230102-234714
git checkout 960ea39e9583e9a433e6fc2ad30e919cc8cdcf0c
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/net/wireless/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <[email protected]>
All warnings (new ones prefixed by >>):
In file included from drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:40:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h:45:9: error: expected '}' before '{' token
45 | { chipid, mask, BRCM_ ## name ## _FIRMWARE_BASENAME }
| ^
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:82:9: note: in expansion of macro 'BRCMF_FW_ENTRY'
82 | BRCMF_FW_ENTRY(BRCM_CC_4356_CHIP_ID, 0xFFFFFFFF, 4356),
| ^~~~~~~~~~~~~~
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:75:67: note: to match this '{'
75 | static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
| ^
In file included from drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:40:
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h:33:19: warning: 'BRCM_4371_FIRMWARE_BASENAME' defined but not used [-Wunused-const-variable=]
33 | static const char BRCM_ ## fw_name ## _FIRMWARE_BASENAME[] = \
| ^~~~~
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:63:1: note: in expansion of macro 'BRCMF_FW_DEF'
63 | BRCMF_FW_DEF(4371, "brcmfmac4371-pcie");
| ^~~~~~~~~~~~
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h:33:19: warning: 'BRCM_4366B_FIRMWARE_BASENAME' defined but not used [-Wunused-const-variable=]
33 | static const char BRCM_ ## fw_name ## _FIRMWARE_BASENAME[] = \
| ^~~~~
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:61:1: note: in expansion of macro 'BRCMF_FW_DEF'
61 | BRCMF_FW_DEF(4366B, "brcmfmac4366b-pcie");
| ^~~~~~~~~~~~
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h:33:19: warning: 'BRCM_4365B_FIRMWARE_BASENAME' defined but not used [-Wunused-const-variable=]
33 | static const char BRCM_ ## fw_name ## _FIRMWARE_BASENAME[] = \
| ^~~~~
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:59:1: note: in expansion of macro 'BRCMF_FW_DEF'
59 | BRCMF_FW_DEF(4365B, "brcmfmac4365b-pcie");
| ^~~~~~~~~~~~
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h:33:19: warning: 'BRCM_4364_FIRMWARE_BASENAME' defined but not used [-Wunused-const-variable=]
33 | static const char BRCM_ ## fw_name ## _FIRMWARE_BASENAME[] = \
| ^~~~~
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:58:1: note: in expansion of macro 'BRCMF_FW_DEF'
58 | BRCMF_FW_DEF(4364, "brcmfmac4364-pcie");
| ^~~~~~~~~~~~
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h:33:19: warning: 'BRCM_4359_FIRMWARE_BASENAME' defined but not used [-Wunused-const-variable=]
33 | static const char BRCM_ ## fw_name ## _FIRMWARE_BASENAME[] = \
| ^~~~~
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:57:1: note: in expansion of macro 'BRCMF_FW_DEF'
57 | BRCMF_FW_DEF(4359, "brcmfmac4359-pcie");
| ^~~~~~~~~~~~
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h:33:19: warning: 'BRCM_4358_FIRMWARE_BASENAME' defined but not used [-Wunused-const-variable=]
33 | static const char BRCM_ ## fw_name ## _FIRMWARE_BASENAME[] = \
| ^~~~~
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:56:1: note: in expansion of macro 'BRCMF_FW_DEF'
56 | BRCMF_FW_DEF(4358, "brcmfmac4358-pcie");
| ^~~~~~~~~~~~
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h:39:19: warning: 'BRCM_43570_FIRMWARE_BASENAME' defined but not used [-Wunused-const-variable=]
39 | static const char BRCM_ ## fw_name ## _FIRMWARE_BASENAME[] = \
| ^~~~~
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:55:1: note: in expansion of macro 'BRCMF_FW_CLM_DEF'
55 | BRCMF_FW_CLM_DEF(43570, "brcmfmac43570-pcie");
| ^~~~~~~~~~~~~~~~
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h:39:19: warning: 'BRCM_4356_FIRMWARE_BASENAME' defined but not used [-Wunused-const-variable=]
39 | static const char BRCM_ ## fw_name ## _FIRMWARE_BASENAME[] = \
| ^~~~~
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:54:1: note: in expansion of macro 'BRCMF_FW_CLM_DEF'
54 | BRCMF_FW_CLM_DEF(4356, "brcmfmac4356-pcie");
| ^~~~~~~~~~~~~~~~
vim +/BRCM_4371_FIRMWARE_BASENAME +33 drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
46d703a775394e Hante Meuleman 2015-11-25 31
41f573dbb534f1 Arend Van Spriel 2018-03-22 32 #define BRCMF_FW_DEF(fw_name, fw_base) \
41f573dbb534f1 Arend Van Spriel 2018-03-22 @33 static const char BRCM_ ## fw_name ## _FIRMWARE_BASENAME[] = \
41f573dbb534f1 Arend Van Spriel 2018-03-22 34 BRCMF_FW_DEFAULT_PATH fw_base; \
41f573dbb534f1 Arend Van Spriel 2018-03-22 35 MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH fw_base ".bin")
46d703a775394e Hante Meuleman 2015-11-25 36
885f256f61f958 Matthias Brugger 2021-06-07 37 /* Firmware and Country Local Matrix files */
885f256f61f958 Matthias Brugger 2021-06-07 38 #define BRCMF_FW_CLM_DEF(fw_name, fw_base) \
885f256f61f958 Matthias Brugger 2021-06-07 @39 static const char BRCM_ ## fw_name ## _FIRMWARE_BASENAME[] = \
885f256f61f958 Matthias Brugger 2021-06-07 40 BRCMF_FW_DEFAULT_PATH fw_base; \
885f256f61f958 Matthias Brugger 2021-06-07 41 MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH fw_base ".bin"); \
885f256f61f958 Matthias Brugger 2021-06-07 42 MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH fw_base ".clm_blob")
885f256f61f958 Matthias Brugger 2021-06-07 43
--
0-DAY CI Kernel Test Service
https://01.org/lkp
On 2023/01/03 3:27, Arend Van Spriel wrote:
> On January 2, 2023 4:15:41 PM Hector Martin <[email protected]> wrote:
>
>> On 02/01/2023 23.40, Aditya Garg wrote:
>>> From: Aditya Garg <[email protected]>
>>>
>>> Commit 'dce45ded7619' added support for 89459 chip pcie device. It uses the
>>> BRCM4355 chip which is also found in Apple hardware. However this commit
>>> causes conflicts in the firmware naming between Apple hardware, which
>>> supports OTP and other non-Apple hardwares. So, this patch makes these
>>> Apple chips use their own firmware table so as to avoid possible conflicts
>>> like these in the future.
>>
>> I think my reply to Arend flew over your head.
>>
>> My point was that I'd rather have the Broadcom/Cypress people actually
>> answer my question so we can figure out how to do this *properly*,
>> instead of doing "safer-but-dumb" things (like this patch) because we
>> just don't have the information to do it properly.
>
> Fair enough. Can you accurately (re)state your question and I will try to
> answer it.
As per my original email: Is the CYW89459 just a rebrand of the BCM4355,
or just a subset? Can we consider them equivalent, and equivalent to the
Apple part (BCM4355C1 / revision 12)?
More specifically:
- What BCM4355 variants exist in the wild, and what are their PCI device
IDs and revision IDs?
- Is a single firmware nominally intended to be compatible with all of
those variants? Does that include the CYW89459 branded parts?
- If CYW89459 is a rebrand of BCM4355, is it complete, or are there
still chips being sold as BCM4355?
Even more specifically, bcmdhd has these device IDs:
#define BCM4355_D11AC_ID 0x43dc /* 4355 802.11ac dualband device */
#define BCM4355_D11AC2G_ID 0x43fc /* 4355 802.11ac 2.4G device */
#define BCM4355_D11AC5G_ID 0x43fd /* 4355 802.11ac 5G device */
But the patch I'm replying to uses PCI ID 0x4355, which instead should be:
#define BCM43237_D11N_ID 0x4355 /* 43237 802.11n dualband device */
#define BCM43237_D11N5G_ID 0x4356 /* 43237 802.11n 5GHz device */
So what's up with the BCM43237? Is that a 4355 variant? Is this what got
rebranded as CYW89459? Is it firmware-compatible with the others?
<rant>
I'm going to be honest here: I'm quite saddened by the state of brcmfmac
and Broadcom's neglect of this driver. Other than the Apple OTP /
firmware selection shenanigans, everything else I'm having to implement
to support Apple machines are features that Broadcom's downstream bcmdhd
driver *already* supports on non-Apple machines, not Apple-specific. Not
only that, people are asking for modern WiFi features like newer crypto
modes that bcmdhd supports but brcmfmac doesn't. It seems clear that
Broadcom isn't interested in maintaining this driver and updating it to
support newer chips and features. So I'm basically doing your job for
you all. Which is fine, but if I'm going to be in charge of implementing
all this stuff for you, *please* help me by at least clarifying the
device variant / firmware feature related issues, because getting that
wrong will cause regressions or firmware naming scheme breaks down the
line, and that sucks for users.
</rant>
- Hector
On 1/3/2023 4:55 AM, Hector Martin wrote:
> On 2023/01/03 3:27, Arend Van Spriel wrote:
>> On January 2, 2023 4:15:41 PM Hector Martin <[email protected]> wrote:
>>
>>> On 02/01/2023 23.40, Aditya Garg wrote:
>>>> From: Aditya Garg <[email protected]>
>>>>
>>>> Commit 'dce45ded7619' added support for 89459 chip pcie device. It uses the
>>>> BRCM4355 chip which is also found in Apple hardware. However this commit
>>>> causes conflicts in the firmware naming between Apple hardware, which
>>>> supports OTP and other non-Apple hardwares. So, this patch makes these
>>>> Apple chips use their own firmware table so as to avoid possible conflicts
>>>> like these in the future.
>>>
>>> I think my reply to Arend flew over your head.
>>>
>>> My point was that I'd rather have the Broadcom/Cypress people actually
>>> answer my question so we can figure out how to do this *properly*,
>>> instead of doing "safer-but-dumb" things (like this patch) because we
>>> just don't have the information to do it properly.
>>
>> Fair enough. Can you accurately (re)state your question and I will try to
>> answer it.
>
> As per my original email: Is the CYW89459 just a rebrand of the BCM4355,
> or just a subset? Can we consider them equivalent, and equivalent to the
> Apple part (BCM4355C1 / revision 12)?
There is probably no easy answer. Mainly because Cypress is a separate
entity. However, they use the same/similar technology and code base. So
let me first start with the chip naming. The wifi chip primarily has a
number and revision. The chip number is straighforward and can be read
from the device. The chip revision comes in two variants: 1) simple
increasing number as read from the device, and 2) a <letter><digit>
format. The latter start at a0, which you almost never see in the wild
unless we do it "first time right". Whenever spinning a new chip we
either increase the digit or the letter depending on type/amount of
changes. There is not predictable mapping between the revision variants.
Depending on the hurdles in a chip project we may move from a0 to b0, or
from b0 to b1 or whatever.
If CYW89459 chip reads chip number 0x4355 than it is a BCM4355. If it is
a different revision it may require different firmware. A different
letter will always require different firmware. A different digit may
work although the firmware can have code paths for a specific revision.
The firmware tables in pcie.c have the revmask. With our crystal ball
being out-of-order we tend to enable a firmware for all revisions
(0xFFFFFFFF) unless proven otherwise. If otherwise, we come up with a
sensible new name and add a new entry to the firmware table changing the
revmasks accordingly.
> More specifically:
> - What BCM4355 variants exist in the wild, and what are their PCI device
> IDs and revision IDs?
Who knows. The PCI revision ID always equals the chip revision afaik.
The PCI device IDs should be as below.
> - Is a single firmware nominally intended to be compatible with all of
> those variants? Does that include the CYW89459 branded parts?
> - If CYW89459 is a rebrand of BCM4355, is it complete, or are there
> still chips being sold as BCM4355?
>
> Even more specifically, bcmdhd has these device IDs:
>
> #define BCM4355_D11AC_ID 0x43dc /* 4355 802.11ac dualband device */
> #define BCM4355_D11AC2G_ID 0x43fc /* 4355 802.11ac 2.4G device */
> #define BCM4355_D11AC5G_ID 0x43fd /* 4355 802.11ac 5G device */
>
> But the patch I'm replying to uses PCI ID 0x4355, which instead should be:
>
> #define BCM43237_D11N_ID 0x4355 /* 43237 802.11n dualband device */
> #define BCM43237_D11N5G_ID 0x4356 /* 43237 802.11n 5GHz device */
>
> So what's up with the BCM43237? Is that a 4355 variant? Is this what got
> rebranded as CYW89459? Is it firmware-compatible with the others?
Right. If you have come across a BCM4355 with PCI device ID 0x4355 than
my best guess would be that their OTP is corrupted and the PCIe core on
the chip uses its default as stored in hardware, which equals the chip
number. This is really a fallback for a faulty device (or a device which
does not have its OTP programmed).
> <rant>
>
> I'm going to be honest here: I'm quite saddened by the state of brcmfmac
> and Broadcom's neglect of this driver. Other than the Apple OTP /
> firmware selection shenanigans, everything else I'm having to implement
> to support Apple machines are features that Broadcom's downstream bcmdhd
> driver *already* supports on non-Apple machines, not Apple-specific. Not
> only that, people are asking for modern WiFi features like newer crypto
> modes that bcmdhd supports but brcmfmac doesn't. It seems clear that
> Broadcom isn't interested in maintaining this driver and updating it to
> support newer chips and features. So I'm basically doing your job for
> you all. Which is fine, but if I'm going to be in charge of implementing
> all this stuff for you, *please* help me by at least clarifying the
> device variant / firmware feature related issues, because getting that
> wrong will cause regressions or firmware naming scheme breaks down the
> line, and that sucks for users.
>
> </rant>
Happy New year to you. Thanks for clearly marking the rant. Makes it
easier to ignore, but let me get into this. I would not call bcmdhd the
downstream driver. It is a separate out-of-tree driver. Indeed resources
were pulled from brcm80211 development, but there always have been only
2 or 3 people working on it. Me being the constant working mule and
these days only for 20% of my working hours to do the job. So you are
not really doing our job as we are not assigned to do so. I guess there
is no ROI for Broadcom or so it is perceived and there is no customer
pushing for it. That said I am always happy to help and clarify whatever
I can.
Regards,
Arend
> On Jan 3, 2023, at 8:30 AM, Arend van Spriel <[email protected]> wrote:
>
> On 1/3/2023 4:55 AM, Hector Martin wrote:
>> More specifically:
>> - What BCM4355 variants exist in the wild, and what are their PCI device
>> IDs and revision IDs?
>
> Who knows. The PCI revision ID always equals the chip revision afaik. The PCI device IDs should be as below.
If the day ever came where the FCC inquired about a theoretical spurious radio emissions issue in such a chipset, and asked Broadcom for a list of all affected hardware releases, would the FCC also be told “who knows”?
I guess the difference is that the FCC has the statutory authority to yank Broadcom’s certifications to sell their product, whereas Hector is merely improving your driver support for no monetary compensation from you.
Maybe the Broadcom drivers should be yanked from Linux if this is what passes for Broadcom release engineering.
zzy
On 1/3/2023 2:46 PM, Hector Martin wrote:
> On 03/01/2023 22.30, Arend van Spriel wrote:
>> On 1/3/2023 4:55 AM, Hector Martin wrote:
>>> On 2023/01/03 3:27, Arend Van Spriel wrote:
>>>> On January 2, 2023 4:15:41 PM Hector Martin <[email protected]> wrote:
>>>>
>>>>> On 02/01/2023 23.40, Aditya Garg wrote:
>>>>>> From: Aditya Garg <[email protected]>
>>>>>>
>>>>>> Commit 'dce45ded7619' added support for 89459 chip pcie device. It uses the
>>>>>> BRCM4355 chip which is also found in Apple hardware. However this commit
>>>>>> causes conflicts in the firmware naming between Apple hardware, which
>>>>>> supports OTP and other non-Apple hardwares. So, this patch makes these
>>>>>> Apple chips use their own firmware table so as to avoid possible conflicts
>>>>>> like these in the future.
>>>>>
>>>>> I think my reply to Arend flew over your head.
>>>>>
>>>>> My point was that I'd rather have the Broadcom/Cypress people actually
>>>>> answer my question so we can figure out how to do this *properly*,
>>>>> instead of doing "safer-but-dumb" things (like this patch) because we
>>>>> just don't have the information to do it properly.
>>>>
>>>> Fair enough. Can you accurately (re)state your question and I will try to
>>>> answer it.
>>>
>>> As per my original email: Is the CYW89459 just a rebrand of the BCM4355,
>>> or just a subset? Can we consider them equivalent, and equivalent to the
>>> Apple part (BCM4355C1 / revision 12)?
>>
>> There is probably no easy answer. Mainly because Cypress is a separate
>> entity. However, they use the same/similar technology and code base. So
>> let me first start with the chip naming. The wifi chip primarily has a
>> number and revision. The chip number is straighforward and can be read
>> from the device. The chip revision comes in two variants: 1) simple
>> increasing number as read from the device, and 2) a <letter><digit>
>> format. The latter start at a0, which you almost never see in the wild
>> unless we do it "first time right". Whenever spinning a new chip we
>> either increase the digit or the letter depending on type/amount of
>> changes. There is not predictable mapping between the revision variants.
>> Depending on the hurdles in a chip project we may move from a0 to b0, or
>> from b0 to b1 or whatever.
>
> Right, this is standard chip spin numbering, that much I know.
>
>> If CYW89459 chip reads chip number 0x4355 than it is a BCM4355. If it is
>> a different revision it may require different firmware. A different
>> letter will always require different firmware. A different digit may
>> work although the firmware can have code paths for a specific revision.
>
> So is it always correct to have the same firmware (in a generic
> situation, not a customized OEM build) for, say, a BCM4355 rev 12,
> regardless of what the PCI ID programmed into the OTP is (and what the
> marketing device name is)?
Yes.
> If so, then my conclusion is that the original patch I replied to is
> incorrect, all the defines should've been called BCM4355 (not the
> Cypress part number), and we probably need two firmware table entries
> since (judging by the revision check elsewhere in that patch) there are
> other revisions in the wild than the one Apple uses, and therefore there
> should at the very least be a firmware name split at C1. It would then
> be very helpful to know what revisions *do* exist and their correct naming.
I can only track down what we have in Broadcom. For the 4355 the
revisions B1 (=6), B3 (=8), C0 (=10) and C1 are mentioned as released.
Here things get weird, because you mentioned BCM4355 rev12, which would
be a C2. So without asking around I can only assume this C2 variant is
not different from firmware perspective and can happily run the C1 firmware.
> If different PCI device IDs might need different firmware, then the
> exiting firmware selection/table mechanism is insufficient.
>
>> Happy New year to you. Thanks for clearly marking the rant. Makes it
>> easier to ignore, but let me get into this. I would not call bcmdhd the
>> downstream driver. It is a separate out-of-tree driver. Indeed resources
>> were pulled from brcm80211 development, but there always have been only
>> 2 or 3 people working on it. Me being the constant working mule and
>> these days only for 20% of my working hours to do the job. So you are
>> not really doing our job as we are not assigned to do so. I guess there
>> is no ROI for Broadcom or so it is perceived and there is no customer
>> pushing for it. That said I am always happy to help and clarify whatever
>> I can.
>
> Is there any chance you can provide a list of chips/shipping revisions
> and revision IDs, so we can stop guessing at the mappings in the
> firmware table? Because this is effectively breaking userspace ABI every
> time we make a change to an existing chip, as it can change the firmware
> file name that userspace loads. This already happened with BCM4364,
> where (at least) B2 and B3 revisions exist in the wild and we need
> separate firmwares, yet it was added with a full mask, resulting in
> people copying "the right firmware for them" manually and my patch to
> split it into properly named firmwares will break those users.
Userspace is not loading anything these days. AFAIK the kernel is
directly accessing the firmware file. Anyway, I never considered this as
being a big issue. If people change their installed os to get things
working, they can expect the reverse can happen anytime and deal with it
once more. If this is considered a real issue we should only set the
revmask for the revision we know to be working.
Regards,
Arend