linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

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:	Thu, 03 Dec 2009 18:45:26 -0500
From:	Andy Walls <awalls@...ix.net>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Gerd Hoffmann <kraxel@...hat.com>,
	Jarod Wilson <jarod@...sonet.com>,
	Christoph Bartelmus <lirc@...telmus.de>,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	jonsmirl@...il.com, khc@...waw.pl, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

On Thu, 2009-12-03 at 19:10 -0200, Mauro Carvalho Chehab wrote:
> Gerd Hoffmann wrote:
> 
> > One final pass over the lirc interface would be good, taking the chance
> > to fixup anything before the ABI is set in stone with the mainline
> > merge.  Things to look at:

> >   (3) Someone suggested a 'commit' ioctl which would activate
> >       the parameters set in (multiple) previous ioctls.  Makes sense?
> 
> A better approach is to create an ioctl that can send a group of value/attribute pairs
> at the same time. We used this estrategy for V4L extended controls to do things like
> setting an mpeg encoder (were we need to adjust several parameters at the same time,
> and adding all of them on one struct would be hard, since you can't specify all
> of them sa the same time). The same strategy is also used by DVB API to allow it
> to use any arbitrary protocol. It was conceived to support DVB-S2.

Gerd,

I mentioned it.  The reason that I mentioned it is that partial
configuration, before all the IOCTLs are done, of the IR chips that I
work with *may* cause:

1. Unnecessary, extra I2C bus operations leading to delay on
configuration.  That's no big deal as it would really only matter for a
genuine discrete CX2584x chip with IR implemented using the integrated
IR controller.  I do not know of any TV capture cards wired up like
that.

2. If the Low Pass Filter gets turned off, or set to very short time
interval, bad ambient light conditions could create an "interrupt
storm".  As soon as all the IOCTLs complete, the storm would stop.

We can probably do without the change in lirc_dev ioctl() altogether,
since it only *really* affects one set of chips  that I work with, and
only during configuration.  I could instead implement interrupt storm
detection and interrupt rate limiting for those devices.

BTW IIRC, LIRC likes to resend the ioctl() to set the carrier frequency
over again when it goes to transmit.  That's kind of annoying, but I can
work around that too by caching a copy of the carrier freq LIRC set the
last time.

Regards,
Andy

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