From: Takashi Iwai <tiwai@xxxxxxx>
Date: Fri, 25 Nov 2016 10:30:48 +0100
> On Thu, 24 Nov 2016 21:35:16 +0100,
> Tushar Dave wrote:
>>
>> dbri uses 'u32' for dma handle while invoking kernel DMA APIs,
>> instead of using dma_addr_t. This hasn't caused any 'incompatible
>> pointer type' warning on SPARC because until now dma_addr_t is of
>> type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit
>> DMA and therefore dma_addr_t became of type u64. This makes
>> 'incompatible pointer type' warnings inevitable.
>>
>> e.g.
>> sound/sparc/dbri.c: In function ʽsnd_dbri_createʼ:
>> sound/sparc/dbri.c:2538: warning: passing argument 3 of ʽdma_zalloc_coherentʼ from incompatible pointer type
>> ./include/linux/dma-mapping.h:608: note: expected ʽdma_addr_t *ʼ but argument is of type ʽu32 *ʼ
>>
>> For the record, dbri(sbus) driver never executes on sun4v. Therefore
>> even though 64bit DMA is enabled on SPARC, dbri continues to use
>> legacy iommu that guarantees DMA address is always in 32bit range.
>>
>> This patch resolves above compiler warning.
>>
>> Signed-off-by: Tushar Dave <tushar.n.dave@xxxxxxxxxx>
>> Reviewed-by: thomas tai <thomas.tai@xxxxxxxxxx>
>> ---
>> v2->v3:
>> - Use %pad to print dma_addr_t. Comment by Takashi Iwai.
>
> Applied now. Thanks!
This patch is absolutely not appropriate for your tree Takashi.
It's for the sparc tree because that's where the dma_addr_t
type was changed from 32-bit to 64-bit on sparc64, which is
what caused this build warning.
Dave, please only send sparc specific driver patches to
sparclinux@xxxxxxxxxxxxxxx in the future so we can avoid
this kind of problem. The whole handling of the dma_addr_t
type change on sparc64 has been a real mess, quite honestly.
?τθΊ{.nΗ+?·????+%?Λ?±ιέΆ??w?Ί{.nΗ+?·¬??ά?)ξΗψ§Ά?ʽά¨}©?²Ζ zΪ&j:+v?¨ώψ ―ω ?w?ώ?ΰ2?ή?¨θΪ&ʼ)ίʽ«aΆΪ??ϋΰzΏδzΉή?ϊ+?ω???έʼj??wθώf
