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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ