<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hello,<br>
</p>
<p>About “surprising” the driver: <tt>-EINVAL</tt> means that
firmware load machinery is absent, while the <tt>rtl8192ce</tt>
driver (as well as many others) explicitly depend on it (<tt>select
FW_LOADER</tt>), so that’s not possible in any correct kernel
configuration.</p>
<p>Anyway, driver maintainers answered. Well, I expected such
answer. And I’m afraid they’re right in that the device runs some
firmware anyway; that may be the firmware included on production
or last loaded (or maybe EFI loads it on boot? well, don’t know).</p>
<p>Actually, for a long time I wanted to ask: what’s the real point
to remove firmware from the kernel? That’s not security: complex
devices can’t work without a firmware, so either they don’t work
at all or have some sort of built-in firmware, that may pose all
the same security risks; that’s not the freedom, as unchangeable
program on disk isn’t any worse than unchangeable program in ROM;
so what?</p>
<p>By the way, I tried the approach with callback calling, it seems
it doesn’t break anything but neither lets this driver (unaltered)
to work. And the modified driver works somewhat, often crashing
the program that tries to perform scan (tested <tt>wpa_supplicant</tt>
and <tt>iw</tt>, both crash with <tt>SEGFAULT</tt>). It seems
that depends on the device state on boot/resume, which can be
different for some reason.<br>
</p>
<pre class="moz-signature" cols="72">--
Lobachevskii Vitalii <a class="moz-txt-link-freetext" href="https://github.com/numberZero">https://github.com/numberZero</a></pre>
<div class="moz-cite-prefix">On 18.08.2016 22:14, Alexandre Oliva
wrote:<br>
</div>
<blockquote cite="mid:ortwehao06.fsf@livre.home" type="cite">
<pre wrap="">Hi,
Thanks for your report!
On Aug 13, 2016, number Zero <a class="moz-txt-link-rfc2396E" href="mailto:silverunicorn2011@yandex.ru"><silverunicorn2011@yandex.ru></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">However, after I made it to ignore the EINVAL error from the
reject_firmware_nowait function (in
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c), it works fine.
</pre>
</blockquote>
<pre wrap="">
Interesting. Can you check that this remains true even after a full
power cycle, as in, that it's not a blob loaded by a previous blobbed
kernel that remains it to work in your setting? (if you never had the
blob around, or never used a blobbed kernel, just say so, and I'll be
happy enough about the conclusion ;-)
</pre>
<blockquote type="cite">
<pre wrap="">Really, are there any reasons for reject_firmware_nowait to return
-EINVAL?
</pre>
</blockquote>
<pre wrap="">
Yes. It the error code to indicate to the caller that the firmware
loading functionality is not avaialble. It indicates the callback
supplied by the caller will not be called, so the caller itself should
take care of e.g. returning any temporary memory the callback would have
released.
If the driver works even if request_firmware_nowait returns such an
error, then it ought to tolerate this return code.
</pre>
<blockquote type="cite">
<pre wrap="">So shouldn’t the reject_firmware_nowait function behave as if the
requested firmware merely absent?
</pre>
</blockquote>
<pre wrap="">
Given the multiple cases in which drivers were "surprised" by this
return code, I guess we could try to rework reject_firmware_nowait so as
to actually call the callback, signalling the unsuccessful completion of
the request. Would you like to give that a try?
Or perhaps you'd prefer to report the bug to the rtl8192ce maintainers,
so that they could fix their driver so as to work (as it should) even
when the firmware loading configuration option is disabled?
Thanks,
</pre>
</blockquote>
</body>
</html>