Search Linux Wireless

Re: [PATCH] brcmfmac: add support for BCM4366E chipset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3 April 2018 at 10:22, Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> wrote:
> On 3/30/2018 9:26 AM, Rafał Miłecki wrote:
>>
>> On 23 March 2018 at 10:31, Arend van Spriel
>> <arend.vanspriel@xxxxxxxxxxxx> wrote:
>>>
>>> On 3/22/2018 4:58 PM, Dan Haab wrote:
>>>>
>>>>
>>>> From: Dan Haab <dhaab@xxxxxxxxx>
>>>>
>>>> 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.

-- 
Rafał




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux