From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6801FC433DB for ; Wed, 24 Mar 2021 18:14:18 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0A2D561A1E for ; Wed, 24 Mar 2021 18:14:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A2D561A1E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ilAmOr0VEWJr4vZAhZsqz9qpkgCvO0mBLFGHTJi1yQE=; b=qifaSlpc0bQpLEI6kJD5FxWol mblk5V6JBzH8/XYZTGL6+Pa1072cWXK8/XwgRS+VxZhhdGUXu5kd9GMIofZi9P02Zo76cKnieyXz0 lCZiY5UiPuJgtb/a8+jy+Spg9FImgeB0lixNxXPjpOphU0BZV5jBwFH8vjdxDFtOgmyFe6lsYFWEp cO9G9SpFGEtMqCGK4FSsemdegWtsHCeGbZSog8ARhAcvydFaO6D5Jxj9WrhC5ySuQh6alhqzsSrKp VlQRRrzwTW0ZAqNoneHmJ0HCUXV2X+OeNOMomWI7JiO/BytS40M5f7YJtTfDVOrdfKP+Gtue93l3c Ih9L6IzdQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lP7zW-0001WK-C6; Wed, 24 Mar 2021 18:12:27 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lP7zP-0001VJ-Cn for linux-arm-kernel@lists.infradead.org; Wed, 24 Mar 2021 18:12:23 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id E3F2E61A24; Wed, 24 Mar 2021 18:12:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616609537; bh=MgoXkuObURmUvWuUKdbb9OKYxXjUYO+tnI1HEsW+seM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SNZOeiggKvkMd+AmGZyu+AydOXj83oW7ynub4lSjobGEDAnsD4JxGyit4ES49Whfn 5cXGZJghwajWlTjP3zlctOgas7fnf3F3un2ilMpJ/P2q6GMlHdr6ee00HjzDJmoluZ dHQqSr8W02oQUOk2/2fyxniJDNik2LrlSoGDiBIZ14EAiPBC823Hg3Xd31LOZ/r2pd JF9jdN36strHOO2F5uVdPNeFJk2Jc56insBYw3zAl8h/30SYdCIBZcyKJseZ0cZ1CR s1zSjGNVmWnJNd2rVhYpT2B2+0SkopHJmG49IP6kxbQERGweAlxHfPIHBjMMSn0G3p aD6VdTjdhpG0w== Date: Wed, 24 Mar 2021 18:12:10 +0000 From: Will Deacon To: Hector Martin Cc: linux-arm-kernel@lists.infradead.org, Marc Zyngier , Rob Herring , Arnd Bergmann , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Linus Walleij , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , devicetree@vger.kernel.org, linux-serial@vger.kernel.org, linux-doc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFT PATCH v3 08/27] asm-generic/io.h: Add a non-posted variant of ioremap() Message-ID: <20210324181210.GB13181@willie-the-truck> References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-9-marcan@marcan.st> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210304213902.83903-9-marcan@marcan.st> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210324_181219_916502_87C63CF9 X-CRM114-Status: GOOD ( 31.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Mar 05, 2021 at 06:38:43AM +0900, Hector Martin wrote: > ARM64 currently defaults to posted MMIO (nGnRnE), but some devices > require the use of non-posted MMIO (nGnRE). Introduce a new ioremap() > variant to handle this case. ioremap_np() is aliased to ioremap() by > default on arches that do not implement this variant. > > sparc64 is the only architecture that needs to be touched directly, > because it includes neither of the generic io.h or iomap.h headers. > > This adds the IORESOURCE_MEM_NONPOSTED flag, which maps to this > variant and marks a given resource as requiring non-posted mappings. > This is implemented in the resource system because it is a SoC-level > requirement, so existing drivers do not need special-case code to pick > this ioremap variant. > > Then this is implemented in devres by introducing devm_ioremap_np(), > and making devm_ioremap_resource() automatically select this variant > when the resource has the IORESOURCE_MEM_NONPOSTED flag set. > > Signed-off-by: Hector Martin > --- > .../driver-api/driver-model/devres.rst | 1 + > arch/sparc/include/asm/io_64.h | 4 ++++ > include/asm-generic/io.h | 22 ++++++++++++++++++- > include/asm-generic/iomap.h | 9 ++++++++ > include/linux/io.h | 2 ++ > include/linux/ioport.h | 1 + > lib/devres.c | 22 +++++++++++++++++++ > 7 files changed, 60 insertions(+), 1 deletion(-) > > diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst > index cd8b6e657b94..2f45877a539d 100644 > --- a/Documentation/driver-api/driver-model/devres.rst > +++ b/Documentation/driver-api/driver-model/devres.rst > @@ -309,6 +309,7 @@ IOMAP > devm_ioremap() > devm_ioremap_uc() > devm_ioremap_wc() > + devm_ioremap_np() > devm_ioremap_resource() : checks resource, requests memory region, ioremaps > devm_ioremap_resource_wc() > devm_platform_ioremap_resource() : calls devm_ioremap_resource() for platform device > diff --git a/arch/sparc/include/asm/io_64.h b/arch/sparc/include/asm/io_64.h > index 9bb27e5c22f1..9fbfc9574432 100644 > --- a/arch/sparc/include/asm/io_64.h > +++ b/arch/sparc/include/asm/io_64.h > @@ -409,6 +409,10 @@ static inline void __iomem *ioremap(unsigned long offset, unsigned long size) > #define ioremap_uc(X,Y) ioremap((X),(Y)) > #define ioremap_wc(X,Y) ioremap((X),(Y)) > #define ioremap_wt(X,Y) ioremap((X),(Y)) > +static inline void __iomem *ioremap_np(unsigned long offset, unsigned long size) > +{ > + return NULL; > +} > > static inline void iounmap(volatile void __iomem *addr) > { > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h > index c6af40ce03be..082e0c96db6e 100644 > --- a/include/asm-generic/io.h > +++ b/include/asm-generic/io.h > @@ -942,7 +942,9 @@ static inline void *phys_to_virt(unsigned long address) > * > * ioremap_wc() and ioremap_wt() can provide more relaxed caching attributes > * for specific drivers if the architecture choses to implement them. If they > - * are not implemented we fall back to plain ioremap. > + * are not implemented we fall back to plain ioremap. Conversely, ioremap_np() > + * can provide stricter non-posted write semantics if the architecture > + * implements them. > */ > #ifndef CONFIG_MMU > #ifndef ioremap > @@ -993,6 +995,24 @@ static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size) > { > return NULL; > } > + > +/* > + * ioremap_np needs an explicit architecture implementation, as it > + * requests stronger semantics than regular ioremap(). Portable drivers > + * should instead use one of the higher-level abstractions, like > + * devm_ioremap_resource(), to choose the correct variant for any given > + * device and bus. Portable drivers with a good reason to want non-posted > + * write semantics should always provide an ioremap() fallback in case > + * ioremap_np() is not available. > + */ > +#ifndef ioremap_np > +#define ioremap_np ioremap_np > +static inline void __iomem *ioremap_np(phys_addr_t offset, size_t size) > +{ > + return NULL; > +} > +#endif Can we implement the generic pci_remap_cfgspace() in terms of ioremap_np() if it is supported by the architecture? That way, we could avoid defining both on arm64. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel