Correct handling of the dma_request_chan call in order to avoid
misleading warn message if no DMA is provided within the device-tree
and moreover fail if dma_request_chan has returned a valid error.

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
---
 drivers/spi/spi-stm32.c | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
index 353ea5b93e0a..8f8968383ad0 100644
--- a/drivers/spi/spi-stm32.c
+++ b/drivers/spi/spi-stm32.c
@@ -2484,11 +2484,13 @@ static int stm32_spi_probe(struct platform_device *pdev)
 	spi->dma_tx = dma_request_chan(spi->dev, "tx");
 	if (IS_ERR(spi->dma_tx)) {
 		ret = PTR_ERR(spi->dma_tx);
-		spi->dma_tx = NULL;
-		if (ret == -EPROBE_DEFER)
+		if (ret == -ENODEV) {
+			dev_info(&pdev->dev, "tx dma disabled\n");
+			spi->dma_tx = NULL;
+		} else {
+			dev_err_probe(&pdev->dev, ret, "failed to request tx dma channel\n");
 			goto err_clk_disable;
-
-		dev_warn(&pdev->dev, "failed to request tx dma channel\n");
+		}
 	} else {
 		ctrl->dma_tx = spi->dma_tx;
 	}
@@ -2496,11 +2498,13 @@ static int stm32_spi_probe(struct platform_device *pdev)
 	spi->dma_rx = dma_request_chan(spi->dev, "rx");
 	if (IS_ERR(spi->dma_rx)) {
 		ret = PTR_ERR(spi->dma_rx);
-		spi->dma_rx = NULL;
-		if (ret == -EPROBE_DEFER)
+		if (ret == -ENODEV) {
+			dev_info(&pdev->dev, "rx dma disabled\n");
+			spi->dma_rx = NULL;
+		} else {
+			dev_err_probe(&pdev->dev, ret, "failed to request rx dma channel\n");
 			goto err_dma_release;
-
-		dev_warn(&pdev->dev, "failed to request rx dma channel\n");
+		}
 	} else {
 		ctrl->dma_rx = spi->dma_rx;
 	}

-- 
2.34.1

On Wed, Dec 17, 2025 at 10:51:33PM +0100, Alain Volmat wrote:
> Correct handling of the dma_request_chan call in order to avoid
> misleading warn message if no DMA is provided within the device-tree
> and moreover fail if dma_request_chan has returned a valid error.

Bug fixes should go at the start of serieses to avoid spurious
dependencies on new or cleanup changes.

Hi Mark,

On Thu, Dec 18, 2025 at 08:00:57AM +0000, Mark Brown wrote:
> On Wed, Dec 17, 2025 at 10:51:33PM +0100, Alain Volmat wrote:
> > Correct handling of the dma_request_chan call in order to avoid
> > misleading warn message if no DMA is provided within the device-tree
> > and moreover fail if dma_request_chan has returned a valid error.
> 
> Bug fixes should go at the start of serieses to avoid spurious
> dependencies on new or cleanup changes.

Actually I wasn't thinking about requiring this commit to go into
stable branches. Without commit, the driver will still work even if
there is an issue to request a dma channel since it will fallback to
interrupt based transfers.
This commit makes the error visible now, ensuring that if the
device-tree indicates that a DMA should be used, it will either be used
or probe will fail.

Alain

On Thu, Dec 18, 2025 at 09:38:40AM +0100, Alain Volmat wrote:
> On Thu, Dec 18, 2025 at 08:00:57AM +0000, Mark Brown wrote:

> > Bug fixes should go at the start of serieses to avoid spurious
> > dependencies on new or cleanup changes.

> Actually I wasn't thinking about requiring this commit to go into
> stable branches. Without commit, the driver will still work even if
> there is an issue to request a dma channel since it will fallback to
> interrupt based transfers.
> This commit makes the error visible now, ensuring that if the
> device-tree indicates that a DMA should be used, it will either be used
> or probe will fail.

I'd not send it to stable either (admittedly I generally stopped tagging
stuff for stable entirely) but I will apply it for v6.19.

On Thu, Dec 18, 2025 at 08:57:36AM +0000, Mark Brown wrote:
> On Thu, Dec 18, 2025 at 09:38:40AM +0100, Alain Volmat wrote:
> > On Thu, Dec 18, 2025 at 08:00:57AM +0000, Mark Brown wrote:
> 
> > > Bug fixes should go at the start of serieses to avoid spurious
> > > dependencies on new or cleanup changes.
> 
> > Actually I wasn't thinking about requiring this commit to go into
> > stable branches. Without commit, the driver will still work even if
> > there is an issue to request a dma channel since it will fallback to
> > interrupt based transfers.
> > This commit makes the error visible now, ensuring that if the
> > device-tree indicates that a DMA should be used, it will either be used
> > or probe will fail.
> 
> I'd not send it to stable either (admittedly I generally stopped tagging
> stuff for stable entirely) but I will apply it for v6.19.

Alright. Thanks. Let me send a v2, putting this patch in front of the
serie.