lkml.org 
[lkml]   [2008]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] rfkill-input doesn't work until 5 minutes after boot
On Sat, 4 Oct 2008 21:43:43 +0100 Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> rfkill-input implements debounce as follows:
>
> if (time_after(jiffies, task->last + msecs_to_jiffies(200))) {
>
> However, task->last is initialised to 0 while jiffies starts at -300*HZ.
> Any input within 5 minutes of kernel start is therefore ignored. Fix by
> initialising task->last correctly.
>
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
>
>
> diff --git a/net/rfkill/rfkill-input.c b/net/rfkill/rfkill-input.c
> index e5b6955..de75934 100644
> --- a/net/rfkill/rfkill-input.c
> +++ b/net/rfkill/rfkill-input.c
> @@ -101,6 +101,7 @@ static void rfkill_schedule_toggle(struct rfkill_task *task)
> .mutex = __MUTEX_INITIALIZER(n.mutex), \
> .lock = __SPIN_LOCK_UNLOCKED(n.lock), \
> .desired_state = RFKILL_STATE_UNBLOCKED, \
> + .last = INITIAL_JIFFIES, \
> }
>
> static DEFINE_RFKILL_TASK(rfkill_wlan, RFKILL_TYPE_WLAN);
>

That'll only work as intended if CONFIG_RFKILL_INPUT=y? If the module
is loaded 10 minutes after boot, the timestamp is still wrong. It might
happily happen to work, but will still fail after 2^31 jiffies (or something
like that).

Generally speaking, INITIAL_JIFFIES is a secret internal debugging
detail and its use out in general kernel code is a red flag.

I think this initialisation should be done at runtime somehow.

> .27 material?

yup.


\
 
 \ /
  Last update: 2008-10-05 00:43    [W:0.191 / U:2.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site