mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-21 21:11:47 +07:00
cc0336ec8a
The knav_qmss driver is currently broken when CONFIG_LPAE is set, which is a bit surprising because I'd expect that any serious users of this platforms would have more than 2GB of RAM and require LPAE. The compiler clearly warns about an incorrect use of dma_addr_t in the debug kernel messages: ti/knav_qmss_queue.c: In function 'knav_queue_setup_region': ti/knav_qmss_queue.c:1025:117: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=] ti/knav_qmss_queue.c:1025:117: warning: format '%x' expects argument of type 'unsigned int', but argument 10 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=] ti/knav_qmss_queue.c: In function 'knav_queue_setup_link_ram': ti/knav_qmss_queue.c:1175:118: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=] This patch changes all the debugging output to use the correct %pad format string that works with both 32-bit and 64-bit dma_addr_t. As the variable naming is somewhat confusing here, I also change all *_phys names to *_dma when they refer to bus addresses that are used for DMA rather than a physical memory address as seen from the CPU. This is particularly important on keystone, because the two things are not the same there. Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
---|---|---|
.. | ||
Kconfig | ||
knav_dma.c | ||
knav_qmss_acc.c | ||
knav_qmss_queue.c | ||
knav_qmss.h | ||
Makefile | ||
wkup_m3_ipc.c |