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 <ansh...@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
