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=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 F4236C5DF63 for ; Wed, 6 Nov 2019 18:12:09 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 BE4872166E for ; Wed, 6 Nov 2019 18:12:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="htq8icfj"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=dabbelt-com.20150623.gappssmtp.com header.i=@dabbelt-com.20150623.gappssmtp.com header.b="PNo3xZ45" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE4872166E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Mime-Version:Message-ID:To:From:In-Reply-To:Subject: Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References:List-Owner; bh=dw7ZjzVbl1GSpswoPiS2vpdNa17CI38k5vOYfnSTptI=; b=htq8icfjYuPMY+Ka0YrdWQjC6 4+qDPwZHVRF8AUGi4lohbg7BYBZIlNi1aOezTgf9KOnZvFxfzrtRhVAbuYIzMo15tdFOXgBOQCEwG UE/pqXRrAN40HGX3j0picnzh/VZc+LYxd7tR0Qw9+x99HyXI8fsTe+IKW9S7ibRsX0yaad27pur3z ucZE3q56u1eZqeyd4hINKqniKFyQeGKl23SiWY9hk57FQ9tGMhCIelwVQqyT2AwS0Lg4XTCxHK+XT ez/RV4+PlNNE659xICUCbfjVF1OF2wnm3yeUj9v4TShuftG5dSx2a00xeXMHngn0EsYnwVZJip9P2 P51Ji5iXw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iSPmd-00040b-0E; Wed, 06 Nov 2019 18:11:55 +0000 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iSPmO-0003kl-Oe for linux-mtd@lists.infradead.org; Wed, 06 Nov 2019 18:11:44 +0000 Received: by mail-pg1-x541.google.com with SMTP id q22so10068910pgk.2 for ; Wed, 06 Nov 2019 10:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20150623.gappssmtp.com; s=20150623; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=j8eNwULKpZxPZC3Ue7l8WChG2Sw1ZeM6zGQJhcLB2q4=; b=PNo3xZ45pD8y2N6reebfbfZpOdqqiBr1Lz+k6yQFI0L0/2p4rg9rq6quFNZC0fUzEy WlsJw4SBofaliFzu25uc3GL+jfLPaDDaxBBSeFuxKZdU+M46CbuLmJCyYZ3YubRPMmb4 KJuh7ZayA7bBdQZfTwcK1CQOU3wgdx+7HYStjSw481T2P1SlQpPljbqXrje6nW+uncab xnl2WqnQq3h3MzYeukOBvYmW22S70Ab9cogKRn6Y5e/sTOn8Whd6Q8gV3t9/yTSsvIJH qW1nfHNHClKIYFKkd63n+sMzCsL83vOlxoTHUSAO8sIcR8NpgIG3bG3BN+f8kRlw/+Kv 8mzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=j8eNwULKpZxPZC3Ue7l8WChG2Sw1ZeM6zGQJhcLB2q4=; b=CpB1+2aoBpwmtrstbKnlB+2IzrvorohLOCn1VvhSgBwPHM6cAH/T5GgAIWYxRainu2 MANKAgAM0YEqp32VUH5o5/ze70+ITHx31ZScooCkwdSGj4KnzF9Rlro7I1Q+34E2YpSX m70Se0w1MW0xx3btFPXYb8bTGDXIYDQUgDDi2trl0eJU6TGfEx7vX8mv8PAwde/dlJgp 3UwJdpYywczG07qRxU6pqWIn2BXTSdzQrfyv/WDpqkQOZK2PN3E4J+xF70piAHG5nb+5 AGedRoA5XDg3R9tc8V4Wjs0mUJod3t5FAxAJlZv0x+Kr7rL4UswNT65rYzf8AIikLr+V 7W8w== X-Gm-Message-State: APjAAAUSgRulhX3826QAH4KWt3g6df+Qq5hVb3MQzBkSCwgqUVqs7fxw G4nJ/MbAcKxhM68S47POf9O80g== X-Google-Smtp-Source: APXvYqyi7QvVvwFbCwtrCcolLw/HV05dOHLVSXF3jAYddzEgRk4byr6sPDxWkoeeO54icKRZXqVAsQ== X-Received: by 2002:a62:170b:: with SMTP id 11mr4988303pfx.85.1573063899585; Wed, 06 Nov 2019 10:11:39 -0800 (PST) Received: from localhost ([12.206.222.5]) by smtp.gmail.com with ESMTPSA id i5sm12394738pfo.52.2019.11.06.10.11.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Nov 2019 10:11:37 -0800 (PST) Date: Wed, 06 Nov 2019 10:11:37 -0800 (PST) X-Google-Original-Date: Wed, 06 Nov 2019 10:11:28 PST (-0800) Subject: Re: [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU In-Reply-To: <20191029064834.23438-12-hch@lst.de> From: Palmer Dabbelt To: Christoph Hellwig Message-ID: Mime-Version: 1.0 (MHng) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191106_101140_806324_C9464CA5 X-CRM114-Status: GOOD ( 25.08 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, guoren@kernel.org, sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org, deanbo422@gmail.com, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, linux-hexagon@vger.kernel.org, x86@kernel.org, linux-snps-arc@lists.infradead.org, linux-xtensa@linux-xtensa.org, Arnd Bergmann , linux-m68k@lists.linux-m68k.org, openrisc@lists.librecores.org, green.hu@gmail.com, linux-mtd@lists.infradead.org, gxt@pku.edu.cn, linux-arm-kernel@lists.infradead.org, monstr@monstr.eu, linux-parisc@vger.kernel.org, linux-mips@vger.kernel.org, linux-alpha@vger.kernel.org, nios2-dev@lists.rocketboards.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Mon, 28 Oct 2019 23:48:24 PDT (-0700), Christoph Hellwig wrote: > All MMU-enabled ports have a non-trivial ioremap and should thus provide > the prototype for their implementation instead of providing a generic > one unless a different symbol is not defined. Note that this only > affects sparc32 nds32 as all others do provide their own version. > > Also update the kerneldoc comments in asm-generic/io.h to explain the > situation around the default ioremap* implementations correctly. > > Signed-off-by: Christoph Hellwig > --- > arch/nds32/include/asm/io.h | 2 ++ > arch/sparc/include/asm/io_32.h | 1 + > include/asm-generic/io.h | 29 ++++++++--------------------- > 3 files changed, 11 insertions(+), 21 deletions(-) > > diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h > index 16f262322b8f..fb0e8a24c7af 100644 > --- a/arch/nds32/include/asm/io.h > +++ b/arch/nds32/include/asm/io.h > @@ -6,6 +6,7 @@ > > #include > > +void __iomem *ioremap(phys_addr_t phys_addr, size_t size); > extern void iounmap(volatile void __iomem *addr); > #define __raw_writeb __raw_writeb > static inline void __raw_writeb(u8 val, volatile void __iomem *addr) > @@ -80,4 +81,5 @@ static inline u32 __raw_readl(const volatile void __iomem *addr) > #define writew(v,c) ({ __iowmb(); writew_relaxed((v),(c)); }) > #define writel(v,c) ({ __iowmb(); writel_relaxed((v),(c)); }) > #include > + > #endif /* __ASM_NDS32_IO_H */ > diff --git a/arch/sparc/include/asm/io_32.h b/arch/sparc/include/asm/io_32.h > index df2dc1784673..9a52d9506f80 100644 > --- a/arch/sparc/include/asm/io_32.h > +++ b/arch/sparc/include/asm/io_32.h > @@ -127,6 +127,7 @@ static inline void sbus_memcpy_toio(volatile void __iomem *dst, > * Bus number may be embedded in the higher bits of the physical address. > * This is why we have no bus number argument to ioremap(). > */ > +void __iomem *ioremap(phys_addr_t offset, size_t size); > void iounmap(volatile void __iomem *addr); > /* Create a virtual mapping cookie for an IO port range */ > void __iomem *ioport_map(unsigned long port, unsigned int nr); > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h > index a98ed6325727..6a5edc23afe2 100644 > --- a/include/asm-generic/io.h > +++ b/include/asm-generic/io.h > @@ -922,28 +922,16 @@ static inline void *phys_to_virt(unsigned long address) > /** > * DOC: ioremap() and ioremap_*() variants > * > - * If you have an IOMMU your architecture is expected to have both ioremap() > - * and iounmap() implemented otherwise the asm-generic helpers will provide a > - * direct mapping. > + * Architectures with an MMU are expected to provide ioremap() and iounmap() > + * themselves. For NOMMU architectures we provide a default nop-op > + * implementation that expect that the physical address used for MMIO are > + * already marked as uncached, and can be used as kernel virtual addresses. > * > - * There are ioremap_*() call variants, if you have no IOMMU we naturally will > - * default to direct mapping for all of them, you can override these defaults. > - * If you have an IOMMU you are highly encouraged to provide your own > - * ioremap variant implementation as there currently is no safe architecture > - * agnostic default. To avoid possible improper behaviour default asm-generic > - * ioremap_*() variants all return NULL when an IOMMU is available. If you've > - * defined your own ioremap_*() variant you must then declare your own > - * ioremap_*() variant as defined to itself to avoid the default NULL return. > + * 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. > */ > #ifndef CONFIG_MMU > - > -/* > - * Change "struct page" to physical address. > - * > - * This implementation is for the no-MMU case only... if you have an MMU > - * you'll need to provide your own definitions. > - */ > - > #ifndef ioremap > #define ioremap ioremap > static inline void __iomem *ioremap(phys_addr_t offset, size_t size) > @@ -954,14 +942,13 @@ static inline void __iomem *ioremap(phys_addr_t offset, size_t size) > > #ifndef iounmap > #define iounmap iounmap > - > static inline void iounmap(void __iomem *addr) > { > } > #endif > #endif /* CONFIG_MMU */ > + > #ifndef ioremap_nocache > -void __iomem *ioremap(phys_addr_t phys_addr, size_t size); > #define ioremap_nocache ioremap_nocache > static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size) > { It looks like the difference in prototype between the architectures is between void __iomem *ioremap(resource_size_t, size_t) void __iomem *ioremap(phys_addr_t, size_t) void __iomem *ioremap(phys_addr_t, unsigned long) void __iomem *ioremap(unsigned long, unsigned long) shouldn't they all just be that first one? In other words, wouldn't it be better to always provide the generic ioremap prototype and unify the ports instead? ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/