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;
Sender: Larry Finger <larry.finger@gmail.com>
Message-ID: <f5e75b2b-14eb-7ffc-6716-70324d2d13c5@lwfinger.net>
Date:   Mon, 17 Jul 2023 15:25:34 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: rtw89 driver and compressed firmware files
To:     Takashi Iwai <tiwai@suse.de>, Ping-Ke Shih <pkshih@realtek.com>
Cc:     linux-wireless@vger.kernel.org
References: <87zg3uvawm.wl-tiwai@suse.de>
Content-Language: en-US
From:   Larry Finger <Larry.Finger@lwfinger.net>
In-Reply-To: <87zg3uvawm.wl-tiwai@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 7/17/23 10:02, Takashi Iwai wrote:
> Hi,
> 
> while debugging a reported rtw89 issue
>    https://bugzilla.suse.com/show_bug.cgi?id=1212808
> we noticed that rtw89 driver didn't load the firmware properly.
> 
> And, this turned out that it's because the driver uses
> request_partial_firmware_into_buf() function with the combination of
> compressed firmware files (that are standard on some distros like
> openSUSE).
> It's a known limitation of the request_partial_firmware_into_buf() API
> function itself; it won't load compressed files, because otherwise
> it'd have to read the full data.  That said, the use of
> request_partial_*() should be only for very limited use cases, and
> this doesn't look fitting well for rtw89.
> (And, as usual, the information is missing in the documentation :-<
> The API document should state it clearly; I'm going to submit a patch
> to add the information.)
> 
> There was already a workaround for CONFIG_SECURIY_LOADPIN_ENFORCE for
> a similar problem, but such a fallback is required in general for all
> cases, as it seems.
> 
> I can cook a hackish patch for the fallback, but I wonder whether it
> still makes sense to keep the use of that API function.  rtw89 is the
> only driver except for bcm-vk (where the API was introduced just for
> this driver), after all...

Takashi,

I am trying to duplicate the OPs problem in boo#1212808. I am currently running 
with an RTW8851BE, thus I must use kernel 6.5-rc2, or the repo at 
https://github.com/lwfinger/rtw89.git, which is the source for the Hardware 
entry at openSUSE. The firmware loading code is common for my chip and the 
RTW8852BE in the bugzilla entry. In my dmesg output, I see the following:

[  160.142412] rtw89_8851be 0000:02:00.0: Direct firmware load for 
rtw89/rtw8851b_fw.bin failed with error -2
[  160.142418] rtw89_8851be 0000:02:00.0: failed to early request firmware: -2
[  160.170098] rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.0, cmd 
version 0, type 5
[  160.170103] rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.0, cmd 
version 0, type 3
[  160.505451] rtw89_8851be 0000:02:00.0: chip rfe_type is 1
[  160.551131] rtw89_8851be 0000:02:00.0 wls1: renamed from wlan0

The first attempt fails, but the second works. The firmware file in question is 
xz compressed. This result was obtained with the in-kernel version of the driver.

All of this was done using Tumbleweed. My next step will be to try Leap 15.5 and 
Leap 15.4. I will report those tests later.

Larry