linux-kernel - Re: [PATCH resend] [media] rc-core: fix protocol_change regression in ir_raw_event

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <20141018201856.6e7a8435.m.chehab@samsung.com>
Date:	Sat, 18 Oct 2014 20:18:56 +0200
From:	Mauro Carvalho Chehab <m.chehab@...sung.com>
To:	Tomas Melin <tomas.melin@....fi>
Cc:	james.hogan@...tec.com,
	Antti Seppälä <a.seppala@...il.com>,
	linux-media@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH resend] [media] rc-core: fix protocol_change regression in
 ir_raw_event_register

Em Sat, 18 Oct 2014 13:10:01 +0300
Tomas Melin <tomas.melin@....fi> escreveu:

> On Thu, Oct 16, 2014 at 11:49 PM, David Härdeman <david@...deman.nu> wrote:
> > I think this is already addressed in this thread:
> > http://www.spinics.net/lists/linux-media/msg79865.html
> The patch in that thread would have broken things since the
> store_protocol function is not changed at the same time. The patch I
> sent also takes that into account.
> 
> My concern is still that user space behaviour changes.
> In my case, lirc simply does not work anymore.

Yeah, lirc should be enabled by default.

> More generically,
> anyone now using e.g. nuvoton-cir with anything other than RC6_MCE
> will not get their devices working without first explictly enabling
> the correct protocol from sysfs or with ir-keytable.

The right behavior here is to enable the protocol as soon as the
new keycode table is written by userspace.

Except for LIRC and the protocol of the current table enabled is
not a good idea because:

	1) It misread the code from some other IR;
	2) It will be just spending power without need, running
	   several tasks (one for each IR type) with no reason, as the
	   keytable won't match the codes for other IRs (and if it is
	   currently matching, then this is a bad behavior).

> Correct me if I'm wrong but the change_protocol function in struct
> rc_dev is meant for changing hardware decoder protocols which means
> only a few drivers actually use it.

Actually, most drivers are for hardware decoders.

> So the added empty function
> change_protocol into rc-ir-raw.c doesnt really make sense in the first
> place.
> 
> Tomas


-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/