| Message ID | 1521734286-16293-1-git-send-email-dan.haab@luxul.com (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Kalle Valo |
| Headers | show |
On 3/22/2018 4:58 PM, Dan Haab wrote: > From: Dan Haab <dhaab@luxul.com> > > 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 <arend.vanspriel@broadcom.com> wrote: > On 3/22/2018 4:58 PM, Dan Haab wrote: >> >> From: Dan Haab <dhaab@luxul.com> >> >> 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.
On 3/30/2018 9:26 AM, Rafał Miłecki wrote: > On 23 March 2018 at 10:31, Arend van Spriel > <arend.vanspriel@broadcom.com> wrote: >> On 3/22/2018 4:58 PM, Dan Haab wrote: >>> >>> From: Dan Haab <dhaab@luxul.com> >>> >>> 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 <arend.vanspriel@broadcom.com> wrote: > On 3/30/2018 9:26 AM, Rafał Miłecki wrote: >> >> On 23 March 2018 at 10:31, Arend van Spriel >> <arend.vanspriel@broadcom.com> wrote: >>> >>> On 3/22/2018 4:58 PM, Dan Haab wrote: >>>> >>>> >>>> From: Dan Haab <dhaab@luxul.com> >>>> >>>> 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 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. > 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.
On 4/3/2018 12:17 PM, Rafał Miłecki wrote: > On 3 April 2018 at 10:22, Arend van Spriel <arend.vanspriel@broadcom.com> 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 <arend.vanspriel@broadcom.com> wrote: > On 4/3/2018 12:17 PM, Rafał Miłecki wrote: >> >> On 3 April 2018 at 10:22, Arend van Spriel <arend.vanspriel@broadcom.com> >> 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. Sounds great, thanks, I keep by fingers crossed :)
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