On Mon, 2017-03-20 at 13:23 +0100, Arnd Bergmann wrote: > On Mon, Mar 20, 2017 at 3:44 AM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > > Hi all, > > > > After merging the char-misc tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_mmap': > > drivers/misc/aspeed-lpc-ctrl.c:51:9: error: implicit declaration of function 'pgprot_dmacoherent' [-Werror=implicit-function-declaration] > > prot = pgprot_dmacoherent(prot); > > A lot of other drivers (including /dev/mem) just use pgprot_noncached() or > pgprot_writecombine(), which would make the code portable and might be > what you want here as well. > > pgprot_dmacoherent() is meant specifically for mapping RAM that is used > for DMA buffers that come from dma_alloc_coherent(), which doesn't seem > to be the case here. > > What kind of address range is this really? It's a piece of RAM that we reserve via a reserved region, which will be accessed by HW (sort-of-DMA, ie, the "host" system will access that using FW cycles on the LPC bus which we map to that reserved region of memory). Joel, Cyril, can you send a 1-liner patch to change that to pgprot_noncached() ? Cheers, Ben. > > drivers/misc/aspeed-lpc-ctrl.c:51:7: error: incompatible types when assigning to type 'pgprot_t {aka struct pgprot}' from type 'int' > > prot = pgprot_dmacoherent(prot); > > ^ > > In file included from include/linux/miscdevice.h:6:0, > > from drivers/misc/aspeed-lpc-ctrl.c:11: > > drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe': > > drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'phys_addr_t {aka long long unsigned int}' [-Wformat=] > > dev_info(dev, "Loaded at 0x%08x (0x%08x)\n", > > This should just use the "%pap" for printing a phys_addr_t, otherwise we > get the same warning on ARM in some configurations. > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html