[alsa-devel] [PATCH v3] dbri: Fix compiler warning

David Miller davem at davemloft.net
Fri Nov 25 18:03:10 CET 2016


From: Takashi Iwai <tiwai at suse.de>
Date: Fri, 25 Nov 2016 17:58:21 +0100

> On Fri, 25 Nov 2016 17:54:47 +0100,
> David Miller wrote:
>> 
>> From: Takashi Iwai <tiwai at suse.de>
>> 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 at oracle.com>
>> >> Reviewed-by: thomas tai <thomas.tai at oracle.com>
>> >> ---
>> >> 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 at vger.kernel.org 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.
> 
> Fair enough.  Could you take it through your tree?
> Feel free to take my ack:
>   Reviewed-by: Takashi Iwai <tiwai at suse.de>

I will, thank you.


More information about the Alsa-devel mailing list