Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 23 Aug 2022 20:32:42 +0800
From:   Baoquan He <bhe@redhat.com>
To:     Christophe Leroy <christophe.leroy@csgroup.eu>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "hch@infradead.org" <hch@infradead.org>,
        "agordeev@linux.ibm.com" <agordeev@linux.ibm.com>,
        "wangkefeng.wang@huawei.com" <wangkefeng.wang@huawei.com>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 02/11] mm: ioremap: fixup the physical address and
 page prot
Message-ID: <YwTI6jAjY68QK5h6@MiWiFi-R3L-srv>
References: <20220820003125.353570-1-bhe@redhat.com>
 <20220820003125.353570-3-bhe@redhat.com>
 <e7f8798a-43ac-8083-93ac-4581bd2a5647@csgroup.eu>
 <YwQrC3X3PHa0pNDy@MiWiFi-R3L-srv>
 <54b7afcc-056d-7f33-6858-d451a3222c70@csgroup.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <54b7afcc-056d-7f33-6858-d451a3222c70@csgroup.eu>
Precedence: bulk

On 08/23/22 at 05:33am, Christophe Leroy wrote:
> 
> 
> Le 23/08/2022 ? 03:19, Baoquan He a ?crit?:
> > On 08/22/22 at 06:30am, Christophe Leroy wrote:
> >>
> >>
> >> Le 20/08/2022 ? 02:31, Baoquan He a ?crit?:
> >>> 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_ioremap()
> >>> 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 helpers
> >> to do that, those helpers being called by the ioremap_prot(), instead 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_IOREMAP
> > 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.

> 
> 
> By the way, could be a good opportunity to change ioremap_prot() flags 
> type from unsigned long to pgprot_t

Tend to agree, I will give it a shot.