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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 70D24ECAAD2 for ; Sun, 28 Aug 2022 11:11:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=YSaYzPH/hU51EStE/Y0fU7XCDGLUDYe8VXiQPNH1eC4=; b=boPfSpNQ9RKdOu D69gvZpX7hSVNicnyGH0r2Fe/xQxsIvJqdFS50XpvGKs9NcdTdCb0gNxObpq4D3vrA1hVQaBGCgc4 aqzvMuS+fUW/v7UyGXcY2uIbR5pt187TxfGx7uUnM1+u520Jc+CCzRfOrEfpYeKij+t85l66cDqRb HZCoDzzcsTY7iThs1D22hc/nXLXJmeY1ACjE+XYo1rU3J8eRWK44Igonyv/Lp/kVJxuZG9zfleSg4 9pLlFfHyWAz9TvoHase18ifQ1Cwvw68fkvKS2VPKoraZPzTykE+/cDnQ47OFfKUgs2QmmbUwm8J1Z IiFM+GqPPNLTjJi6LeIg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oSGBK-00GLQm-Ih; Sun, 28 Aug 2022 11:10:22 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oSGBF-00GLOs-2y for linux-arm-kernel@lists.infradead.org; Sun, 28 Aug 2022 11:10:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661685016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/Xdc5yjDQJtdeC1xQqflsPRd7xjOX2OaEJE9/AMTpio=; b=TXbHHbDRUlddbQ/DR2bH5aes4Wr5hqUb6hsPYHxIud5gXTTUYfkUgGMcZm4WCNo8HUCPhb i6HNruChtF4uoNv79DkygYb6eccNb/2IDfibP8k2Aq1TS4zWpoF1QCCEwydB2unCUuO0a5 XN60hJjpuIlfMKdLE97qrtTLIvHOjBI= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-518-v66h8T_SM0ytnqYJL7TA-A-1; Sun, 28 Aug 2022 07:10:12 -0400 X-MC-Unique: v66h8T_SM0ytnqYJL7TA-A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6804A3C021B1; Sun, 28 Aug 2022 11:10:12 +0000 (UTC) Received: from localhost (ovpn-12-25.pek2.redhat.com [10.72.12.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8B6A02166B26; Sun, 28 Aug 2022 11:10:11 +0000 (UTC) Date: Sun, 28 Aug 2022 19:10:07 +0800 From: Baoquan He To: Christophe Leroy , "hch@infradead.org" Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "agordeev@linux.ibm.com" , "wangkefeng.wang@huawei.com" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2 02/11] mm: ioremap: fixup the physical address and page prot Message-ID: References: <20220820003125.353570-1-bhe@redhat.com> <20220820003125.353570-3-bhe@redhat.com> <54b7afcc-056d-7f33-6858-d451a3222c70@csgroup.eu> <8df89136-a7f2-9b66-d522-a4fb9860bf22@csgroup.eu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8df89136-a7f2-9b66-d522-a4fb9860bf22@csgroup.eu> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220828_041017_817430_7C9EFC12 X-CRM114-Status: GOOD ( 38.58 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 08/23/22 at 07:03pm, Christophe Leroy wrote: > = > = > Le 23/08/2022 =E0 14:32, Baoquan He a =E9crit=A0: > > On 08/23/22 at 05:33am, Christophe Leroy wrote: > >> > >> > >> Le 23/08/2022 =E0 03:19, Baoquan He a =E9crit=A0: > >>> On 08/22/22 at 06:30am, Christophe Leroy wrote: > >>>> > >>>> > >>>> Le 20/08/2022 =E0 02:31, Baoquan He a =E9crit=A0: > >>>>> On some architectures, the physical address need be fixed up before > >>>>> doing mapping, e.g, parisc. And on architectures, e.g arc, the > >>>>> parameter 'prot' passed into ioremap_prot() need be adjusted too. > >>>>> > >>>>> In oder to convert them to take GENERIC_IOREMAP method, we need wrap > >>>>> the address fixing up code and page prot adjusting code into arch_i= oremap() > >>>>> and pass the new address and 'prot' out for ioremap_prot() handling. > >>>> > >>>> Is it really the best approach ? Wouldn't it be better to have helpe= rs > >>>> to do that, those helpers being called by the ioremap_prot(), instea= d of > >>>> doing it inside the arch_ioremap() function ? > >>> > >>> This is suggested too by Alexander during his v1 reviewing. I tried, = but > >>> feel the current way taken in this patchset is better. Because not all > >>> architecutres need the address fix up, only parisc, and only few need > >>> adjust the 'prot'. Introducing other helpers seems too much, that only > >>> increases the complexity of of ioremap() and the generic GENERIC_IORE= MAP > >>> method for people to understand and take. > >> > >> I can't understand. Why is it difficult to do something like: > >> > >> #ifndef ioremap_adjust_prot > >> static inline unsigned long ioremap_adjust_prot(unsigned long flags) > >> { > >> return flags; > >> } > >> #endif > >> > >> Then for arc you do > >> > >> static inline unsigned long ioremap_adjust_prot(unsigned long flags) > >> { > >> return pgprot_val(pgprot_noncached(__pgprot(flags))); > >> } > >> #define ioremap_adjust_prot ioremap_adjust_prot > > = > > My thinking is we have four things to do in the added hookers. > > 1) check if we should do ioremap on ARCHes. If not, return NULL from > > ioremap_prot(); > > 2) handling the mapping io address specifically on ARCHes, e.g arc, > > ia64, s390; > > 3) the original physical address passed into ioremap_prot() need be > > fixed up, e.g arc; > > 4) the 'prot' passed into ioremap_prot() need be adjusted, e.g on arc > > and xtensa. > > = > > With Kefeng's patches, the case 1) is handled with introduced > > ioremap_allowed()/iounmap_allowed(). In this patchset, what I do is > > rename the hooks as arch_ioremap() and arch_iounmap(), then put case 1), > > 2), 3), 4) handling into arch_ioremap(). Adding helpers to cover each > > case is not difficult from my side. I worry that as time goes by, those > > several hooks my cause issue, e.g if a new adjustment need be done, > > should we introduce a new helper or make do with the existed hook; how > > = > > When I investigated this, one arch_ioremap() looks not complicated > > since not all ARCHes need cover all above 4 cases. That's why I finally > > choose one hook. I am open to new idea, please let me know if we should > > change it to introduce several different helpers. > > = > = > A new idea that would have my preference would be to do just like we did = > with arch_get_unmapped_area(). Look at = > https://elixir.bootlin.com/linux/v6.0-rc1/source/arch/powerpc/mm/book3s64= /slice.c#L638 = > and https://elixir.bootlin.com/linux/v6.0-rc1/source/mm/mmap.c#L2131 > = > Instead of having the generic that calls the arch specific, make it the = > other way round, have the arch specific call the generic after doing its = > specialties. This sounds good. I made a draft patch to change code in generic code part, just showing what it looks like. Both arch_ioremap() way and the arch sepcific call the generic way look good to me. Just it will take less effort for me to continue the arch_ioremap() way. I would like to hear Christoph's opinion since he introduced the GENERIC_IOREMAP method and suggested the earlier arch_ioremap() way and change in this patchset. = diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index 68a8117b30fa..4bc3e18c475f 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -1047,35 +1047,18 @@ static inline void iounmap(volatile void __iomem *a= ddr) #elif defined(CONFIG_GENERIC_IOREMAP) #include = -/* - * Arch code can implement the following two hooks when using GENERIC_IORE= MAP - * arch_ioremap() return a bool, - * - IS_ERR means return an error - * - NULL means continue to remap - * - a non-NULL, non-IS_ERR pointer is returned directly - * arch_iounmap() return a bool, - * - 0 means continue to vunmap - * - error code means skip vunmap and return directly - */ -#ifndef arch_ioremap -#define arch_ioremap arch_ioremap -static inline void __iomem *arch_ioremap(phys_addr_t *paddr, size_t size, - unsigned long *prot_val) -{ - return NULL; -} -#endif +void __iomem * +generic_ioremap_prot(phys_addr_t phys_addr, size_t size, unsigned long pro= t); = -#ifndef arch_iounmap -#define arch_iounmap arch_iounmap -static inline int arch_iounmap(void __iomem *addr) +#ifndef ioremap_prot +#define ioremap_prot ioremap_prot +void __iomem * +ioremap_prot(phys_addr_t phys_addr, size_t size, unsigned long prot); { - return 0; + return generic_ioremap_prot(phys_addr, size, prot); } #endif = -void __iomem *ioremap_prot(phys_addr_t phys_addr, size_t size, - unsigned long prot); void iounmap(volatile void __iomem *addr); = #ifndef ioremap diff --git a/mm/ioremap.c b/mm/ioremap.c index 7914b5cf5b78..87d51003dee6 100644 --- a/mm/ioremap.c +++ b/mm/ioremap.c @@ -11,8 +11,8 @@ #include #include = -void __iomem *ioremap_prot(phys_addr_t phys_addr, size_t size, - unsigned long prot) +void __iomem * +generic_ioremap_prot(phys_addr_t phys_addr, size_t size, unsigned long pro= t) { unsigned long offset, vaddr; phys_addr_t last_addr; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel