linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Baoquan He <bhe@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "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>,
	"schnelle@linux.ibm.com" <schnelle@linux.ibm.com>,
	"David.Laight@ACULAB.COM" <David.Laight@ACULAB.COM>,
	"shorne@gmail.com" <shorne@gmail.com>
Subject: Re: [PATCH v3 00/11] mm: ioremap: Convert architectures to take GENERIC_IOREMAP way
Date: Wed, 12 Oct 2022 10:08:16 +0000	[thread overview]
Message-ID: <4805bfd4-d54c-8590-f9a6-b6056985d514@csgroup.eu> (raw)
In-Reply-To: <20221009103114.149036-1-bhe@redhat.com>

Hi,

Le 09/10/2022 à 12:31, Baoquan He a écrit :
> Currently, many architecutres have't taken the standard GENERIC_IOREMAP
> way to implement ioremap_prot(), iounmap(), and ioremap_xx(), but make
> these functions specifically under each arch's folder. Those cause many
> duplicated codes of ioremap() and iounmap().
> 
> In this patchset, firstly adapt the hooks io[re|un]map_allowed, then
> make use of them to convert those ARCH-es to take GENERIC_IOREMAP method.
> With these change, duplicated ioremap/iounmap() code uder ARCH-es are
> removed.
> 
> This is suggested by Christoph in below discussion:
> https://lore.kernel.org/all/Yp7h0Jv6vpgt6xdZ@infradead.org/T/#u
> 
> And it's basically further action after arm64 has converted to
> GENERIC_IOREMAP way in below patchset.
> [PATCH v5 0/6] arm64: Cleanup ioremap() and support ioremap_prot()
> https://lore.kernel.org/all/20220607125027.44946-1-wangkefeng.wang@huawei.com/T/#u
> 

I'm still puzzled with your series, it seems more churn than needed, and 
I still deeply dislike the approach where a function called 
arch_ioremap() says "Today I don't feel like doing the job so I return 
NULL and you'll do it for me"

In order to better illustrate what I have in mind as discussed 
previously, I have prepared a short RFC series based on your v3, taking 
into account the first two architectures (ARC and IA64) of your series, 
and also adding POWERPC architecture. I will send it out shortly.

Christophe

> v2->v3:
> - Rewrite log of all patches to add more details as Christoph suggested.
> 
> - Merge the old patch 1 and 2 which adjusts return values and
>    parameters of arch_ioremap() into one patch, namely the current
>    patch 3. Christoph suggested this.
> 
> - Change the return value of arch_iounmap() to bool type since we only
>    do arch specific address filtering or address checking, bool value
>    can reflect the checking better. This is pointed out by Niklas when
>    he reviewed the s390 patch.
>    
> - Put hexagon patch at the beginning of patchset since hexagon has the
>    same ioremap() and iounmap() as standard ones, no arch_ioremap() and
>    arch_iounmap() hooks need be introduced. So the later arch_ioremap
>    and arch_iounmap() adjustment are not related in hexagon. Christophe
>    suggested this.
> 
> - Remove the early ioremap code from openrisc ioremap() firstly since
>    openrisc doesn't have early ioremap handling in openrisc arch code.
>    This simplifies the later converting to GENERIC_IOREMAP method.
>    Christoph and Stafford suggersted this.
> 
> - Fix compiling erorrs reported by lkp in parisc and sh patches.
>    Adding macro defintions for those port|mem io functions in
>    <asm/io.h> to avoid repeated definition in <asm-generic/io.h>.
> 
> v1->v2:
> - Rename io[re|un]map_allowed() to arch_io[re|un]map() and made
>    some minor changes in patch 1~2 as per Alexander and Kefeng's
>    suggestions. Accordingly, adjust patches~4~11 because of the renaming
>    arch_io[re|un]map().
> 
> Testing:
> - It's running well on arm64 system with the latest upstream kernel
>    and this patchset applied.
> - Cross compiling passed on arc, ia64, parisc, s390, sh, xtensa.
> - cross compiling is not tried on hexagon and openrisc because
>    - Didn't find cross compiling tools for hexagon;
>    - there's error with openrisc compiling, while I have no idea how to
>      fix it. Please see below pasted log:
>      ---------------------------------------------------------------------
>      [root@intel-knightslanding-lb-02 linux]# make ARCH=openrisc defconfig
>      *** Default configuration is based on 'or1ksim_defconfig'
>      #
>      # configuration written to .config
>      #
>      [root@intel-knightslanding-lb-02 linux]# make ARCH=openrisc -j320 CROSS_COMPILE=/usr/bin/openrisc-linux-gnu-
>        SYNC    include/config/auto.conf.cmd
>        CC      scripts/mod/empty.o
>      ./scripts/check-local-export: /usr/bin/openrisc-linux-gnu-nm failed
>      make[1]: *** [scripts/Makefile.build:250: scripts/mod/empty.o] Error 1
>      make[1]: *** Deleting file 'scripts/mod/empty.o'
>      make: *** [Makefile:1275: prepare0] Error 2
>      ----------------------------------------------------------------------
> 
> Baoquan He (11):
>    hexagon: mm: Convert to GENERIC_IOREMAP
>    openrisc: mm: remove unneeded early ioremap code
>    mm/ioremap: change the return value of io[re|un]map_allowed and rename
>    mm: ioremap: allow ARCH to have its own ioremap definition
>    arc: mm: Convert to GENERIC_IOREMAP
>    ia64: mm: Convert to GENERIC_IOREMAP
>    openrisc: mm: Convert to GENERIC_IOREMAP
>    parisc: mm: Convert to GENERIC_IOREMAP
>    s390: mm: Convert to GENERIC_IOREMAP
>    sh: mm: Convert to GENERIC_IOREMAP
>    xtensa: mm: Convert to GENERIC_IOREMAP
> 
>   arch/arc/Kconfig                  |  1 +
>   arch/arc/include/asm/io.h         | 19 ++++++---
>   arch/arc/mm/ioremap.c             | 60 ++++-----------------------
>   arch/arm64/include/asm/io.h       |  5 ++-
>   arch/arm64/mm/ioremap.c           | 16 +++++---
>   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        | 26 +++++++-----
>   arch/ia64/mm/ioremap.c            | 50 +++++------------------
>   arch/openrisc/Kconfig             |  1 +
>   arch/openrisc/include/asm/io.h    | 12 ++++--
>   arch/openrisc/mm/ioremap.c        | 62 ++--------------------------
>   arch/parisc/Kconfig               |  1 +
>   arch/parisc/include/asm/io.h      | 19 ++++++---
>   arch/parisc/mm/ioremap.c          | 65 +++---------------------------
>   arch/s390/Kconfig                 |  1 +
>   arch/s390/include/asm/io.h        | 25 +++++++-----
>   arch/s390/pci/pci.c               | 65 ++++++------------------------
>   arch/sh/Kconfig                   |  1 +
>   arch/sh/include/asm/io.h          | 67 +++++++++++++++++--------------
>   arch/sh/include/asm/io_noioport.h |  7 ++++
>   arch/sh/mm/ioremap.c              | 63 ++++++-----------------------
>   arch/xtensa/Kconfig               |  1 +
>   arch/xtensa/include/asm/io.h      | 39 ++++++++----------
>   arch/xtensa/mm/ioremap.c          | 56 ++++++--------------------
>   include/asm-generic/io.h          | 30 ++++++++------
>   mm/ioremap.c                      | 13 ++++--
>   29 files changed, 248 insertions(+), 512 deletions(-)
>   delete mode 100644 arch/hexagon/mm/ioremap.c
> 

      parent reply	other threads:[~2022-10-12 10:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-09 10:31 [PATCH v3 00/11] mm: ioremap: Convert architectures to take GENERIC_IOREMAP way Baoquan He
2022-10-09 10:31 ` [PATCH v3 01/11] hexagon: mm: Convert to GENERIC_IOREMAP Baoquan He
2022-10-09 16:39   ` Christophe Leroy
2022-10-10  0:17     ` Baoquan He
2022-10-09 10:31 ` [PATCH v3 02/11] openrisc: mm: remove unneeded early ioremap code Baoquan He
2022-10-09 10:31 ` [PATCH v3 03/11] mm/ioremap: change the return value of io[re|un]map_allowed and rename Baoquan He
2022-10-09 11:13   ` Kefeng Wang
2022-10-10  0:25     ` Baoquan He
2022-10-10  0:55       ` Kefeng Wang
2022-10-09 10:31 ` [PATCH v3 04/11] mm: ioremap: allow ARCH to have its own ioremap definition Baoquan He
2022-10-09 10:31 ` [PATCH v3 05/11] arc: mm: Convert to GENERIC_IOREMAP Baoquan He
2022-10-12 10:17   ` Christophe Leroy
2022-10-13  9:51     ` Baoquan He
2022-10-09 10:31 ` [PATCH v3 06/11] ia64: " Baoquan He
2022-10-09 10:31 ` [PATCH v3 07/11] openrisc: " Baoquan He
2022-10-09 10:31 ` [PATCH v3 08/11] parisc: " Baoquan He
2022-10-09 10:31 ` [PATCH v3 09/11] s390: " Baoquan He
2022-10-09 13:54   ` kernel test robot
2022-10-10 10:38     ` Baoquan He
2022-10-10 11:53       ` Niklas Schnelle
2022-10-11  3:00         ` Baoquan He
2022-10-11 15:16   ` Niklas Schnelle
2022-10-12  5:52     ` Baoquan He
2022-10-12  7:37       ` Niklas Schnelle
2022-10-12  9:20         ` Baoquan He
2022-10-09 10:31 ` [PATCH v3 10/11] sh: " Baoquan He
2022-10-09 14:16   ` kernel test robot
2022-10-09 10:31 ` [PATCH v3 11/11] xtensa: " Baoquan He
2022-10-09 16:12   ` kernel test robot
2022-10-10  2:47     ` Baoquan He
2022-10-12 10:08 ` Christophe Leroy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4805bfd4-d54c-8590-f9a6-b6056985d514@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=David.Laight@ACULAB.COM \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=schnelle@linux.ibm.com \
    --cc=shorne@gmail.com \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).