[PATCH v1 0/2] Fix dma_addr_t for R5 SPL

[PATCH v1 0/2] Fix dma_addr_t for R5 SPL

[Anshul Dalal]

Hi all,

On various TI's K3 platforms boot failure was observed on SPI NOR since the
commit 5609f200d062 ("arm: Kconfig: enable LTO for ARCH_K3"). This issue was
root caused to stack corruption by the 'udma_transfer' function. Where the local
variable 'paddr' of type 'dma_addr_t' was being written to as a 64-bit value
which overwrote the stack frame of the caller (dma_memcpy) as only 32-bits had
been reserved for paddr on the stack, specifically the r4 register in the frame
of dma_memcpy was being overwritten with a 0.

drivers/dma/ti/k3-udma.c:2192:

	int udma_transfer(...)
	{
		...
		dma_addr_t paddr = 0;

		...
		/* paddr was written to as 64-bit value here */
		udma_poll_completion(uc, &paddr);
	}

drivers/dma/dma-uclass.c:234:

	int dma_memcpy(...)
	{
		dma_addr_t destination;
		dma_addr_t source;
		int ret;

		...

		/* This call resolves to udma_transfer */
		ret = ops->transfer(...);

		...

		dma_unmap_single(destination, ...);
		dma_unmap_single(...);
		return ret;
	}

Enabling LTO changed how gcc mapped local variables of dma_memcpy to CPU
registers, where earlier the bug was hidden since the overwritten register
'r4' was allotted to 'ret' but was allotted to 'destination' once LTO was
enabled. And since the overwritten value was 0, the bug remained undetected
as it just meant ret was 0, but having 'destination' set to 0 caused
dma_unmap_single to fail silently leading to boot failures.

The fix entails enabling DMA_ADDR_T_64BIT which changes dma_addr_t from u32 to
u64 for the R5 SPL thus reserving enough space for 'paddr' to prevent the
overflow.

Regards,
Anshul
---
Anshul Dalal (2):
  dma: ti: k3-udma: fix dma_addr_t typecasts
  config: arch: k3: enable DMA_ADDR_T_64BIT

 arch/arm/Kconfig         | 1 +
 drivers/dma/ti/k3-udma.c | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

-- 
2.50.1

[PATCH v1 1/2] dma: ti: k3-udma: fix dma_addr_t typecasts

[Anshul Dalal]

With the change to dma_addr_t from u32 to u64 for the R5 SPL, the
existing typecasts from void* to int or vice-versa cause the compiler to
throw a "cast from pointer to integer of different size".

Therefore this patch changes the casts to a uintptr_t which is
guaranteed to hold any pointer value, thus supressing the compiler
warning.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 drivers/dma/ti/k3-udma.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 723265ab2e5..01824310995 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -2327,7 +2327,7 @@ static int udma_send(struct dma *dma, void *src, size_t len, void *metadata)
 {
 	struct udma_dev *ud = dev_get_priv(dma->dev);
 	struct cppi5_host_desc_t *desc_tx;
-	dma_addr_t dma_src = (dma_addr_t)src;
+	dma_addr_t dma_src = (uintptr_t)src;
 	struct ti_udma_drv_packet_data packet_data = { 0 };
 	dma_addr_t paddr;
 	struct udma_chan *uc;
@@ -2426,7 +2426,7 @@ static int udma_receive(struct dma *dma, void **dst, void *metadata)
 
 	cppi5_desc_get_tags_ids(&desc_rx->hdr, &port_id, NULL);
 
-	*dst = (void *)buf_dma;
+	*dst = (void *)(uintptr_t)buf_dma;
 	uc->num_rx_bufs--;
 
 	return pkt_len;
@@ -2518,7 +2518,7 @@ int udma_prepare_rcv_buf(struct dma *dma, void *dst, size_t size)
 
 	desc_num = uc->desc_rx_cur % UDMA_RX_DESC_NUM;
 	desc_rx = uc->desc_rx + (desc_num * uc->config.hdesc_size);
-	dma_dst = (dma_addr_t)dst;
+	dma_dst = (uintptr_t)dst;
 
 	cppi5_hdesc_reset_hbdesc(desc_rx);
 
-- 
2.50.1

[PATCH v1 2/2] config: arch: k3: enable DMA_ADDR_T_64BIT

[Anshul Dalal]

ARCH_K3 encompasses both 32 and 64-bit cores on the same SoC, though the
DMA addresses are always 64-bit in size.

With the current implementation, the R5 SPL uses a u32 for dma_addr_t
which leads to data overflow when functions such as k3_nav_*_pop_mem try
to write a 64-bit address to dma_addr_t variable.

In certain cases it leads to stack corruption which manifest as boot
failures on certain compilers, such as SPI boot on GCC 14.2 or 13.3.

Therefore this patch selects CONFIG_DMA_ADDR_T_64BIT for all ARCH_K3.

Fixes: ffcc66e8fec5 ("dma: ti: add driver to K3 UDMA")
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 40368abc297..16db046f4b8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -833,6 +833,7 @@ config ARCH_K3
 	select FIT
 	select REGEX
 	select FIT_SIGNATURE if ARM64
+	select DMA_ADDR_T_64BIT
 	select LTO
 	imply TI_SECURE_DEVICE
 	imply DM_RNG if ARM64
-- 
2.50.1

Re: [PATCH v1 1/2] dma: ti: k3-udma: fix dma_addr_t typecasts

[Prasanth Mantena]

Hi Anshul,
On 19:02, Anshul Dalal wrote:
> With the change to dma_addr_t from u32 to u64 for the R5 SPL, the

From above line, Does this patch meant to after patch 2/2 ?

> existing typecasts from void* to int or vice-versa cause the compiler to
> throw a "cast from pointer to integer of different size".
> 
> Therefore this patch changes the casts to a uintptr_t which is
> guaranteed to hold any pointer value, thus supressing the compiler
> warning.
> 
> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> ---
>  drivers/dma/ti/k3-udma.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index 723265ab2e5..01824310995 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c
> @@ -2327,7 +2327,7 @@ static int udma_send(struct dma *dma, void *src, size_t len, void *metadata)
>  {
>  	struct udma_dev *ud = dev_get_priv(dma->dev);
>  	struct cppi5_host_desc_t *desc_tx;
> -	dma_addr_t dma_src = (dma_addr_t)src;
> +	dma_addr_t dma_src = (uintptr_t)src;

Considering after the dma_addr_t changed to u64, please help me understand what
warning does the above change fix.

Thanks,
Prasanth

>  	struct ti_udma_drv_packet_data packet_data = { 0 };
>  	dma_addr_t paddr;
>  	struct udma_chan *uc;
> @@ -2426,7 +2426,7 @@ static int udma_receive(struct dma *dma, void **dst, void *metadata)
>  
>  	cppi5_desc_get_tags_ids(&desc_rx->hdr, &port_id, NULL);
>  
> -	*dst = (void *)buf_dma;
> +	*dst = (void *)(uintptr_t)buf_dma;
>  	uc->num_rx_bufs--;
>  
>  	return pkt_len;
> @@ -2518,7 +2518,7 @@ int udma_prepare_rcv_buf(struct dma *dma, void *dst, size_t size)
>  
>  	desc_num = uc->desc_rx_cur % UDMA_RX_DESC_NUM;
>  	desc_rx = uc->desc_rx + (desc_num * uc->config.hdesc_size);
> -	dma_dst = (dma_addr_t)dst;
> +	dma_dst = (uintptr_t)dst;
>  
>  	cppi5_hdesc_reset_hbdesc(desc_rx);
>  
> -- 
> 2.50.1
> 

Re: [PATCH v1 1/2] dma: ti: k3-udma: fix dma_addr_t typecasts

[Anshul Dalal]

Hi Prasanth,

On Wed Aug 27, 2025 at 9:44 PM IST, Prasanth Mantena wrote:
> Hi Anshul,
> On 19:02, Anshul Dalal wrote:
>> With the change to dma_addr_t from u32 to u64 for the R5 SPL, the
>
> From above line, Does this patch meant to after patch 2/2 ?
>
>> existing typecasts from void* to int or vice-versa cause the compiler to
>> throw a "cast from pointer to integer of different size".
>> 
>> Therefore this patch changes the casts to a uintptr_t which is
>> guaranteed to hold any pointer value, thus supressing the compiler
>> warning.
>> 
>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> ---
>>  drivers/dma/ti/k3-udma.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
>> index 723265ab2e5..01824310995 100644
>> --- a/drivers/dma/ti/k3-udma.c
>> +++ b/drivers/dma/ti/k3-udma.c
>> @@ -2327,7 +2327,7 @@ static int udma_send(struct dma *dma, void *src, size_t len, void *metadata)
>>  {
>>  	struct udma_dev *ud = dev_get_priv(dma->dev);
>>  	struct cppi5_host_desc_t *desc_tx;
>> -	dma_addr_t dma_src = (dma_addr_t)src;
>> +	dma_addr_t dma_src = (uintptr_t)src;
>
> Considering after the dma_addr_t changed to u64, please help me understand what
> warning does the above change fix.
>

This patch was meant to prevent warnings from the last patch of the
series, though I understand the confusion here. I will reword the commit
description to be more clear in v2.

Thanks,
Anshul

Re: [PATCH v1 1/2] dma: ti: k3-udma: fix dma_addr_t typecasts

[Anshul Dalal]

On Thu Aug 28, 2025 at 10:31 AM IST, Anshul Dalal wrote:
> Hi Prasanth,
>
> On Wed Aug 27, 2025 at 9:44 PM IST, Prasanth Mantena wrote:
>> Hi Anshul,
>> On 19:02, Anshul Dalal wrote:
>>> With the change to dma_addr_t from u32 to u64 for the R5 SPL, the
>>
>> From above line, Does this patch meant to after patch 2/2 ?
>>
>>> existing typecasts from void* to int or vice-versa cause the compiler to
>>> throw a "cast from pointer to integer of different size".
>>> 
>>> Therefore this patch changes the casts to a uintptr_t which is
>>> guaranteed to hold any pointer value, thus supressing the compiler
>>> warning.
>>> 
>>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>>> ---
>>>  drivers/dma/ti/k3-udma.c | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
>>> index 723265ab2e5..01824310995 100644
>>> --- a/drivers/dma/ti/k3-udma.c
>>> +++ b/drivers/dma/ti/k3-udma.c
>>> @@ -2327,7 +2327,7 @@ static int udma_send(struct dma *dma, void *src, size_t len, void *metadata)
>>>  {
>>>  	struct udma_dev *ud = dev_get_priv(dma->dev);
>>>  	struct cppi5_host_desc_t *desc_tx;
>>> -	dma_addr_t dma_src = (dma_addr_t)src;
>>> +	dma_addr_t dma_src = (uintptr_t)src;
>>
>> Considering after the dma_addr_t changed to u64, please help me understand what
>> warning does the above change fix.
>>
>
> This patch was meant to prevent warnings from the last patch of the
> series, though I understand the confusion here. I will reword the commit
> description to be more clear in v2.
>

To give further context:

The fix would ideally be to use dma_addr_t for all dma-uclass
APIs similar to how the linux kernel handles it. Though given what we
have (using void* instead), a direct typecast to dma_addr_t with the
second patch would essentially amount to casting a 32-bit pointer to u64
hence the warning "cast from pointer to integer of different size".

uintptr_t is u32 for the R5 SPL so the 32-bit pointer is casted to a u32
first and then to dma_addr_t which is u64. Thus keeping the compiler
happy :)

And since K3's R5 SPL is the only case where dma_addr_t isn't the same
size as void* but with the dma addresses guaranteed to fit in a 32-bit
address space, I think a few typecasts are the easier solution than
refactoring the dma APIs to use dma_addr_t.

Regards,
Anshul

Re: [PATCH v1 1/2] dma: ti: k3-udma: fix dma_addr_t typecasts

[Kumar, Udit]

On 8/25/2025 7:02 PM, Anshul Dalal wrote:
> With the change to dma_addr_t from u32 to u64 for the R5 SPL, the
> existing typecasts from void* to int or vice-versa cause the compiler to
> throw a "cast from pointer to integer of different size".

is this some compiler specific ?. Please mention that

I don't see this warning 
https://gist.github.com/uditkumarti/1c4238a7101d97cdc57b7a40d10147d2

I am on  gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1)


> Therefore this patch changes the casts to a uintptr_t which is
> guaranteed to hold any pointer value, thus supressing the compiler
> warning.
>
> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> ---
>   drivers/dma/ti/k3-udma.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index 723265ab2e5..01824310995 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c
> @@ -2327,7 +2327,7 @@ static int udma_send(struct dma *dma, void *src, size_t len, void *metadata)
>   {
>   	struct udma_dev *ud = dev_get_priv(dma->dev);
>   	struct cppi5_host_desc_t *desc_tx;
> -	dma_addr_t dma_src = (dma_addr_t)src;
> +	dma_addr_t dma_src = (uintptr_t)src;
>   	struct ti_udma_drv_packet_data packet_data = { 0 };
>   	dma_addr_t paddr;
>   	struct udma_chan *uc;
> @@ -2426,7 +2426,7 @@ static int udma_receive(struct dma *dma, void **dst, void *metadata)
>   
>   	cppi5_desc_get_tags_ids(&desc_rx->hdr, &port_id, NULL);
>   
> -	*dst = (void *)buf_dma;
> +	*dst = (void *)(uintptr_t)buf_dma;
>   	uc->num_rx_bufs--;
>   
>   	return pkt_len;
> @@ -2518,7 +2518,7 @@ int udma_prepare_rcv_buf(struct dma *dma, void *dst, size_t size)
>   
>   	desc_num = uc->desc_rx_cur % UDMA_RX_DESC_NUM;
>   	desc_rx = uc->desc_rx + (desc_num * uc->config.hdesc_size);
> -	dma_dst = (dma_addr_t)dst;
> +	dma_dst = (uintptr_t)dst;
>   
>   	cppi5_hdesc_reset_hbdesc(desc_rx);
>   

Re: [PATCH v1 1/2] dma: ti: k3-udma: fix dma_addr_t typecasts

[Anshul Dalal]

On Thu Aug 28, 2025 at 2:20 PM IST, Udit Kumar wrote:
>
> On 8/25/2025 7:02 PM, Anshul Dalal wrote:
>> With the change to dma_addr_t from u32 to u64 for the R5 SPL, the
>> existing typecasts from void* to int or vice-versa cause the compiler to
>> throw a "cast from pointer to integer of different size".
>
> is this some compiler specific ?. Please mention that
>
> I don't see this warning 
> https://gist.github.com/uditkumarti/1c4238a7101d97cdc57b7a40d10147d2
>
> I am on  gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1)
>

Sorry for the confusing language in the commit description, this was a
preventative fix, it fixes the warnings that would've been emitted if
you had applied the second patch of the series by itself.

GCC 11 would still emit the warning if you apply only the second patch.

Regards,
Anshul