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 _______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
