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;
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 0419FC433CB
From:   Kalle Valo <kvalo@codeaurora.org>
To:     Arend Van Spriel <arend.vanspriel@broadcom.com>
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>
Subject: Re: [PATCH v2] brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2
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>
Date:   Wed, 29 Jan 2020 17:02:09 +0200
In-Reply-To: <71763ca9-ed7a-2403-b85a-d7dc624cd050@broadcom.com> (Arend Van
        Spriel's message of "Tue, 28 Jan 2020 10:47:37 +0100")
Message-ID: <87a766xq4u.fsf@tynnyri.adurom.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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 :)

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches