Inaccurate deblobbing breaks rtl8192ce

[Lobachevskii Vitalii]

Hello,
thanks for your reply.

On 08/18/2016 10:14 PM, Alexandre Oliva wrote:
> 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 ;-)

Tested. It works after full power-off (no hibernation, battery removed).
Not perfectly, I had to reboot the system second time to make it work;
not sure was that problem caused by the driver or some user-space tools.
But patched version works fine after suspend/hibernation, while Arch one
required driver reload (like rmmod rtl8192ce; udevadm trigger /sys/...)
on each resume.

It reports errors like this on boot (dmesg):
[ 4583.110840] BUG: scheduling while atomic: wpa_supplicant/440/0x00000002
[ 4583.466167] BUG: scheduling while atomic: wpa_supplicant/440/0x00000000
but still works. Not sure may that be related to this specific problem.

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

Sorry, missed that.

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

I will, as that appeared to be their fail... or rather Realtek
unwillingness to let their driver work without the proprietary firmware.

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

I will try to make it call the callback asynchronously, just as
request_firmware_nowait does. That may be a bit of overkill, and I am
not even sure that that is better, but who knows what will confuse more
drivers...

Really, Realtek drivers are weird. Sometimes they work, sometimes don’t;
often they need reload after suspend to work... or to work better. (I
have several Realtek chips, all with similar problems)

-- 
Lobachevskii Vitalii  https://github.com/numberZero