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

[Sean Young <sean@mess.org>]

On Tue, Feb 21, 2017 at 11:52:24PM +0100, Matthias Reichl wrote:
> On Tue, Feb 21, 2017 at 07:34:39PM +0000, Sean Young wrote:
> > On Tue, Feb 21, 2017 at 07:49:29PM +0100, Matthias Reichl wrote:
> > > 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.
> > 
> > Hmm this seems to be working fine for me. If you write to the protocols
> > file, eg. "echo +nec > /sys/class/rc/rc0/protocols", is ir-nec-decoder
> > loaded and do you get any messages in dmesg (you should).
> > 
> > What's your config?
> 
> When I do an "echo +nec > /sys/class/rc/rc0/protocols" it triggers
> the load of both rc5 and nec decoder modules:
> 
> root@rpi3:~# 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]
> root@rpi3:~# echo +nec > /sys/class/rc/rc0/protocols
> root@rpi3:~# 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]
> root@rpi3:~# dmesg | grep "IR "
> [    3.565061] Registered IR keymap rc-hauppauge
> [    3.613031] lirc_dev: IR Remote Control driver registered, major 242
> [    3.641423] IR LIRC bridge handler initialized
> [   41.877263] IR RC5(x/sz) protocol handler initialized
> [   41.931575] IR NEC protocol handler initialized
> 
> I'm currently testing with downstream RPi kernel 4.9 on Raspbian Jessie
> (a Debian derivate).
> 
> Kernel config is here:
> https://github.com/raspberrypi/linux/blob/rpi-4.9.y/arch/arm/configs/bcm2709_defconfig
> 
> To reproduce the issue it's important to disable the udev rule that
> runs ir-keytable -a as that can trigger a load of the kernel keytable
> via the userspace keymap/protocol.

Ah. Yes, this is broken. In commit "9f0bf36 [media] media: rc: preparation
for on-demand decoder module loading", code was added so that only the
required decoder module was loaded. This added it to the sysfs protocols
attribute handling, but not to the rc_register_device(), so no decoder
will be loaded when a device is first registered.

As you say the udev rule papers over the problem by executing ir-keytable,
so I never noticed the problem either.

I'll send a patch as a reply to this email.


Sean