[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171019224825.h54muomkruk4wtgn@dtor-ws>
Date: Thu, 19 Oct 2017 15:48:25 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
Hans Verkuil <hans.verkuil@...co.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Geliang Tang <geliangtang@...il.com>,
linux-input <linux-input@...r.kernel.org>,
linux-media@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] media: input: Convert timers to use timer_setup()
On Thu, Oct 19, 2017 at 03:45:38PM -0700, Kees Cook wrote:
> On Thu, Oct 19, 2017 at 3:32 PM, Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> > On Mon, Oct 16, 2017 at 04:14:43PM -0700, Kees Cook 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.
> >>
> >> One input_dev user hijacks the input_dev software autorepeat timer to
> >> perform its own repeat management. However, there is no path back to the
> >> existing status variable, so add a generic one to the input structure and
> >> use that instead.
> >
> > That is too bad and it should not be doing this. I'd rather av7110 used
> > its own private timer for that.
>
> Yeah, that was a pretty weird case. I couldn't see how to avoid it,
> though. I didn't see a way to hook the autorepeat, but I'm not too
> familiar with the code here.
You just need to manage the private timer in the driver and not mess up
with the input core if input core's autorepeat does not provide the
desired behavior...
Thanks.
--
Dmitry
Powered by blists - more mailing lists