On Mon, 17 Jul 2023 22:25:34 +0200, Larry Finger wrote: > > 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. Thanks Larry, but I guess that it happens only for multi versions such as rtw8852b that have rtw8852a_fw.bin and rtw8852a_fw-1.bin, while yours is rtw8851b that has only one firmware version. And, the driver might look as if still "working". IIUC, it's only that the new firmware version won't be used as long as the firmware files are compressed. You can see more details by passing firmware_class.dyndbg=+p boot option. > 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. Note that the problem of the firmware loader is likely irrelevant with the actual issue in the bugzilla entry above; I only gave as a reference. It seems that the bug there was due to the error: rtw89_8852be 0000:02:00.0: [ERR]pci config read 719 rtw89_8852be 0000:02:00.0: [ERR] pcie autok fail -22 rtw89_8852be 0000:02:00.0: failed to setup chip information Since reloading the module works, this might be related with the PCI power state or something else. But it's a different topic from this thread, which is about the firmware loader problem. Takashi
