linux-kernel - Re: [RFC v2] Another approach to IR

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: <m37ht33oro.fsf@intrepid.localdomain>
Date:	Thu, 03 Dec 2009 19:18:03 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Jon Smirl <jonsmirl@...il.com>, Jarod Wilson <jarod@...sonet.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jarod Wilson <jarod@...hat.com>,
	Devin Heitmueller <dheitmueller@...nellabs.com>,
	Maxim Levitsky <maximlevitsky@...il.com>, awalls@...ix.net,
	j@...nau.net, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	lirc-list@...ts.sourceforge.net, superm1@...ntu.com,
	Christoph Bartelmus <lirc@...telmus.de>
Subject: Re: [RFC v2] Another approach to IR

Mauro Carvalho Chehab <mchehab@...hat.com> writes:

> Btw, looking at that code, while it is not impossible to split the 
> IR pulse/space measures from the NEC decoder itself, and make it generic
> to support other protocols, it is not a trivial task, and may result on
> a less stable driver.

And it's not needed at all.
Protocol decoders can be easily run in parallel, I've done it on saa713x
and this is trivial at least there. Can do that when the lirc interface
is available.

> The advantage of the NEC decoding approach on saa7134 is that you know for
> sure how much time it is required to get the entire code. So, the code 
> can easily abort the reception of a bad code. The disadvantage is that 
> only one protocol can be decoded at the same time.

This isn't a hard thing to fix.

> The same problem also happens with almost all in-kernel drivers: the decoders
> for raw mode were constructed to work with just one pulse/space code at the
> same time. A conversion into a generic code can happen, but it will require
> several tests to be sure that they won't cause undesirable side-effects.

IOW any such receiver has to be tested, sure.

> The advantage of hardware decoders is that you don't need to be polling the
> IR serial port at a high rate, as you'll get directly the code. So, you'll
> free the CPU to do something else.

Which device requires polling the port?
Most are IRQ-driven, aren't they?
-- 
Krzysztof Halasa
--
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/