Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756851AbbBEKr0 (ORCPT ); Thu, 5 Feb 2015 05:47:26 -0500 Received: from mail-ie0-f176.google.com ([209.85.223.176]:50161 "EHLO mail-ie0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751859AbbBEKrX (ORCPT ); Thu, 5 Feb 2015 05:47:23 -0500 MIME-Version: 1.0 In-Reply-To: <20150205104149.GA18158@e104818-lin.cambridge.arm.com> References: <1422881149-8177-1-git-send-email-hanjun.guo@linaro.org> <1422881149-8177-3-git-send-email-hanjun.guo@linaro.org> <2422968.Es7R0p3loO@vostro.rjw.lan> <1422984576.18187.82.camel@deneb.redhat.com> <20150204112508.GB26006@e104818-lin.cambridge.arm.com> <1423066107.18187.99.camel@deneb.redhat.com> <20150204175734.GI26006@e104818-lin.cambridge.arm.com> <1423076294.18187.103.camel@deneb.redhat.com> <20150205104149.GA18158@e104818-lin.cambridge.arm.com> Date: Thu, 5 Feb 2015 10:47:23 +0000 Message-ID: Subject: Re: [PATCH v8 02/21] acpi: fix acpi_os_ioremap for arm64 From: Ard Biesheuvel To: Catalin Marinas Cc: Mark Salter , Mark Rutland , Mark Langsdorf , "linaro-acpi@lists.linaro.org" , Will Deacon , "wangyijing@huawei.com" , Rob Herring , Lorenzo Pieralisi , Timur Tabi , Daniel Lezcano , "linux-acpi@vger.kernel.org" , "grant.likely@linaro.org" , Charles Garcia-Tobin , "phoenix.liyi@huawei.com" , Robert Richter , Jason Cooper , Arnd Bergmann , Marc Zyngier , "jcm@redhat.com" , Mark Brown , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" , Ashwin Chaugule , "graeme.gregory@linaro.org" , Randy Dunlap , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , "hanjun.guo@linaro.org" , "suravee.suthikulpanit@amd.com" , Sudeep Holla , Olof Johansson 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: 1878 Lines: 38 On 5 February 2015 at 10:41, Catalin Marinas wrote: > On Wed, Feb 04, 2015 at 06:58:14PM +0000, Mark Salter wrote: >> On Wed, 2015-02-04 at 17:57 +0000, Catalin Marinas wrote: >> > On Wed, Feb 04, 2015 at 04:08:27PM +0000, Mark Salter wrote: >> > > acpi_os_remap() is used to map ACPI tables. These tables may be in ram >> > > which are already included in the kernel's linear RAM mapping. So we >> > > need ioremap_cache to avoid two mappings to the same physical page >> > > having different caching attributes. >> > >> > What's the call path to acpi_os_ioremap() on such tables already in the >> > linear mapping? I can see an acpi_map() function which already takes >> > care of the RAM mapping case but there are other cases where >> > acpi_os_ioremap() is called directly. For example, >> > acpi_os_read_memory(), can it be called on both RAM and I/O? >> >> acpi_map() is the one I've seen. > > By default, if should_use_kmap() is not patched for arm64, it translates > to page_is_ram(); acpi_map() would simply use a kmap() which returns the > current kernel linear mapping on arm64. > >> I'm not sure about others. > > Question for the ARM ACPI guys: what happens if you implement > acpi_os_ioremap() on arm64 as just ioremap()? Do you get any WARN_ON() > (__ioremap_caller() checks whether the memory is RAM)? > Regardless of whether you hit any WARN_ON()s now, we still need to distinguish between MMIO ranges with device semantics, and ACPI or other tables whose data may not be naturally aligned all the time, and hence requiring memory semantics. acpi_os_ioremap() may be used for both, afaik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/