From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.tuxedocomputers.com (mail.tuxedocomputers.com [157.90.84.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C37AC48CEE; Wed, 10 Jan 2024 13:51:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=tuxedocomputers.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tuxedocomputers.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=tuxedocomputers.com header.i=@tuxedocomputers.com header.b="rgs21n+s" Received: from [192.168.42.20] (p5de453e7.dip0.t-ipconnect.de [93.228.83.231]) (Authenticated sender: wse@tuxedocomputers.com) by mail.tuxedocomputers.com (Postfix) with ESMTPSA id 9B8652FC0057; Wed, 10 Jan 2024 14:51:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxedocomputers.com; s=default; t=1704894704; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=45PF4SKouCDbeha7fnHOqQp65vlx3cmuT9w/Tvpf/YY=; b=rgs21n+sRKB7C+ayhXpDXTrqzvo0Luly1w7G34zfcM9HUxfrG5fXNFLB0V7bELGpLMvHn8 SRfNuSzXKJ6QQ2xqJMmqzgEUyOZsfRxiz7RvB7jbAA2oxqymxScVTk13AzKeZTeAobWXas VYgRhZjeEs/EcO6t3Suw5bghQuiACe8= Authentication-Results: mail.tuxedocomputers.com; auth=pass smtp.auth=wse@tuxedocomputers.com smtp.mailfrom=wse@tuxedocomputers.com Message-ID: Date: Wed, 10 Jan 2024 14:51:44 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/2] i8042: Add forcenorestore quirk to leave controller untouched even on s3 Content-Language: en-US To: Dmitry Torokhov Cc: hdegoede@redhat.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org References: <20240104183118.779778-1-wse@tuxedocomputers.com> <20240104183118.779778-2-wse@tuxedocomputers.com> From: Werner Sembach In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Am 09.01.24 um 22:48 schrieb Dmitry Torokhov: > Hi Werner, > > On Thu, Jan 04, 2024 at 07:31:17PM +0100, Werner Sembach wrote: >> On s3 resume the i8042 driver tries to restore the controller to a known >> state by reinitializing things, however this can confuse the controller >> with different effects. Mostly occasionally unresponsive keyboards after >> resume. >> >> These issues do not rise on s0ix resume as here the controller is assumed >> to preserved its state from before suspend. >> >> This patch adds a quirk for devices where the reinitialization on s3 resume >> is not needed and might be harmful as described above. It does this by >> using the s0ix resume code path at selected locations. >> >> This new quirk goes beyond what the preexisting reset=never quirk does, >> which only skips some reinitialization steps. > I think the original change mentioned not only issues on resume, but > also after boot, which this one does not address, at least directly, so > I am not sure if this patch is the proper replacement. The original change introduced issues after boot and fixed issues after resume. The new quirk fixes the issues after resume without introducing issues after boot. The issues after boot where only affecting the NHxxRZQ and the N1xxCU iirc. > > I would also like to understand better what exact step is troublesome, > as I would be surprised if any interaction with the keyboard > controller while suspending causes the issue to manifest. Is it enough, > by chance, to skip restoring MUX mode and reset? SERIO_QUIRK_NOMUX and SERIO_QUIRK_RESET_ALWAYS are required in the old fix for the resume issues to go away (I don't know if SERIO_QUIRK_NOLOOP and SERIO_QUIRK_NOPNP are required, I threw them in just in case because we were running them already on the device, so they where somewhat "field proven" to not break things). However while SERIO_QUIRK_NOMUX and SERIO_QUIRK_RESET_ALWAYS for themself did not individually introduce the boot problem, in combination they did. That was all I was able to find out back when I tested the old quirks. > > Also, shoudl this system use s2idle by chance? N1xxCU is s3 only (intel 10th gen clevo) > > Thanks. >