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: <7571dbf0-5a2d-8ab3-70ab-5ca53f799803@lwfinger.net>
Date:   Mon, 17 Jul 2023 17:23:27 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.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 have completed my tests of Leap 15.5. I had to manually copy the firmware for 
the 8851BE to /lib/firmware/rtw89, but once I did that, the following was logged:

[ 1572.450392] rtw89_8851be 0000:02:00.0: Direct firmware load for 
rtw89/rtw8851b_fw.bin failed with error -2
[ 1572.450397] rtw89_8851be 0000:02:00.0: failed to early request firmware: -2
[ 1572.470196] rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.0, cmd 
version 0, type 5
[ 1572.470204] rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.0, cmd 
version 0, type 3
[ 1572.801867] rtw89_8851be 0000:02:00.0: chip rfe_type is 1
[ 1572.842343] rtw89_8851be 0000:02:00.0 wlan2: renamed from wlan1

This result was obtained with kernel 5.14.21-150500.53-default.

Yes, the request_partial_firmware_into_buf() failed, but the next attempt 
succeeded. The firmware in question was xz-compressed.

I cannot duplicate the OP's result. I will try next with Leap 15.4, but I do not 
expect a different result.

Larry