Messages in this thread | | | Date | Sat, 4 Oct 2008 15:39:29 -0700 | From | Andrew Morton <> | Subject | Re: [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.
| |