Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v2] brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2
To:     Kalle Valo <kvalo@codeaurora.org>
Cc:     "brian m. carlson" <sandals@crustytoothpaste.net>,
        linux-wireless@vger.kernel.org,
        brcm80211-dev-list.pdl@broadcom.com,
        brcm80211-dev-list@cypress.com,
        Franky Lin <franky.lin@broadcom.com>,
        Hante Meuleman <hante.meuleman@broadcom.com>,
        Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
        Wright Feng <wright.feng@cypress.com>
References: <20200126155108.7DDD7C433CB@smtp.codeaurora.org>
 <20200126193339.167346-1-sandals@crustytoothpaste.net>
 <16fe3b278d0.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
 <20200126230029.GI4113372@camp.crustytoothpaste.net>
 <71763ca9-ed7a-2403-b85a-d7dc624cd050@broadcom.com>
 <87a766xq4u.fsf@tynnyri.adurom.net>
From:   Arend Van Spriel <arend.vanspriel@broadcom.com>
Message-ID: <2a7409b1-df6a-4d94-6a28-d69990ba01eb@broadcom.com>
Date:   Fri, 31 Jan 2020 09:50:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <87a766xq4u.fsf@tynnyri.adurom.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk


On 1/29/2020 4:02 PM, Kalle Valo wrote:
> Arend Van Spriel <arend.vanspriel@broadcom.com> writes:
> 
>>> There is also precedent for users acquiring firmware themselves via the
>>> b43 and b43legacy drivers, where users have to use a script to extract
>>> the firmware from other drivers.
>>>
>>> I wish I had a better answer to this, but I don't work for Broadcom or
>>> anyone associated with it and am just trying to get the Mac I was given
>>> for $DAYJOB to work with Linux.  Perhaps since you do you'd be willing
>>> to ask them to release the firmware.
>>>
>>> The alternative is that the chip doesn't work at all (and can't be added
>>> via the new_id sysfs entry because of the rambase setting) and users
>>> have to compile a custom patched kernel to make their wireless card work
>>> at all.  I'd really prefer to avoid that if possible, since it's
>>> a strictly worse experience in every way.
>>
>> How about putting this device under some Kconfig flag. If distro
>> kernel start probing the device and fail, most users will probably
>> turn to their distro for help. Having a Kconfig with a good
>> description could avoid that. It would mean an extra step of building
>> the driver though.
> 
> I don't understand the issue you are trying to solve. If the firmware
> image is missing there's a clear error message in the log and the kernel
> continues to operate normally, right? That way users have a clear
> understanding why their wireless is not working, and hopefully push
> Broadcom to release the firmware with a suitable license :)

Hi Kalle,

Actually as there is precedent of firmwareless drivers in distros I am 
fine with the change as is.

Regards,
Arend