From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6110B606A32D for ; Fri, 13 Nov 2026 13:51:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=VGHxNI47; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.a=rsa-sha256 header.s=gloria202408 header.b=gCRVbUCl DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Unsubscribe-Post:List-Owner; bh=ajfkqwM/Rgd/hmTjFJVgmLiAvDSBq9sv3hvrZF5U8+A=; b=VGHxNI47B5Gq9TnZmvIJiMP31O XkrK0CMSEmXXZ7RpAvw3jIEjHsq6XQAiJs/Z0LXZiFcvJrpQvKjcfk4jZEned8C/T35dfvfcX2/7K V3GfSuJQlSLe3IHE1L9Q58n3Ozb3KJrG4pkdDZB1HHM+FeEQ2QXvzybHIO0XHGa5xQuLWJg/J4bNy QqxRYpXDFnGNDn8Sx+qZKAATxvkUKjY7albuiMjr8ty0ZcD/z0WxWtD+VZ73+eWClblQXzuqzZ0tW C8OID8+3+zYFFV5Pg07jsD9GBnEsjtJNVB485+hpcsN9cZ5YSFfyoiTzYAPMY1JP2zKP5VDtyCrCx D5hc/jFA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xRrgB-0000000D1ur-0g4Y; Fri, 13 Nov 2026 13:50:59 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xRrfh-0000000D1Ux-2T9o; Fri, 13 Nov 2026 13:50:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Transfer-Encoding:MIME-Version:Message-ID:Date: Subject:Cc:To:From:Reply-To:Content-Type:In-Reply-To:References; bh=ajfkqwM/Rgd/hmTjFJVgmLiAvDSBq9sv3hvrZF5U8+A=; b=gCRVbUClz1vii5qByspiO5SU5p d2rkzTYkogGYm5xmDBms6rjXaDrHmbMz8JPxbQa3ibbjn7HhkSFbipmP1wseO0aDg/auwJ+vy3zVT U/yDf8SSBaasUM+baNbIS1eMhM+B2AxsrXtcOsrqSUdK1i9JOPid95qIvex0BJA40ZVlN8jOy08wI ThfVYgK3Wgj989vjtlItq+vqI74GPGObiVpDmhSEPjIm55vkSb81rW8ZOpeBe8dGDz/uIHUb5J1rD aXbBtyV8McsFU7H5gJIjjuw1oI7nDX0mMojyrnpJ+krSqHQNQyWxIaEOMRHb+/JMKVrIh06HEdtbL AzexC66w==; From: Heiko Stuebner To: broonie@kernel.org Cc: Heiko Stuebner , linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, quentin.schulz@cherry.de, Lee Jones , Sebastian Reichel Subject: [PATCH v2 0/6] spi: Implement a atomic transfer as a last resort Date: Fri, 13 Nov 2026 14:50:11 +0100 Message-ID: <20261113135017.1047959-1-heiko@sntech.de> X-Mailer: git-send-email 2.53.0 X-Archived-By: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20261113_055029_647021_50741BD8 X-CRM114-Status: GOOD ( 20.41 ) X-Spam-Score: -2.1 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-13.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 SPI devices at times are used as PMICs including a power-controller functionality that should turn off a system. This happens in an atomic context very late during the shutdown, where no interrupts are available anymore and conflicts with the asynchronous nature of the SPI subsystem. ====== History ====== For the RK806 spi-connected PMIC this has already caused interesting artifacts. A first change, tried to "fix" the issue by using the SYS_OFF_MODE_POWER_OFF_PREPARE step of poweroff. While this hides the issue, on some devices this now turns the pmic off too early before other important steps are done. To mitigate that issue for "some" devices, a change [0] tried to use different poweroff phases for i2c and spi devices, where Lee rightfully said, that with this no proper solution would be done - and Lee was right, as that issue now is open since 2024. The newest change is a simple revert back the old way [1] because of those issues caused on other devices, but that now breaks the SPI side again and also did not take into account that long history. ====== Now ======= The I2C framework has an atomic transfer callback for exactly this late stage transfers since commit 63b96983a5dd ("i2c: core: introduce callbacks for atomic transfers") and during the discussion it was suggested implementing something like this for SPI too. As this did not seem to have happened yet, I thought I'd try my luck. Similar to I2C this is meant only for that latest stage so I stole the gating from there too. I assume I did not take some SPI specifics into account, but I guess having some code to discuss is a starting point at least :-) ===== Testing ===== Adding the below diff allows the atomic transfer to also work as main transfer function for testing purposes. As SPI's ->transfer() call already lives inside a spinlock_irqsafe context, this allows to find any sleeping elements easily. @@ -953,6 +953,9 @@ /* Only register atomic transfer in host-mode */ if (!target_mode) { + pm_runtime_resume_and_get(rs->dev); + ctlr->transfer = rockchip_spi_transfer_atomic; + ctlr->transfer_atomic = rockchip_spi_transfer_atomic; ret = devm_register_sys_off_handler(&pdev->dev, ===== New ===== changes in v2: address review comments from Mark Brown - core: preserve old behaviour for drivers not declaring an atomic transfer function - core: don't use message optimization - safer, but still validate the message to get bits_per_word defaults etc - core: make spi_delay_exec usable from atomic contexts - rockchip: only register atomic transfer in host-mode - rockchip: provide a wait_for_idle_atomic function, to not require (non-working) jiffies for timeout - rockchip: register additional restart handler to enable runtime pm before reboots too - rockchip: drop runtime-pm from atomic transfer - would sleep anyway - rockchip: don't prevent power_off, if runtime-resume fails - rockchip: use core spi's spi_set_cs to also handle gpio-cs [0] https://lore.kernel.org/lkml/20240730180903.81688-1-sebastian.reichel@collabora.com/ [1] https://lore.kernel.org/all/20260908-veyron-shutdown-v1-1-066ecb80f5f2@gmail.com/ Cc: Heiko Stuebner Cc: linux-spi@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: quentin.schulz@cherry.de Cc: Lee Jones Cc: Sebastian Reichel Heiko Stuebner (6): spi: Allow spi_delay_exec() to be used from atomic contexts spi: Export spi_set_cs() function spi: Add infrastructure for atomic sync transfers spi: rockchip: Fix runtime resume error handling spi: rockchip: Move to pm_runtime_resume_and_get spi: rockchip: Add an atomic transfer function drivers/spi/spi-rockchip.c | 126 +++++++++++++++++++++++++++++++++++-- drivers/spi/spi.c | 77 ++++++++++++++++++++--- include/linux/spi/spi.h | 13 ++++ 3 files changed, 204 insertions(+), 12 deletions(-) -- 2.53.0