Bug: decoders referenced in kernel rc-keymaps not loaded on boot

[Matthias Reichl <hias@horus.com>]

There seems to be a bug in on-demand loading of IR protocol decoders.

After bootup the protocol referenced in the in-kernel rc keymap shows
up as enabled (in sysfs and ir-keytable) but the protocol decoder
is not loaded and thus no rc input events will be generated.

For example, RPi3 with kernel 4.10 and gpio-ir-recv configured to use
the rc-hauppauge keymap in devicetree:

# lsmod | grep '^\(ir\|rc_\)'
ir_lirc_codec           5590  0
rc_hauppauge            2422  0
rc_core                24320  5 rc_hauppauge,ir_lirc_codec,lirc_dev,gpio_ir_recv

# cat /sys/class/rc/rc0/protocols
other unknown [rc-5] nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp cec [lirc]

# dmesg | grep "IR "
[    4.506728] Registered IR keymap rc-hauppauge
[    4.554651] lirc_dev: IR Remote Control driver registered, major 242
[    4.576490] IR LIRC bridge handler initialized

The same happens with other IR receivers, eg the streamzap receiver,
which uses the rc-5-sz protocol / ir_rc5_decoder, on x86.

Reverting the on-demand-loading patches

[media] media: rc: remove unneeded code
commit c1500ba0b61e9abf95e0e7ecd3c4ad877f019abe

[media] media: rc: move check whether a protocol is enabled to the core
commit d80ca8bd71f0b01b2b12459189927cb3299cfab9

[media] media: rc: load decoder modules on-demand
commit acc1c3c688ed8cc862ddc007eab0dcef839f4ec8

restores the previous behaviour, all decoders are enabled and IR
events can be generated immediately after boot without having to
manually trigger loading of a protocol decoder.

so long,

Hias