From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE38F44BC90 for ; Thu, 13 Aug 2026 10:57:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786618636; cv=none; b=abp30f8TK/mwRT8aVw7EKo+uLYbbs7cJWdcQtUs1aPTNzq+38lb1o3KF5sXYsfIkflhtM4kiJoo87fGgfnxjKalrj850IAkYlTRkWjnjlWlusN0/WVToHvJZkl5CvkzCeY+iYJchI8CUPHVkO/RHtJvRqAN4SMvz8pzJNq+bx6s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786618636; c=relaxed/simple; bh=KvwsAYDk+lrfMWGaKagitWYN8fUVhylr5egO46S4+Vk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Qe5/TDAFOiPfO9391olig7gdJ/puUHPmWrkKioK0wpgZzdY7Yf6f1QE63IOnyE6W5g4bQ6+oLesObq7VPb5tmT/Xyt349/2ahSwnDQXN/08KhT5d3oaCW6gXlDjpShYfvMDpVHleBtPltf7ByN+ASVy1exwqT7b8/TtsmEX69XA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=Cch1nbNV; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="Cch1nbNV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1786618625; bh=KvwsAYDk+lrfMWGaKagitWYN8fUVhylr5egO46S4+Vk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Cch1nbNVjxVFVcPMfvI90Q4qrJRDDuwrhdJ4HiR3WPaWls8OqRRcLwyehLKnUGjVk J0A23oPWz6ZhptMhf58NgxgQSfAjJc8uEYclOw4vyDivUZwYxy/FDA4079b97b2y7G sX2JppLWgnzqbf2spEH2mCXuZBkJ/OX/C3qKkOO8DMji9M4hqloEIaO2VqGwHis7U/ MjCmX5lDUj178oFna6ixQQl6RkLWuW7P6yg3Pf5ImdU6lZYvlleC5wvBXrtNq6SScF mrQzgFrRPsB//hY0DswaYIKXiRVF7sY0VH+3357daLIlHyhKLWvK7bDBNiO43rDUjY OTfC9u5J+Qkcw== Received: from fedora-21.home (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id EB49517E0FEA; Thu, 13 Aug 2026 12:57:04 +0200 (CEST) From: Boris Brezillon Date: Thu, 13 Aug 2026 12:57:02 +0200 Subject: [PATCH v3 04/17] drm/panthor: Make sure reset requests in the post reset path are not lost Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260813-panthor-unplug-fixes-v3-4-3ed4e961bbe7@collabora.com> References: <20260813-panthor-unplug-fixes-v3-0-3ed4e961bbe7@collabora.com> In-Reply-To: <20260813-panthor-unplug-fixes-v3-0-3ed4e961bbe7@collabora.com> To: Steven Price , Liviu Dudau Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Boris Brezillon , sashiko-bot@kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1786618621; l=2210; i=boris.brezillon@collabora.com; s=20260429; h=from:subject:message-id; bh=KvwsAYDk+lrfMWGaKagitWYN8fUVhylr5egO46S4+Vk=; b=uCok+ec3UUGlIrXDLejRNputl1IO8+txbtqLKeud/m4cZnjRRq3+ySOjjDTvx2+pN+gUcI84K Umi4ompnJXBAh39MziZimQmdT8GARhtUVLXyyhs1mRLHds+PaF25eru X-Developer-Key: i=boris.brezillon@collabora.com; a=ed25519; pk=eN+ORdOgQY7d5U+0kA8h5bf67XdD8bhKbjD/TCHexSY= In theory, there might be MMU/FW faults happening after the FW has successfully started, and since we clear the reset.pending bit after panthor_fw_post_reset() has returned, there's a short window during which a reset request can be ignored. The other case is a reset condition in other subcomponents that would not prevent the FW to boot, but given what's currently done in the post_reset() helpers, I don't see how this can happen. Anyway, it's probably safer to reset the pending bit just before the SOFT_RESET is issued, so there's absolutely no timeframe during which a reset event can be lost. The risk is an infinite reset loop if the reset condition doesn't prevent the FW to boot, and keeps happening in subsequent resets. Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260804-panthor-unplug-fixes-v1-0-abbbd2d41b13@collabora.com?part=2 Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panthor/panthor_device.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c index 1a8f5ac24399..ffaff8c7088e 100644 --- a/drivers/gpu/drm/panthor/panthor_device.c +++ b/drivers/gpu/drm/panthor/panthor_device.c @@ -156,11 +156,18 @@ static void panthor_device_reset_work(struct work_struct *work) panthor_sched_pre_reset(ptdev); panthor_fw_pre_reset(ptdev, true); panthor_mmu_pre_reset(ptdev); + + /* Reset the pending bit just before the SOFT_RESET to catch any reset + * condition happening in the post reset path. If we're in such a bad + * state we can't even resume the FW, we will bail out and unplug + * anyway, at which point the reset work is disabled, which should + * prevent an infinite reset loop. + */ + atomic_set(&ptdev->reset.pending, 0); panthor_hw_soft_reset(ptdev); panthor_hw_l2_power_on(ptdev); panthor_mmu_post_reset(ptdev); ret = panthor_fw_post_reset(ptdev); - atomic_set(&ptdev->reset.pending, 0); panthor_sched_post_reset(ptdev, ret != 0); drm_dev_exit(cookie); -- 2.55.0