Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Kalle Valo <kvalo@kernel.org>
To:     Ping-Ke Shih <pkshih@realtek.com>
Cc:     "linux-wireless\@vger.kernel.org" <linux-wireless@vger.kernel.org>,
        "Kevin Yang" <kevin_yang@realtek.com>
Subject: Re: [PATCH 13/13] rtw89: prohibit mac80211 chanctx ops without HW scan
References: <20220617084954.61261-1-pkshih@realtek.com>
        <20220617084954.61261-14-pkshih@realtek.com>
        <877d5bprxn.fsf@kernel.org>
        <027f1de5f6ed0da21754c17154cc09411f2c5aa5.camel@realtek.com>
        <6f6682f8d8c7aec02d113330c87484cbcab14ff3.camel@realtek.com>
        <b8f7720937e05c6fd7fde14b8ea57065879928a8.camel@realtek.com>
Date:   Fri, 02 Sep 2022 11:28:26 +0300
In-Reply-To: <b8f7720937e05c6fd7fde14b8ea57065879928a8.camel@realtek.com>
        (Ping-Ke Shih's message of "Tue, 9 Aug 2022 11:00:12 +0000")
Message-ID: <87ler2b2ol.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Ping-Ke Shih <pkshih@realtek.com> writes:

>> > > So if the user has not update the firmware a kernel upgrade will break
>> > > their internet? That's not good, we should not break existing setups. So
>> > > what firmware version is required?
>> > > 
>> > 
>> > Firmware version 0.13.35.0 is required. The firmware has been in
>> > linux-firmware repository on 2022-02-18. I think people being able
>> > to update kernel can update firmware as well.
>> > 
>> > The alternative ways could be
>> > 1. add a module parameter, like no_channel_context. We can add a
>> >    prompt to note people can set it to 1 for old firmware.
>> > 
>> > 2. wait version of request_firmware() as first step of pci probe.
>> >    The probe could cost longer time, because currently we use
>> >    request_firmware_nowait() and continue to initialize in parallel.
>> >    More, hw->priv isn't allocated at that moment, so it could be not
>> >    so straightforward.
>> > 
>> 
>> To prevent break users' existing setups, modified approach 1 is adopted
>> by patchset v2. We add a module parameter rtw89_use_chanctx, and disable
>> it by default. So, users' setups with old firmware can still work.
>> 
>> If a user wants channel context to support concurrency, he can set
>> rtw89_use_chanctx=1 and upgrade firmware. 
>> 
>> I think this could be a better user experience of kernel.
>> 
>
> We have a better idea that load firmware header and parse firmware
> features when probing before ieee80211_register_hw(). If firmware
> doesn't support hw_scan, it still can work as original. So, users
> don't need to update firmware or set module parameters.
>
> I have sent v3 with this idea that is friendly to users.

Sorry for the delay, I was not able to look at this in detail earlier.

Indeed v3 is much better approach and actually what we prefer in
upstream. iwlwifi, ath10k and ath11k do something similar. Forcing users
to update the firmware or fiddling with module parameters when updating
the kernel is bad from user's point of view.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

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