Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756143AbdCUDAx (ORCPT ); Mon, 20 Mar 2017 23:00:53 -0400 Received: from mail-yw0-f195.google.com ([209.85.161.195]:36117 "EHLO mail-yw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755307AbdCUDAv (ORCPT ); Mon, 20 Mar 2017 23:00:51 -0400 MIME-Version: 1.0 In-Reply-To: <1490056560.20591.1.camel@gmail.com> References: <20170320134414.25f2e3d6@canb.auug.org.au> <1490055482.2504.43.camel@kernel.crashing.org> <1490056560.20591.1.camel@gmail.com> From: Joel Stanley Date: Tue, 21 Mar 2017 13:28:27 +1030 X-Google-Sender-Auth: Q7VxC8aZsFLC7AoXwOeswAVzVoI Message-ID: Subject: Re: linux-next: build failure after merge of the char-misc tree To: Cyril Bur Cc: Benjamin Herrenschmidt , Arnd Bergmann , Stephen Rothwell , Greg KH , linux-next@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1701 Lines: 42 On Tue, Mar 21, 2017 at 11:06 AM, Cyril Bur 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 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