Inaccurate deblobbing breaks rtl8192ce

[Alexandre Oliva]

Hi,

Thanks for your report!

On Aug 13, 2016, number Zero <silverunicorn2011 at yandex.ru> wrote:

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

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 ;-)

> Really, are there any reasons for reject_firmware_nowait to return
> -EINVAL?

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.

> So shouldn’t the reject_firmware_nowait function behave as if the
> requested firmware merely absent?

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,

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer