[PATCH] brcmfmac: add support for BCM4366E chipset

From: Dan Haab <redacted>

BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
supported by the same firmware as 4366c0.

Signed-off-by: Dan Haab <redacted>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c       | 1 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c       | 2 ++
 drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 1 +
 3 files changed, 4 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index f7b30ce..271dadb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c

@@ -689,6 +689,7 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv *ci)
 	case BRCM_CC_43525_CHIP_ID:
 	case BRCM_CC_4365_CHIP_ID:
 	case BRCM_CC_4366_CHIP_ID:
+	case BRCM_CC_43664_CHIP_ID:
 		return 0x200000;
 	case CY_CC_4373_CHIP_ID:
 		return 0x160000;

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index a7d827c..b4d3832 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c

@@ -57,6 +57,7 @@ enum brcmf_pcie_state {
 BRCMF_FW_NVRAM_DEF(4365C, "brcmfmac4365c-pcie.bin", "brcmfmac4365c-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4366B, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
+BRCMF_FW_NVRAM_DEF(4366E, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
 
 static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {

@@ -75,6 +76,7 @@ enum brcmf_pcie_state {
 	BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFFFFFF0, 4365C),
 	BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366B),
 	BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366C),
+	BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43664_CHIP_ID, 0xFFFFFFF0, 4366E),
 	BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371),
 };
 

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 57544a3..686f7a8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h

@@ -57,6 +57,7 @@
 #define BRCM_CC_43602_CHIP_ID		43602
 #define BRCM_CC_4365_CHIP_ID		0x4365
 #define BRCM_CC_4366_CHIP_ID		0x4366
+#define BRCM_CC_43664_CHIP_ID		43664
 #define BRCM_CC_4371_CHIP_ID		0x4371
 #define CY_CC_4373_CHIP_ID		0x4373
 

-- 
1.9.1

On 3/22/2018 4:58 PM, Dan Haab wrote:

From: Dan Haab <redacted>

BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
supported by the same firmware as 4366c0.

Thanks, Dan

I have a patch for that queued up already. So let me push that instead.

Regards,
Arend

On 23 March 2018 at 10:31, Arend van Spriel
[off-list ref] wrote:

On 3/22/2018 4:58 PM, Dan Haab wrote:

quoted

From: Dan Haab <redacted>

BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
supported by the same firmware as 4366c0.

Thanks, Dan

I have a patch for that queued up already. So let me push that instead.

Arend: is there some actual problem with this patch? Other than you
have a similar one queued?

I'd prefer to just accept it as it's already there, it was sent first
and it looks alright. It hopefully won't be too hard to rebase your
queued work on top of this trivial patch.

--=20
Rafa=C5=82

On 3/30/2018 9:26 AM, Rafał Miłecki wrote:

On 23 March 2018 at 10:31, Arend van Spriel
[off-list ref] wrote:

quoted

On 3/22/2018 4:58 PM, Dan Haab wrote:

quoted

From: Dan Haab <redacted>

BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
supported by the same firmware as 4366c0.

Thanks, Dan

I have a patch for that queued up already. So let me push that instead.

Arend: is there some actual problem with this patch? Other than you
have a similar one queued?

I'd prefer to just accept it as it's already there, it was sent first
and it looks alright. It hopefully won't be too hard to rebase your
queued work on top of this trivial patch.

My first reaction to this email needed to some cooldown time, but 
managed to swallow it. I actually had a couple of issues with the patch 
and did not want to waste Dan's time when there was a patch ready. I did 
not want to add another device because we are still in the process of 
releasing the firmware for it. Fiddling with radar detection causing the 
delay of that. Another thing is that there is no separate 
BRCMF_FW_NVRAM_DEF() needed for this. And finally, the firmware download 
code has been reworked so this patch needs rebasing.

Regards,
Arend

On 3 April 2018 at 10:22, Arend van Spriel [off-list ref] w=
rote:

On 3/30/2018 9:26 AM, Rafa=C5=82 Mi=C5=82ecki wrote:

quoted

On 23 March 2018 at 10:31, Arend van Spriel
[off-list ref] wrote:

quoted

On 3/22/2018 4:58 PM, Dan Haab wrote:

quoted

From: Dan Haab <redacted>

BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
supported by the same firmware as 4366c0.

Thanks, Dan

I have a patch for that queued up already. So let me push that instead.

Arend: is there some actual problem with this patch? Other than you
have a similar one queued?

I'd prefer to just accept it as it's already there, it was sent first
and it looks alright. It hopefully won't be too hard to rebase your
queued work on top of this trivial patch.

My first reaction to this email needed to some cooldown time, but managed=

 to

swallow it.

I'm sorry you keep reacting to my e-mails/patches that way. I can't
see how my e-mail was offensive in any way. I assure I didn't mean it
to be.

I really assumed there could be some extra changes needed to support
4366E properly, that's why I asked. I can remember adding a full
support for 4366b1 wasn't that obvious and you and Hante spent some
time helping me with some specific device. They required changes from
commit 6ac27689b01e2 ("brcmfmac: use device memsize config from fw if
defined").

I actually had a couple of issues with the patch and did not
want to waste Dan's time when there was a patch ready. I did not want to =

add

another device because we are still in the process of releasing the firmw=

are

for it. Fiddling with radar detection causing the delay of that.

It's something that I think was never a problem in the past. There is
e.g. support for 4366c0 support in the brcmfmac without
brcmfmac4366c-pcie.bin officially released.

Another
thing is that there is no separate BRCMF_FW_NVRAM_DEF() needed for this. =

And

finally, the firmware download code has been reworked so this patch needs
rebasing.

Thanks for rebasing that! I appreciate your help. I'll work on
backporting that into OpenWrt/LEDE.

--=20
Rafa=C5=82

On 4/3/2018 12:17 PM, Rafał Miłecki wrote:

On 3 April 2018 at 10:22, Arend van Spriel [off-list ref] wrote:

[...]

quoted

My first reaction to this email needed to some cooldown time, but managed to
swallow it.

I'm sorry you keep reacting to my e-mails/patches that way. I can't
see how my e-mail was offensive in any way. I assure I didn't mean it
to be.

I can not really say what it is. Anyway it is my fault and have to work 
on it.

[...]

quoted

I actually had a couple of issues with the patch and did not
want to waste Dan's time when there was a patch ready. I did not want to add
another device because we are still in the process of releasing the firmware
for it. Fiddling with radar detection causing the delay of that.

It's something that I think was never a problem in the past. There is
e.g. support for 4366c0 support in the brcmfmac without
brcmfmac4366c-pcie.bin officially released.

My rule of thumb is to get the firmware released before/when the driver 
patch hits mainline. However, sometimes it blows up in my face. Like 
with the 4366c0. We had to add a new feature to the firmware to get an 
ok, which caused the delay. Hopefully, I can get it out soon.

Regards,
Arend

On 3 April 2018 at 13:24, Arend van Spriel [off-list ref] w=
rote:

On 4/3/2018 12:17 PM, Rafa=C5=82 Mi=C5=82ecki wrote:

quoted

On 3 April 2018 at 10:22, Arend van Spriel <arend.vanspriel@broadcom.com=

quoted

wrote:

[...]

quoted

quoted

My first reaction to this email needed to some cooldown time, but manag=

ed

quoted

quoted

to
swallow it.

I'm sorry you keep reacting to my e-mails/patches that way. I can't
see how my e-mail was offensive in any way. I assure I didn't mean it
to be.

I can not really say what it is. Anyway it is my fault and have to work o=

n

it.

[...]

quoted

quoted

I actually had a couple of issues with the patch and did not
want to waste Dan's time when there was a patch ready. I did not want t=

o

quoted

quoted

add
another device because we are still in the process of releasing the
firmware
for it. Fiddling with radar detection causing the delay of that.

It's something that I think was never a problem in the past. There is
e.g. support for 4366c0 support in the brcmfmac without
brcmfmac4366c-pcie.bin officially released.

My rule of thumb is to get the firmware released before/when the driver
patch hits mainline. However, sometimes it blows up in my face. Like with
the 4366c0. We had to add a new feature to the firmware to get an ok, whi=

ch

caused the delay. Hopefully, I can get it out soon.

Sounds great, thanks, I keep by fingers crossed :)

--=20
Rafa=C5=82