Felix Fietkau <nbd@xxxxxxxx> writes: > On 2020-04-28 13:07, Kalle Valo wrote: >> Lorenzo Bianconi <lorenzo@xxxxxxxxxx> 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@xxxxxxxxxx> >>> --- >>> .../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
