On Thu, Oct 19, 2017 at 3:48 PM, Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> wrote:
> 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@xxxxxxxxx> 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...
I don't know how to fix this, but I still need to do this refactoring.
What's the correct step forward here? Should I temporarily disable the
timer in av7110?
Seems like the hijacking was introduced in ee820a648fb3 ("V4L/DVB
(5334): Dvb-ttpci: Infrared remote control refactoring").
Thanks!
-Kees
--
Kees Cook
Pixel Security
