[PATCHv2] dmaengine: at_hdmac: fix sparse '__iomem' cast warning in memset helpers

[PATCHv2] dmaengine: at_hdmac: fix sparse '__iomem' cast warning in memset helpers

[Rosen Penev]

Both atc_prep_dma_memset() and atc_prep_dma_memset_sg() declare vaddr
as 'void __iomem *' but assign the return of dma_pool_alloc(), which
returns 'void *' (not iomem memory). This causes sparse to warn about
a cast removing the __iomem address space at the dereference site.

The struct field memset_vaddr is also typed as 'int *', which is
neither the type returned by dma_pool_alloc() nor the type used for
the actual writes.

Fix by declaring vaddr as 'u32 *' in both functions and changing
memset_vaddr in struct at_desc from 'int *' to 'u32 *'. This matches
the actual usage and eliminates the need for the (u32 *) cast.

Fixes: 5d8c5bea0da9 ("dmaengine: at_hdmac: add COMPILE_TEST support")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202607231110.8MqNRj0Q-lkp@intel.com/
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 v2: remove extra cast
 drivers/dma/at_hdmac.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 7b6aa9bbc3c8..f24e64219fb5 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -244,7 +244,7 @@ struct at_desc {
 	/* Memset temporary buffer */
 	bool				memset_buffer;
 	dma_addr_t			memset_paddr;
-	int				*memset_vaddr;
+	u32				*memset_vaddr;
 	struct atdma_sg			sg[] __counted_by(sglen);
 };
 
@@ -1097,7 +1097,7 @@ atc_prep_dma_memset(struct dma_chan *chan, dma_addr_t dest, int value,
 	struct at_dma_chan	*atchan = to_at_dma_chan(chan);
 	struct at_dma		*atdma = to_at_dma(chan->device);
 	struct at_desc		*desc;
-	void __iomem		*vaddr;
+	u32			*vaddr;
 	dma_addr_t		paddr;
 	char			fill_pattern;
 	int			ret;
@@ -1126,10 +1126,10 @@ atc_prep_dma_memset(struct dma_chan *chan, dma_addr_t dest, int value,
 	/* Only the first byte of value is to be used according to dmaengine */
 	fill_pattern = (char)value;
 
-	*(u32*)vaddr = (fill_pattern << 24) |
-		       (fill_pattern << 16) |
-		       (fill_pattern << 8) |
-		       fill_pattern;
+	*vaddr = (fill_pattern << 24) |
+		 (fill_pattern << 16) |
+		 (fill_pattern << 8) |
+		  fill_pattern;
 
 	desc = kzalloc_flex(*desc, sg, 1, GFP_ATOMIC);
 	if (!desc)
@@ -1168,7 +1168,7 @@ atc_prep_dma_memset_sg(struct dma_chan *chan,
 	struct at_dma		*atdma = to_at_dma(chan->device);
 	struct at_desc		*desc;
 	struct scatterlist	*sg;
-	void __iomem		*vaddr;
+	u32			*vaddr;
 	dma_addr_t		paddr;
 	size_t			total_len = 0;
 	int			i;
@@ -1189,7 +1189,7 @@ atc_prep_dma_memset_sg(struct dma_chan *chan,
 			__func__);
 		return NULL;
 	}
-	*(u32*)vaddr = value;
+	*vaddr = value;
 
 	desc = kzalloc_flex(*desc, sg, sg_len, GFP_ATOMIC);
 	if (!desc)
-- 
2.55.0

Re: [PATCHv2] dmaengine: at_hdmac: fix sparse '__iomem' cast warning in memset helpers

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but atc_prep_dma_memset_sg() fails to broadcast the byte value into a 32-bit pattern, leading to incorrect memory fills.
- [High] This problem wasn't introduced by this patch, but there is a guaranteed kernel oops on error paths of DMA prep functions due to dereferencing an uninitialized vd->tx.chan pointer in atdma_desc_free().
--

--- Patch [1]: [PATCHv2] dmaengine: at_hdmac: fix sparse '__iomem' cast warning in memset helpers ---
commit e39a1989ac7867eaa551256bdc408f22e82b835b
Author: Rosen Penev <rosenp@gmail.com>

dmaengine: at_hdmac: fix sparse '__iomem' cast warning in memset helpers

This patch changes the type of vaddr in memset helpers to avoid sparse
warnings about casting away the __iomem address space. It also updates the
memset_vaddr field in struct at_desc to match the actual usage.

Link: https://lore.kernel.org/oe-kbuild-all/202607231110.8MqNRj0Q-lkp@intel.com/

> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index e5b30a57c477a..7c071e6496371 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c

[ ... ]

> @@ -1189,7 +1189,7 @@ atc_prep_dma_memset_sg(struct dma_chan *chan,
>  			__func__);
>  		return NULL;
>  	}
> -	*(u32*)vaddr = value;
> +	*vaddr = value;

[Severity: High]
This problem wasn't introduced by this patch, but does this correctly format
the fill pattern?

If atc_prep_dma_memset_sg() is called with a non-zero byte value (e.g., 0xAA),
the hardware memset pool buffer is initialized with the unexpanded 32-bit word
(0x000000AA). Because the controller repeatedly copies this 32-bit word to the
destination buffer in 4-byte chunks, the resulting memory is filled with an
incorrect pattern.

In atc_prep_dma_memset(), the value is correctly expanded into a 32-bit
pattern before assignment. Should atc_prep_dma_memset_sg() do the same?

>  
>  	desc = kzalloc_flex(*desc, sg, sg_len, GFP_ATOMIC);
>  	if (!desc)

[Severity: High]
This isn't a bug introduced by this patch, but will the error paths after this
allocation cause a NULL pointer dereference?

If a failure occurs later in this function, such as when checking buffer
alignment, the code jumps to err_free_desc and calls atdma_desc_free().

Since desc was allocated via kzalloc_flex() and vchan_tx_prep() has not yet
initialized the virtual channel structure, vd->tx.chan is NULL.

atdma_desc_free() immediately dereferences it:

atdma_desc_free()
    struct at_dma *atdma = to_at_dma(vd->tx.chan->device);

Could this crash the kernel under memory pressure or when invalid scatterlists
are passed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724225958.43925-1-rosenp@gmail.com?part=1