Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 4CA15C433CB
From:   Kalle Valo <kvalo@codeaurora.org>
To:     Felix Fietkau <nbd@nbd.name>
Cc:     Lorenzo Bianconi <lorenzo@kernel.org>,
        linux-wireless@vger.kernel.org, lorenzo.bianconi@redhat.com,
        sean.wang@mediatek.com, linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] mt76: mt7663: add the possibility to load firmware v2
References: <db72b648024aba3243ee3b7deceb548c9bc2bdf1.1587911939.git.lorenzo@kernel.org>
        <87ftcnj2be.fsf@tynnyri.adurom.net>
        <fd49291e-173e-20b0-ee67-c4f519ce8419@nbd.name>
Date:   Tue, 28 Apr 2020 14:38:51 +0300
In-Reply-To: <fd49291e-173e-20b0-ee67-c4f519ce8419@nbd.name> (Felix Fietkau's
        message of "Tue, 28 Apr 2020 13:16:56 +0200")
Message-ID: <87k11zlu0k.fsf@codeaurora.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Felix Fietkau <nbd@nbd.name> writes:

> On 2020-04-28 13:07, Kalle Valo wrote:
>> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>> 
>>> mt7663 firmware v2 is used for embedded devices since it has more completed
>>> features in AP mode.
>>> Add the capability to specify in mt7615 Kconfig which firmware load first
>>> (v3 or v2) and fallback to the other one if the selected firmware fails
>>> to load
>>>
>>> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>>> ---
>>>  .../net/wireless/mediatek/mt76/mt7615/Kconfig | 13 +++++
>>>  .../net/wireless/mediatek/mt76/mt7615/mcu.c   | 50 ++++++++++++++++---
>>>  .../wireless/mediatek/mt76/mt7615/mt7615.h    |  6 ++-
>>>  .../net/wireless/mediatek/mt76/mt7615/pci.c   |  2 +
>>>  .../net/wireless/mediatek/mt76/mt7615/usb.c   |  2 +
>>>  5 files changed, 65 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/Kconfig b/drivers/net/wireless/mediatek/mt76/mt7615/Kconfig
>>> index e25db1135eda..c04d6a182bf0 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/Kconfig
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/Kconfig
>>> @@ -38,3 +38,16 @@ config MT7663U
>>>  	  This adds support for MT7663U 802.11ax 2x2:2 wireless devices.
>>>  
>>>  	  To compile this driver as a module, choose M here.
>>> +
>>> +config MT7615_OFFLOAD_FIRMWARE
>>> +	bool "Prefer client mode offload firmware (MT7663)"
>>> +	depends on MT7615E || MT7663U
>>> +	default y
>>> +	help
>>> +	  Load MT7663 client mode offload firmware (v3) as primary option
>>> +	  and fallback to MT7663 firmware v2 in case of failure.
>>> +	  If MT7615_OFFLOAD_FIRMWARE is not selected MT7663 firmware v2
>>> +	  will be used as primary option.
>>> +	  MT7663 client mode offload firmware supports low power features
>>> +	  (hw frequency scanning, scheduled frequency scanning, WoW,
>>> +	  802.11 power save) but is more limited in AP mode
>> 
>> Why does this need a compile time config? Wouldn't some kind of runtime
>> configuration be better?
>
> I don't think supporting runtime configuration is worth the extra
> complexity of adding an API for shutting down and restarting the
> firmware and dealing with potential errors along the way.
>
> Both firmware types support AP and client mode. Which one you use
> depends on the kind of system you're building for.
>
> If you're building an embedded AP, you don't need any low power offloads
> and may want to support more than 32 clients, so you'd disable this
> configuration option.
>
> If you run the driver on a laptop or desktop machine, you will most
> likely stick to the default.

Yeah, the need for this kind of "firmware settings" interface comes up
frequently, for example to provide settings to the firmware before it's
loaded or choosing which firmware image to load. It would be great to
find a generic solution for that. IIRC someone suggested devlink at some
point but no idea if that would help here.

> If you want to switch without recompiling, you can always just delete
> the set of firmware files you don't want to use. The driver will fall
> back to the other type.

My problem here is the new Kconfig option and the way I see is that this
feature doesn't justify the need of a new Kconfig option. A Kconfig
option shouldn't change the driver behaviour, it should be more about
enabling and disabling components and other compilation specific
configuration.

What about a module parameter? That would be much better and at least I
can't think of a technical reason why it wouldn't work.

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