linux-kernel - Re: [PATCH] media: av7110: switch to useing timer

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20171031172758.ugfo6br344iso4ni@gofer.mess.org>
Date:   Tue, 31 Oct 2017 17:27:58 +0000
From:   Sean Young <sean@...s.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Kees Cook <keescook@...omium.org>, linux-media@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: av7110: switch to useing timer_setup()

On Tue, Oct 24, 2017 at 05:40:05PM -0700, Dmitry Torokhov wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Also stop poking into input core internals and override its autorepeat
> timer function. I am not sure why we have such convoluted autorepeat
> handling in this driver instead of letting input core handle autorepeat,
> but this preserves current behavior of allowing controlling autorepeat
> delay and forcing autorepeat period to be whatever the hardware has.

I think a better solution is to remove the autorepeat handling completely,
and leave it up to the input layer. This simplies the driver greatly and
I don't see how this makes sense for an IR driver. The IR protocols
specify the IR should repeat the message at set intervals whilst a 
button is pressed; this has no relation to autorepeat.

Ideally this driver would be converted to rc-core, but without access to
the hardware I'm not sure that is a great idea. The keymap handling is
very convolated so I have no idea what the scancodes for the remote(s) are,
for example. Any suggestions for what hardware to get off ebay for this?

New patch will be reply this.

Thanks,

Sean