Make sure to deregister the controller before freeing underlying
resources like DMA channels during driver unbind.

Fixes: 64e36824b32b ("spi/rockchip: add driver for Rockchip RK3xxx SoCs integrated SPI")
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/spi/spi-rockchip.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index fd2ebef4903f..eb1992b4178e 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -908,7 +908,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
 		break;
 	}
 
-	ret = devm_spi_register_controller(&pdev->dev, ctlr);
+	ret = spi_register_controller(ctlr);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Failed to register controller\n");
 		goto err_free_dma_rx;
@@ -936,6 +936,8 @@ static void rockchip_spi_remove(struct platform_device *pdev)
 
 	pm_runtime_get_sync(&pdev->dev);
 
+	spi_unregister_controller(ctlr);
+
 	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
-- 
2.52.0

On Mon, Mar 23, 2026 at 11:49:47AM +0100, Johan Hovold wrote:
> Make sure to deregister the controller before freeing underlying
> resources like DMA channels during driver unbind.

Fixes should go before any non-fix patches in the series to avoid
spurious dependencies and make it easier to manage applying the series.

On Mon, Mar 23, 2026 at 04:35:39PM +0000, Mark Brown wrote:
> On Mon, Mar 23, 2026 at 11:49:47AM +0100, Johan Hovold wrote:
> > Make sure to deregister the controller before freeing underlying
> > resources like DMA channels during driver unbind.
> 
> Fixes should go before any non-fix patches in the series to avoid
> spurious dependencies and make it easier to manage applying the series.

Sure, but here there are no inter-driver dependencies (that is, the sets
of patches for each driver respectively are independent).

And I didn't expect this one to go into 7.0-rc (no stable tag).

Do you want me to resend a reordered series?

Johan

On Mon, Mar 23, 2026 at 05:51:20PM +0100, Johan Hovold wrote:
> On Mon, Mar 23, 2026 at 04:35:39PM +0000, Mark Brown wrote:

> > Fixes should go before any non-fix patches in the series to avoid
> > spurious dependencies and make it easier to manage applying the series.

> Sure, but here there are no inter-driver dependencies (that is, the sets
> of patches for each driver respectively are independent).

If you're treating the patches as independent then send a series per
driver.

> And I didn't expect this one to go into 7.0-rc (no stable tag).

Why wouldn't we apply bug fixes as bug fixes?

> Do you want me to resend a reordered series?

Please.

On Mon, Mar 23, 2026 at 05:02:49PM +0000, Mark Brown wrote:
> On Mon, Mar 23, 2026 at 05:51:20PM +0100, Johan Hovold wrote:
> > On Mon, Mar 23, 2026 at 04:35:39PM +0000, Mark Brown wrote:
> 
> > > Fixes should go before any non-fix patches in the series to avoid
> > > spurious dependencies and make it easier to manage applying the series.
> 
> > Sure, but here there are no inter-driver dependencies (that is, the sets
> > of patches for each driver respectively are independent).
> 
> If you're treating the patches as independent then send a series per
> driver.

I sent these as a series as the changes are related, but sure, it is
possible to split it in three series as well.

> > And I didn't expect this one to go into 7.0-rc (no stable tag).
> 
> Why wouldn't we apply bug fixes as bug fixes?

Not all bug fixes meet the stable backport criteria, and late in the
release cycle we tend to defer non-critical fixes to the next cycle.

This one is border line, but I'll include a stable tag when respinning.
 
> > Do you want me to resend a reordered series?
> 
> Please.

Will do.

Johan