2017-03-20 02:44:42

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: build failure after merge of the char-misc tree

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);
^
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",
^
include/linux/device.h:1317:51: note: in definition of macro 'dev_info'
#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
^
drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
dev_info(dev, "Loaded at 0x%08x (0x%08x)\n",
^
include/linux/device.h:1317:51: note: in definition of macro 'dev_info'
#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
^

Caused by commit

6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver")

Clearly this will only build on arm :-( You can only use COMPILE_TEST
if you can reasonably expect the build to work on all architectures
and platforms.

I have added the following patch for today (the warnings should be fixed as well):

From: Stephen Rothwell <[email protected]>
Date: Mon, 20 Mar 2017 13:38:10 +1100
Subject: [PATCH] drivers/misc: Aspeed LPC control driver will only build on arm

Signed-off-by: Stephen Rothwell <[email protected]>
---
drivers/misc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index fb933b0b9297..52a46b129214 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -773,7 +773,7 @@ config PANEL_BOOT_MESSAGE
endif # PANEL

config ASPEED_LPC_CTRL
- depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
+ depends on ARCH_ASPEED && REGMAP && MFD_SYSCON
tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
---help---
Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
--
2.11.0

--
Cheers,
Stephen Rothwell


2017-03-20 12:24:25

by Arnd Bergmann

[permalink] [raw]
Subject: Re: linux-next: build failure after merge of the char-misc tree

On Mon, Mar 20, 2017 at 3:44 AM, Stephen Rothwell <[email protected]> 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?

> 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

2017-03-21 00:18:34

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: linux-next: build failure after merge of the char-misc tree

On Mon, 2017-03-20 at 13:23 +0100, Arnd Bergmann wrote:
> On Mon, Mar 20, 2017 at 3:44 AM, Stephen Rothwell <[email protected]> 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

2017-03-21 00:38:10

by Cyril Bur

[permalink] [raw]
Subject: Re: linux-next: build failure after merge of the char-misc tree

On Tue, 2017-03-21 at 11:18 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2017-03-20 at 13:23 +0100, Arnd Bergmann wrote:
> > On Mon, Mar 20, 2017 at 3:44 AM, Stephen Rothwell <[email protected]> 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() ?
>

Sure. Just to be clear - we want to keep COMPILE_TEST in kconfig?

Also I can't help but notice this: 
https://lists.ozlabs.org/pipermail/openbmc/2017-January/006219.html
[v3 of the series]
vs
https://lists.ozlabs.org/pipermail/openbmc/2017-February/006462.html
[v4 of the series]


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

Thanks Arnd, I'll address that too.

> >
> >       Arnd

2017-03-21 03:00:53

by Joel Stanley

[permalink] [raw]
Subject: Re: linux-next: build failure after merge of the char-misc tree

On Tue, Mar 21, 2017 at 11:06 AM, Cyril Bur <[email protected]> wrote:
> On Tue, 2017-03-21 at 11:18 +1100, Benjamin Herrenschmidt wrote:
>> On Mon, 2017-03-20 at 13:23 +0100, Arnd Bergmann wrote:
>> > On Mon, Mar 20, 2017 at 3:44 AM, Stephen Rothwell <[email protected]> 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() ?
>>
>
> Sure. Just to be clear - we want to keep COMPILE_TEST in kconfig?

Yep. With the change that Ben suggested we should be ok.

pgprot_noncached has a fall back definition in
include/asm-generic/pgtable.h, so all platforms will compile.

Cheers,

Joel