Support new chip 89459.
Update usage of dcmd buffer, dtim_assoc and WOWL pattern due to fw
capabilities change.
Changes in v2:
- rebase on latest wireless-next
- remove commit "brcmfmac: add 54591 PCIE device" due to brcmf_bus_ops
changed
Alexander Prutskov (1):
brcmfmac: Support 89459 pcie
Lo(Double)Hsiang Lo (1):
brcmfmac: increase dcmd maximum buffer size
Ramesh Rangavittal (1):
brcmfmac: Remove the call to "dtim_assoc" IOVAR
Ryohei Kondo (1):
brcmfmac: increase default max WOWL patterns to 16
.../broadcom/brcm80211/brcmfmac/bcdc.c | 4 ++-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 26 +------------------
.../broadcom/brcm80211/brcmfmac/chip.c | 3 +++
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 2 +-
.../broadcom/brcm80211/brcmfmac/pcie.c | 4 +++
.../broadcom/brcm80211/include/brcm_hw_ids.h | 4 ++-
6 files changed, 15 insertions(+), 28 deletions(-)
--
2.25.0
From: Ryohei Kondo <[email protected]>
4373 has support of 16 WOWL patterns thus increasing the default value
Signed-off-by: Ryohei Kondo <[email protected]>
Signed-off-by: Chi-hsien Lin <[email protected]>
Signed-off-by: Ian Lin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index c87b829adb0d..f518e025d6e4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -135,7 +135,7 @@
/* Link Down indication in WoWL mode: */
#define BRCMF_WOWL_LINKDOWN (1 << 31)
-#define BRCMF_WOWL_MAXPATTERNS 8
+#define BRCMF_WOWL_MAXPATTERNS 16
#define BRCMF_WOWL_MAXPATTERNSIZE 128
#define BRCMF_COUNTRY_BUF_SZ 4
--
2.25.0
From: Alexander Prutskov <[email protected]>
Adds support of 89459 chip pcie device and save restore support.
Signed-off-by: Alexander Prutskov <[email protected]>
Signed-off-by: Joseph chuang <[email protected]>
Signed-off-by: Chi-Hsien Lin <[email protected]>
Signed-off-by: Ian Lin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 3 +++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 ++++
drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 4 +++-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 3026166a56c1..121893bbaa1d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -735,6 +735,8 @@ 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;
@@ -1425,6 +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:
/* 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 f98641bb1528..80083f9ea311 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -60,6 +60,7 @@ BRCMF_FW_DEF(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");
@@ -90,6 +91,7 @@ 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 */
@@ -2465,6 +2467,8 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_5G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4371_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4378_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(CY_PCIE_89459_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(CY_PCIE_89459_RAW_DEVICE_ID),
{ /* end: all zeroes */ }
};
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index 1003f123ec25..f4939cf62767 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -56,6 +56,7 @@
#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,7 +91,8 @@
#define BRCM_PCIE_4366_5G_DEVICE_ID 0x43c5
#define BRCM_PCIE_4371_DEVICE_ID 0x440d
#define BRCM_PCIE_4378_DEVICE_ID 0x4425
-
+#define CY_PCIE_89459_DEVICE_ID 0x4415
+#define CY_PCIE_89459_RAW_DEVICE_ID 0x4355
/* brcmsmac IDs */
#define BCM4313_D11N2G_ID 0x4727 /* 4313 802.11n 2.4G device */
--
2.25.0
From: "Lo(Double)Hsiang Lo" <[email protected]>
Increase dcmd maximum buffer size to match firmware
configuration for new chips.
Signed-off-by: Lo(Double)Hsiang Lo <[email protected]>
Signed-off-by: Chi-Hsien Lin <[email protected]>
Signed-off-by: Ian Lin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
index 02a56edf08ba..9ec0c60b6da1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
@@ -87,6 +87,8 @@ struct brcmf_proto_bcdc_header {
* plus any space that might be needed
* for bus alignment padding.
*/
+#define ROUND_UP_MARGIN 2048
+
struct brcmf_bcdc {
u16 reqid;
u8 bus_header[BUS_HEADER_LEN];
@@ -470,7 +472,7 @@ int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)
drvr->hdrlen += BCDC_HEADER_LEN + BRCMF_PROT_FW_SIGNAL_MAX_TXBYTES;
drvr->bus_if->maxctl = BRCMF_DCMD_MAXLEN +
- sizeof(struct brcmf_proto_bcdc_dcmd);
+ sizeof(struct brcmf_proto_bcdc_dcmd) + ROUND_UP_MARGIN;
return 0;
fail:
--
2.25.0
From: Ramesh Rangavittal <[email protected]>
When STA roams from one AP to another, after roam is complete, host
driver tries to get TIM information from firmware. This is no longer
supported in the firmware & hence, this call will always fail.
This failure results in the below message being displayed on the
console all the time when roam is done.
ieee80211 phy0: brcmf_update_bss_info: wl dtim_assoc failed (-52)
Changes ensure that the host driver will no longer try to get TIM
information from firmware.
Signed-off-by: Ramesh Rangavittal <[email protected]>
Signed-off-by: Chi-hsien Lin <[email protected]>
Signed-off-by: Ian Lin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 26 +------------------
1 file changed, 1 insertion(+), 25 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 42068145a447..dfcfb3333369 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3164,10 +3164,7 @@ static s32 brcmf_update_bss_info(struct brcmf_cfg80211_info *cfg,
struct brcmf_if *ifp)
{
struct brcmf_pub *drvr = cfg->pub;
- struct brcmf_bss_info_le *bi;
- const struct brcmf_tlv *tim;
- size_t ie_len;
- u8 *ie;
+ struct brcmf_bss_info_le *bi = NULL;
s32 err = 0;
brcmf_dbg(TRACE, "Enter\n");
@@ -3181,29 +3178,8 @@ static s32 brcmf_update_bss_info(struct brcmf_cfg80211_info *cfg,
bphy_err(drvr, "Could not get bss info %d\n", err);
goto update_bss_info_out;
}
-
bi = (struct brcmf_bss_info_le *)(cfg->extra_buf + 4);
err = brcmf_inform_single_bss(cfg, bi);
- if (err)
- goto update_bss_info_out;
-
- ie = ((u8 *)bi) + le16_to_cpu(bi->ie_offset);
- ie_len = le32_to_cpu(bi->ie_length);
-
- tim = brcmf_parse_tlvs(ie, ie_len, WLAN_EID_TIM);
- if (!tim) {
- /*
- * active scan was done so we could not get dtim
- * information out of probe response.
- * so we speficially query dtim information to dongle.
- */
- u32 var;
- err = brcmf_fil_iovar_int_get(ifp, "dtim_assoc", &var);
- if (err) {
- bphy_err(drvr, "wl dtim_assoc failed (%d)\n", err);
- goto update_bss_info_out;
- }
- }
update_bss_info_out:
brcmf_dbg(TRACE, "Exit");
--
2.25.0
Ian Lin <[email protected]> wrote:
> From: Ryohei Kondo <[email protected]>
>
> 4373 has support of 16 WOWL patterns thus increasing the default value
>
> Signed-off-by: Ryohei Kondo <[email protected]>
> Signed-off-by: Chi-hsien Lin <[email protected]>
> Signed-off-by: Ian Lin <[email protected]>
4 patches applied to wireless-next.git, thanks.
459e552bae96 brcmfmac: increase default max WOWL patterns to 16
dce45ded7619 brcmfmac: Support 89459 pcie
11eda8f01d6a brcmfmac: increase dcmd maximum buffer size
a373f38cd1f5 brcmfmac: Remove the call to "dtim_assoc" IOVAR
--
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Hi,
On 22/09/2022 19.41, Ian Lin wrote:
> From: Alexander Prutskov <[email protected]>
>
> Adds support of 89459 chip pcie device and save restore support.
>
> Signed-off-by: Alexander Prutskov <[email protected]>
> Signed-off-by: Joseph chuang <[email protected]>
> Signed-off-by: Chi-Hsien Lin <[email protected]>
> Signed-off-by: Ian Lin <[email protected]>
[...]
Can you explain how the CYW89459 is related to the BCM4355 family? I
have a patch [1] to add support for the BCM4355 variant present in some
Apple laptops which I was hoping to submit again for 6.2, and this patch
conflicts with it.
[1] https://lore.kernel.org/lkml/[email protected]/
> 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");
> @@ -90,6 +91,7 @@ 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),
> };
Is the CYW89459 just a rebrand of the BCM4355, or just a subset? If it
is a rebrand, it's okay if we call our Apple firmware
brcmfmac89459-pcie* (note that we use per-board firmware names, so it
wouldn't conflict with a generic one). However, if CYW89459 only refers
to specific variants, I think the firmware should be named after the
overall bcm4355 family.
I'm guessing you intend to ship firmware for this. Would that firmware
work for all 4355 variants, or only the CYW one? If only the CYW one, is
it possible to differentiate between them based on PCI revision ID? Note
that our 4355 has revision ID 12, and Apple specifically calls it 4355C1
(different chip revisions have different firmware builds, which is why I
named our firmware brcmfmac4355c1-pcie). If the CYW variant uses other
revision IDs that do not overlap, maybe we should have different
firmware entries for them with different masks.
>
> 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 1003f123ec25..f4939cf62767 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
> @@ -56,6 +56,7 @@
> #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
This seems suspicious. If the chip ID is 4355 and applies to non-Cypress
products, unlike the other constants in this list, this constant should
probably be named after BCM4355, not the Cypress part number.
>
> /* USB Device IDs */
> #define BRCM_USB_43143_DEVICE_ID 0xbd1e
> @@ -90,7 +91,8 @@
> #define BRCM_PCIE_4366_5G_DEVICE_ID 0x43c5
> #define BRCM_PCIE_4371_DEVICE_ID 0x440d
> #define BRCM_PCIE_4378_DEVICE_ID 0x4425
> -
> +#define CY_PCIE_89459_DEVICE_ID 0x4415
> +#define CY_PCIE_89459_RAW_DEVICE_ID 0x4355
Note that the PCI device ID for our 4355 is 0x43dc. Other sources call
this "BCM4355 D11AC", which is distinct from 0x4355 ("BCM43237 D11N")
and 0x4415 ("BCM43596 D11AC").
- Hector
Hi Hector
>
> Is the CYW89459 just a rebrand of the BCM4355, or just a subset? If it
> is a rebrand, it's okay if we call our Apple firmware
> brcmfmac89459-pcie* (note that we use per-board firmware names, so it
> wouldn't conflict with a generic one). However, if CYW89459 only refers
> to specific variants, I think the firmware should be named after the
> overall bcm4355 family.
>
> I'm guessing you intend to ship firmware for this. Would that firmware
> work for all 4355 variants, or only the CYW one? If only the CYW one, is
> it possible to differentiate between them based on PCI revision ID? Note
> that our 4355 has revision ID 12, and Apple specifically calls it 4355C1
> (different chip revisions have different firmware builds, which is why I
> named our firmware brcmfmac4355c1-pcie). If the CYW variant uses other
> revision IDs that do not overlap, maybe we should have different
> firmware entries for them with different masks.
Can we make a separate table for the OTP Apple chips, something like here :-
https://github.com/AdityaGarg8/linux/commit/fc41aac9283d2ba653a8b3191e8c0138c13d8ee1
On 1/2/2023 10:45 AM, Aditya Garg wrote:
> Hi Hector
>
>>
>> Is the CYW89459 just a rebrand of the BCM4355, or just a subset? If it
>> is a rebrand, it's okay if we call our Apple firmware
>> brcmfmac89459-pcie* (note that we use per-board firmware names, so it
>> wouldn't conflict with a generic one). However, if CYW89459 only refers
>> to specific variants, I think the firmware should be named after the
>> overall bcm4355 family.
>>
>> I'm guessing you intend to ship firmware for this. Would that firmware
>> work for all 4355 variants, or only the CYW one? If only the CYW one, is
>> it possible to differentiate between them based on PCI revision ID? Note
>> that our 4355 has revision ID 12, and Apple specifically calls it 4355C1
>> (different chip revisions have different firmware builds, which is why I
>> named our firmware brcmfmac4355c1-pcie). If the CYW variant uses other
>> revision IDs that do not overlap, maybe we should have different
>> firmware entries for them with different masks.
>
>
> Can we make a separate table for the OTP Apple chips, something like here :-
>
> https://github.com/AdityaGarg8/linux/commit/fc41aac9283d2ba653a8b3191e8c0138c13d8ee1
I do not understand from this email thread why you would need separate
tables. Can you explain?
Regards,
Arend
On 02/01/2023 22.58, Arend van Spriel wrote:
> On 1/2/2023 10:45 AM, Aditya Garg wrote:
>> Hi Hector
>>
>>>
>>> Is the CYW89459 just a rebrand of the BCM4355, or just a subset? If it
>>> is a rebrand, it's okay if we call our Apple firmware
>>> brcmfmac89459-pcie* (note that we use per-board firmware names, so it
>>> wouldn't conflict with a generic one). However, if CYW89459 only refers
>>> to specific variants, I think the firmware should be named after the
>>> overall bcm4355 family.
>>>
>>> I'm guessing you intend to ship firmware for this. Would that firmware
>>> work for all 4355 variants, or only the CYW one? If only the CYW one, is
>>> it possible to differentiate between them based on PCI revision ID? Note
>>> that our 4355 has revision ID 12, and Apple specifically calls it 4355C1
>>> (different chip revisions have different firmware builds, which is why I
>>> named our firmware brcmfmac4355c1-pcie). If the CYW variant uses other
>>> revision IDs that do not overlap, maybe we should have different
>>> firmware entries for them with different masks.
>>
>>
>> Can we make a separate table for the OTP Apple chips, something like here :-
>>
>> https://github.com/AdityaGarg8/linux/commit/fc41aac9283d2ba653a8b3191e8c0138c13d8ee1
>
> I do not understand from this email thread why you would need separate
> tables. Can you explain?
>
I think he's proposing we special-case Apple chips into their own
firmware table just to avoid colliding with non-Apple firmware usage,
which is honestly kind of tempting as the safe option if nobody from the
Broadcom/Cypress side is willing to clarify what, exactly, is the
relationship between these chips and what their respective revision
numbers are so we can *correctly* represent them and avoid further
confusion and problems down the line.
You might be able to help with that ;)
- Hector
> I think he's proposing we special-case Apple chips into their own
> firmware table just to avoid colliding with non-Apple firmware usage,
> which is honestly kind of tempting as the safe option if nobody from the
> Broadcom/Cypress side is willing to clarify what, exactly, is the
> relationship between these chips and what their respective revision
> numbers are so we can *correctly* represent them and avoid further
> confusion and problems down the line.
Exactly
>
> You might be able to help with that ;)
I am sending the patch.
>
> - Hector