All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Jonathan Denose <jdenose@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	jefferymiller@google.com, Jonathan Denose <jdenose@google.com>,
	Raul Rangel <rrangel@chromium.org>,
	linux-input@vger.kernel.org, Ike Panhc <ike.pan@canonical.com>,
	Hans de Goede <hdegoede@redhat.com>,
	platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH] Input: psmouse - add resync_on_resume dmi check
Date: Thu, 7 Mar 2024 10:29:04 -0800	[thread overview]
Message-ID: <ZeoHcH59Qsiv90b-@google.com> (raw)
In-Reply-To: <CALNJtpWwhen2H9OT1-rZ4bt+huwXPOPz6qVDJ5g+emE1wRSLsw@mail.gmail.com>

On Mon, Mar 04, 2024 at 11:17:31AM -0600, Jonathan Denose wrote:
> I disabled the ideapad driver by rebuilding the kernel without the
> ideapad_laptop module. That does fix the suspend/resume issue!
> 
> Attached are the logs. Is there a way to make this permanent?
> 
> On Thu, Feb 29, 2024 at 12:23 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > On Mon, Feb 12, 2024 at 02:57:08PM -0600, Jonathan Denose wrote:
> > ...
> > > [   50.241235] ideapad_acpi VPC2004:00: PM: calling acpi_subsys_resume+0x0/0x5d @ 4492, parent: PNP0C09:00
> > > [   50.242055] snd_hda_intel 0000:00:0e.0: PM: pci_pm_resume+0x0/0xed returned 0 after 13511 usecs
> > > [   50.242120] snd_hda_codec_realtek hdaudioC0D0: PM: calling hda_codec_pm_resume+0x0/0x19 [snd_hda_codec] @ 4518, parent: 0000:00:0e.0
> > > [   50.247406] i8042: [49434] a8 -> i8042 (command)
> > > [   50.247468] ideapad_acpi VPC2004:00: PM: acpi_subsys_resume+0x0/0x5d returned 0 after 6220 usecs
> > ...
> > > [   50.247883] i8042 kbd 00:01: PM: calling pnp_bus_resume+0x0/0x9d @ 4492, parent: pnp0
> > > [   50.247894] i8042 kbd 00:01: PM: pnp_bus_resume+0x0/0x9d returned 0 after 0 usecs
> > > [   50.247906] i8042 aux 00:02: PM: calling pnp_bus_resume+0x0/0x9d @ 4492, parent: pnp0
> > > [   50.247916] i8042 aux 00:02: PM: pnp_bus_resume+0x0/0x9d returned 0 after 0 usecs
> > ...
> > > [   50.248301] i8042 i8042: PM: calling platform_pm_resume+0x0/0x41 @ 4492, parent: platform
> > > [   50.248377] i8042: [49434] 55 <- i8042 (flush, kbd)
> > > [   50.248407] i8042: [49435] aa -> i8042 (command)
> > > [   50.248601] i8042: [49435] 00 <- i8042 (return)
> > > [   50.248604] i8042: [49435] i8042 controller selftest: 0x0 != 0x55
> >
> > So here I see the ideapad-laptop driver trying to access i8042 before it
> > even starts resuming. I wonder, does it help if you disable
> > (temporarily) the ideapad driver?

OK, so I tried to cook up a patch that would allow ideapad-laptop driver
to establish device link with i8042 so that the resume will be processed
after i8042 resumes, but the longer I think about it, the more I think
that ideapad driver should not be messing with the touchpad state
directly. The disable event may come up in a middle of the touchpad
resume transition, or when we decide to change touchpad mode for one
reason or another. It also does not respect inhibit/uninhibit controls
for input devices. I think that the proper way for ideapad driver to
handle this is to only send KEY_TOUCHPAD_OFF/KEY_TOUCHPAD_ON to
userspace and let userspace deal with toggling touchpad input (via
inhibit or by other means).

CC-ing ideapad maintainers for their thoughts.

Thanks.

-- 
Dmitry

  parent reply	other threads:[~2024-03-07 18:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02 12:52 [PATCH] Input: psmouse - add resync_on_resume dmi check Jonathan Denose
2024-02-06 22:04 ` Dmitry Torokhov
2024-02-07 16:39   ` Jonathan Denose
2024-02-09 19:01     ` Dmitry Torokhov
2024-02-12 20:57       ` Jonathan Denose
2024-02-29 18:23         ` Dmitry Torokhov
2024-03-04 17:17           ` Jonathan Denose
2024-03-05 18:47             ` Dmitry Torokhov
2024-03-05 21:48               ` Jonathan Denose
2024-03-05 23:17                 ` Dmitry Torokhov
2024-03-06 16:43                   ` Jonathan Denose
2024-03-07 18:29             ` Dmitry Torokhov [this message]
2024-08-05 14:18               ` Hans de Goede
2024-08-05 16:52                 ` Dmitry Torokhov
2024-08-09 15:35                   ` Jonathan Denose
2024-08-10 12:59                     ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZeoHcH59Qsiv90b-@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=ike.pan@canonical.com \
    --cc=jdenose@chromium.org \
    --cc=jdenose@google.com \
    --cc=jefferymiller@google.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rrangel@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.