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:   Mon, 17 Oct 2022 08:37:36 +0800
From:   Baoquan He <bhe@redhat.com>
To:     Christophe Leroy <christophe.leroy@csgroup.eu>
Cc:     linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        linux-arch@vger.kernel.org, akpm@linux-foundation.org,
        hch@infradead.org, agordeev@linux.ibm.com,
        wangkefeng.wang@huawei.com, schnelle@linux.ibm.com,
        David.Laight@aculab.com, shorne@gmail.com
Subject: Re: [RFC PATCH 0/8] mm: ioremap: Convert architectures to take
 GENERIC_IOREMAP way (Alternative)
Message-ID: <Y0yj0IDBVOFwCFuv@MiWiFi-R3L-srv>
References: <cover.1665568707.git.christophe.leroy@csgroup.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cover.1665568707.git.christophe.leroy@csgroup.eu>
Precedence: bulk

Hi Christophe,

On 10/12/22 at 12:09pm, Christophe Leroy wrote:
> From: 
> 
> As proposed in the discussion related to your series, here comes an
> exemple of how it could be.
> 
> I have taken it into ARC and IA64 architectures as an exemple. This is
> untested, even not compiled, it is just to illustrated my meaning in the
> discussion.
> 
> I also added a patch for powerpc architecture, that one in tested with
> both pmac32_defconfig and ppc64_le_defconfig.
> 
> From my point of view, this different approach provide less churn and
> less intellectual disturbance than the way you do it.

Yes, I agree, and admire your insistence on the thing you think right or
better. Learn from you.

When you suggested this in my v2 post, I made a draft patch at below link
according to your suggestion to request people to review. What worried
me is that I am not sure it's ignored or disliked after one week of
waiting.

https://lore.kernel.org/all/YwtND%2FL8xD+ViN3r@MiWiFi-R3L-srv/#related

Up to now, seems people don't oppose this generic_ioremap_prot() way, we
can take it. So what's your plan? You want me to continue with your
patches wrapped in, or I can leave it to you if you want to take over?

Thanks
Baoquan

> 
> Baoquan He (5):
>   hexagon: mm: Convert to GENERIC_IOREMAP
>   openrisc: mm: remove unneeded early ioremap code
>   mm: ioremap: allow ARCH to have its own ioremap definition
>   arc: mm: Convert to GENERIC_IOREMAP
>   ia64: mm: Convert to GENERIC_IOREMAP
> 
> Christophe Leroy (3):
>   mm/ioremap: Define generic_ioremap_prot() and generic_iounmap()
>   mm/ioremap: Consider IOREMAP space in generic ioremap
>   powerpc: mm: Convert to GENERIC_IOREMAP
> 
>  arch/arc/Kconfig              |  1 +
>  arch/arc/include/asm/io.h     |  7 +++---
>  arch/arc/mm/ioremap.c         | 46 +++--------------------------------
>  arch/hexagon/Kconfig          |  1 +
>  arch/hexagon/include/asm/io.h |  9 +++++--
>  arch/hexagon/mm/ioremap.c     | 44 ---------------------------------
>  arch/ia64/Kconfig             |  1 +
>  arch/ia64/include/asm/io.h    | 11 ++++++---
>  arch/ia64/mm/ioremap.c        | 45 ++++++----------------------------
>  arch/openrisc/mm/ioremap.c    | 22 ++++-------------
>  arch/powerpc/Kconfig          |  1 +
>  arch/powerpc/include/asm/io.h | 11 ++++++---
>  arch/powerpc/mm/ioremap.c     | 26 +-------------------
>  arch/powerpc/mm/ioremap_32.c  | 25 ++++++++-----------
>  arch/powerpc/mm/ioremap_64.c  | 22 +++++++----------
>  include/asm-generic/io.h      |  7 ++++++
>  mm/ioremap.c                  | 33 +++++++++++++++++++------
>  17 files changed, 98 insertions(+), 214 deletions(-)
>  delete mode 100644 arch/hexagon/mm/ioremap.c
> 
> -- 
> 2.37.1
>