From patchwork Fri Sep 9 03:18:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 75840 Delivered-To: patch@linaro.org Received: by 10.140.106.11 with SMTP id d11csp137725qgf; Thu, 8 Sep 2016 20:11:35 -0700 (PDT) X-Received: by 10.98.94.6 with SMTP id s6mr2375165pfb.31.1473390695318; Thu, 08 Sep 2016 20:11:35 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id tv1si1453267pab.238.2016.09.08.20.11.35; Thu, 08 Sep 2016 20:11:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=devicetree-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751788AbcIIDLd (ORCPT + 7 others); Thu, 8 Sep 2016 23:11:33 -0400 Received: from mail-pf0-f170.google.com ([209.85.192.170]:35317 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751396AbcIIDLb (ORCPT ); Thu, 8 Sep 2016 23:11:31 -0400 Received: by mail-pf0-f170.google.com with SMTP id w87so24510079pfk.2 for ; Thu, 08 Sep 2016 20:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lirQhmzJw7j9DatML15+BBlVD+EzPepLuqWXkR/FuFI=; b=WRnrltOz5YSOtyorulq0GW6qNT7vBcBhhQdPmJQy/dQLD9oYNufcW/MgrRaImnOPMp eyg7kzlk8bKZiPmdAzMnc9FI7MuDeeAjmE590qGjypFQVsjlyhhZwA6vqbwwMVvvDaLH obxcLrMf8XfPZ7+kvj6NYoMBt8vSCMK4dq6SU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=lirQhmzJw7j9DatML15+BBlVD+EzPepLuqWXkR/FuFI=; b=RGBtjTPflwqZaVf/tMe/OMzszfo40DYmhYux9KgdU/aVMUqB/5W8OY72baYz1JRfP/ uuZLBQTLbVA9oG+ZqJzDHA+KgMNmQ9F4L5X0dc5xPO/RaNdgZvlC1cB9xmPkELzjP9+o Qi6mokpJq76C/onh72tplS4zKkxCZRj5LB3RyXTbsXqC34calrPcDnVlE8wNZigF0V/6 c0yS3RtrqUmHH0UtuBcZTdOv1oeAl8p5ngZqsvfTHCL1F+EzxAZ2jNSQ0OqrsgGuCJOx 0dX6qE7/ic7WijH27Z1eWe66qMBO5otF7EAYJ99hnbvFLOrE7q5plMV5avLOxsr7Iz9n /kOA== X-Gm-Message-State: AE9vXwNAQ0x9W4DeGYelVS1TBNrAUKWuGliPviHpsO0Jxdf5FHH8v5Y3kCvWIpwyhLtlF2uH X-Received: by 10.98.37.130 with SMTP id l124mr2476021pfl.60.1473390690256; Thu, 08 Sep 2016 20:11:30 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id w81sm886918pfa.54.2016.09.08.20.11.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 20:11:29 -0700 (PDT) Date: Fri, 9 Sep 2016 12:18:11 +0900 From: AKASHI Takahiro To: James Morse Cc: Arnd Bergmann , Guenter Roeck , Hoan Tran , Jean Delvare , Jonathan Corbet , Rob Herring , Jassi Brar , Ashwin Chaugule , Duc Dang , lho@apm.com, linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, Catalin Marinas , Will Deacon Subject: Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver Message-ID: <20160909031809.GG16712@linaro.org> Mail-Followup-To: AKASHI Takahiro , James Morse , Arnd Bergmann , Guenter Roeck , Hoan Tran , Jean Delvare , Jonathan Corbet , Rob Herring , Jassi Brar , Ashwin Chaugule , Duc Dang , lho@apm.com, linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, Catalin Marinas , Will Deacon References: <1469134557-26869-1-git-send-email-hotran@apm.com> <13081573.BbD3TmEU5Y@wuerfel> <20160907223705.GA31582@roeck-us.net> <2992356.ULGoZEEDZp@wuerfel> <57D141DF.2010603@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <57D141DF.2010603@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Sep 08, 2016 at 11:47:59AM +0100, James Morse wrote: > Hi, > > On 08/09/16 09:14, Arnd Bergmann wrote: > > On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote: > >> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote: > >>> On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote: > >>>> + ctx->comm_base_addr = cppc_ss->base_address; > >>>> + if (ctx->comm_base_addr) { > >>>> + ctx->pcc_comm_addr = > >>>> + acpi_os_ioremap(ctx->comm_base_addr, > >>>> + cppc_ss->length); > >>>> > >>> > >>> This causes the arm64 allmodconfig build to fail now, according to > >>> kernelci: > >>> > >>> 1 ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined! > >>> > >>> Should this perhaps call ioremap() or memremap() instead? > >>> > >> Hmmm ... almost sounds to me like blaming the messenger. e7cd190385d1 ("arm64: > >> mark reserved memblock regions explicitly in iomem") starts using a function > >> in acpi_os_ioremap() which is not exported. On top of that, memblock_is_memory() > >> is declared as __init_memblock, which makes me really uncomfortable. > >> If acpi_os_ioremap() must not be used by modules, and possibly only during > >> early (?) initialization, maybe its declaration should state those limitations ? > > > > Ah, I didn't notice that. I guess both patches were correct individually and > > got added to linux-next around the same time but caused allmodconfig to blow up > > when used together. > > > > Adding everyone who was involved in the memblock patch to Cc here, maybe one > > of them has an idea what the correct fix is. There are only two other drivers > > using acpi_os_ioremap() and one of them is x86-specific, so it's still likely > > that drivers are not actually supposed to use this symbol. Making > > acpi_os_ioremap() an exported function in arm64 would also work. > > You could use acpi_os_map_iomem()/acpi_os_unmap_iomem() from acpi/acpi_io.h. > If there isn't an existing mapping these end up in acpi_os_ioremap(), and are > already EXPORT_SYMBOL_GPL(). acpi_os_ioremap() is re-defined in arm64/include/asm/acpi.h. The problem is that, as memblock_is_memory() is declared as __init, we cannot build any drivers which call acpi_os_ioremap() as modules. As far as this specific issue is concerned, if we make a change like: diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c ===>8=== The build error will be gone. (and still kdump should work.) But I don't know how we should distinguish IORESOURCE_MEM and IORESOURCE_SYSTEM_RAM. Thanks, -Takahiro AKASHI > (I'm still waiting for allmodconfig on linux-next to finish building) > > > Thanks, > > James > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ===8<=== --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -207,7 +207,7 @@ static void __init request_standard_resources(void) res = alloc_bootmem_low(sizeof(*res)); if (memblock_is_nomap(region)) { res->name = "reserved"; - res->flags = IORESOURCE_MEM | IORESOURCE_BUSY; + res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; } else { res->name = "System RAM"; res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; ===>8=== and revert the following hunk from the commit: ===8<=== --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -12,7 +12,7 @@ #ifndef _ASM_ACPI_H #define _ASM_ACPI_H -#include +#include #include #include @@ -32,7 +32,11 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) { - if (!page_is_ram(phys >> PAGE_SHIFT)) + /* + * EFI's reserve_regions() call adds memory with the WB attribute + * to memblock via early_init_dt_add_memory_arch(). + */ + if (!memblock_is_memory(phys)) return ioremap(phys, size); return ioremap_cache(phys, size);