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;
Date:   Mon, 17 Jul 2023 17:02:33 +0200
Message-ID: <87zg3uvawm.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     Ping-Ke Shih <pkshih@realtek.com>
Cc:     linux-wireless@vger.kernel.org
Subject: rtw89 driver and compressed firmware files
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

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... 


thanks,

Takashi