From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 16D6BC43458 for ; Tue, 30 Jun 2026 16:05:50 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6414210ECCE; Tue, 30 Jun 2026 16:05:49 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="Ox1lSUs8"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id 005DB10ECC5; Tue, 30 Jun 2026 16:05:47 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 476CE600BB; Tue, 30 Jun 2026 16:05:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F352A1F000E9; Tue, 30 Jun 2026 16:05:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782835547; bh=GRs8WjcQhEYPcY1IkD3TxIAylDmbtFFFSwtcXiK+ZfU=; h=Date:Subject:Cc:To:From:References:In-Reply-To; b=Ox1lSUs8APxIsUyMFvQd0DXXHeogkAi4cBq7Nizl0YA0oJsHLXSZrXSDjaUxbf1J7 VFdM3rKwRi7eEN9eli1d/LEEGUB/m01MbJEtntsSfXM3plXu7HfFSxaBX6Kaw5eKDC zhRTylalba619x60GkyfjhkL21ZLJRsTAnvKZe137Ed4OVHcBkyEk6wfR2YqOg+JCW 9AyXSMhByZlMFpix4KMGX12NfZXZmy1KNndWd0gUt18ZCZYYhve92toImNVQKaDAHX 08kQELCc79R8VkaNWXTzXpIFb7diJSou5D9IfOTxeFVu1xTL/EpLnPVKdxS3I2Wlkd /DOnQRMPtcXtQ== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 30 Jun 2026 18:05:42 +0200 Message-Id: Subject: Re: [PATCH v2 1/4] Revert "nouveau/gsp: fix suspend/resume regression on r570 firmware" Cc: , , , , "Timur Tabi" , "Dave Airlie" , "Maarten Lankhorst" , "Ben Skeggs" , "Kees Cook" , "Simona Vetter" , "David Airlie" , "Thomas Zimmermann" , "Maxime Ripard" , "Mel Henning" To: "Andy Shevchenko" , "Lyude Paul" From: "Danilo Krummrich" References: <20260629224350.2870201-1-lyude@redhat.com> <20260629224350.2870201-2-lyude@redhat.com> In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue Jun 30, 2026 at 1:53 PM CEST, Andy Shevchenko wrote: > On Mon, Jun 29, 2026 at 06:42:33PM -0400, Lyude Paul wrote: >> This reverts commit 8302d0afeaec0bc57d951dd085e0cffe997d4d18. >>=20 >> It turns out this looked like the right fix on some systems, but it's no= t - >> as this causes runtime PM to actually fail on many a laptop. >>=20 >> [I have set the fixes to an older commit then the one that is reverted >> here, because when applied with the other patches in this series, this >> appears to /fully/ fix runtime PM in addition to the regression] > > No need to have this in the commit message, move it to the comment block.= .. > >> Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144") > > I'm not sure, actually, that this is a correct approach. You can't revert > something that never appeared (in time range between 53dac0623853 and > 8302d0afeaec). Have you consulted with the stable kernel process document= ation > and/or respective maintainers? I think it should be as simple as picking Fixes: 8302d0afeaec ("nouveau/gsp: fix suspend/resume regression on r570 fi= rmware") Cc: # v6.19+ for this commit and keep patches 2, 3 and 4 as they are. The commit message of this revert can then explain that the commit that was attempted to fix with this revert, i.e. commit 53dac0623853 ("drm/nouveau/g= sp: add support for 570.144") is fixed with a different, subsequent approach. This seems correct, as reverting a bad fix does not claim to solve the orig= inal problem. Thanks, Danilo