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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 14 Oct 2009 01:16:41 +0200
From:	"Carlos R. Mafra" <crmafra2@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	linux-input@...r.kernel.org
Subject: Re: [bisected regression] Touchpad "paste" stops working after
	suspend to RAM

[restoring Cc: list]

On Tue 13.Oct'09 at 13:24:59 -0700, Dmitry Torokhov wrote:
>
> Could you please try this patch (again if you could post dmesg that
> would be great). Thank you!

The patch quoted below also fixes the problem. I attached the
syslog with i8042.debug (with a s2ram in the middle) to the
bugzilla: 

http://bugzilla.kernel.org/show_bug.cgi?id=14392

(cool! the address above was pasted with the touchpad,
so it is really working :-)

Thanks Dmitry!

> 
> Input: atkbd - postpone restoring LED/repeat rate at resume
> 
> From: Dmitry Torokhov <dmitry.torokhov@...il.com>
> 
> We need to postpone restoring LED state and typematic settings until
> keyboard is finished reconnecting upon resume. Normally driver core
> and PM infrastructure takes care of proper ordering and dependencies,
> but or case actual reconnect is done asynchronously from kseriod.
> So while driver core thinks that keyboard was resumed and it is time
> to let input core run it's resume handlers in reality keyboard is not
> ready yet. The solution is to keep rescheduling work that adjusts LED
> and rate settings until keyboard is fully enabled.
> 
> Reported-by: Carlos R. Mafra <crmafra2@...il.com>
> Signed-off-by: Dmitry Torokhov <dtor@...l.ru>
> ---
> 
>  drivers/input/keyboard/atkbd.c |   19 +++++++++++++++----
>  1 files changed, 15 insertions(+), 4 deletions(-)
> 
> 
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index a45157d..022f3cb 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -574,11 +574,22 @@ static void atkbd_event_work(struct work_struct *work)
>  
>  	mutex_lock(&atkbd->event_mutex);
>  
> -	if (test_and_clear_bit(ATKBD_LED_EVENT_BIT, &atkbd->event_mask))
> -		atkbd_set_leds(atkbd);
> +	if (!atkbd->enabled) {
> +		/*
> +		 * Serio ports are resumed asynchronously so while driver core
> +		 * thinks that device is already fully operational in reality
> +		 * it may not be ready yet. In this case we need to keep
> +		 * rescheduling till reconnect completes.
> +		 */
> +		schedule_delayed_work(&atkbd->event_work,
> +					msecs_to_jiffies(100));
> +	} else {
> +		if (test_and_clear_bit(ATKBD_LED_EVENT_BIT, &atkbd->event_mask))
> +			atkbd_set_leds(atkbd);
>  
> -	if (test_and_clear_bit(ATKBD_REP_EVENT_BIT, &atkbd->event_mask))
> -		atkbd_set_repeat_rate(atkbd);
> +		if (test_and_clear_bit(ATKBD_REP_EVENT_BIT, &atkbd->event_mask))
> +			atkbd_set_repeat_rate(atkbd);
> +	}
>  
>  	mutex_unlock(&atkbd->event_mutex);
>  }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ