From: Dan Haab <[email protected]>
BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
supported by the same firmware as 4366c0.
Signed-off-by: Dan Haab <[email protected]>
---
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 <[email protected]>
>
> 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
<[email protected]> wrote:
> On 3/22/2018 4:58 PM, Dan Haab wrote:
>>
>> From: Dan Haab <[email protected]>
>>
>> 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 4/3/2018 12:17 PM, Rafał Miłecki wrote:
> On 3 April 2018 at 10:22, Arend van Spriel <[email protected]> wrote:
[...]
>>
>>
>> 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.
[...]
>> 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 <[email protected]> w=
rote:
> On 4/3/2018 12:17 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
>>
>> On 3 April 2018 at 10:22, Arend van Spriel <[email protected]=
>
>> wrote:
>
>
> [...]
>
>>>
>>>
>>> My first reaction to this email needed to some cooldown time, but manag=
ed
>>> 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.
>
> [...]
>
>>> 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
>>> 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
On 3/30/2018 9:26 AM, Rafał Miłecki wrote:
> On 23 March 2018 at 10:31, Arend van Spriel
> <[email protected]> wrote:
>> On 3/22/2018 4:58 PM, Dan Haab wrote:
>>>
>>> From: Dan Haab <[email protected]>
>>>
>>> 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 <[email protected]> w=
rote:
> On 3/30/2018 9:26 AM, Rafa=C5=82 Mi=C5=82ecki wrote:
>>
>> On 23 March 2018 at 10:31, Arend van Spriel
>> <[email protected]> wrote:
>>>
>>> On 3/22/2018 4:58 PM, Dan Haab wrote:
>>>>
>>>>
>>>> From: Dan Haab <[email protected]>
>>>>
>>>> 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