Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-156-g081acc5ed5-fm-20230206.001-g081acc5e
Mime-Version: 1.0
Message-Id: <056cc71f-7fb9-4d38-a442-a05de6f7d437@app.fastmail.com>
In-Reply-To: <20230216123419.461016-2-bhe@redhat.com>
References: <20230216123419.461016-1-bhe@redhat.com>
 <20230216123419.461016-2-bhe@redhat.com>
Date:   Thu, 16 Feb 2023 13:53:21 +0100
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Baoquan He" <bhe@redhat.com>, linux-kernel@vger.kernel.org
Cc:     linux-mm@kvack.org, "Andrew Morton" <akpm@linux-foundation.org>,
        "Christophe Leroy" <christophe.leroy@csgroup.eu>,
        "Christoph Hellwig" <hch@infradead.org>,
        "Alexander Gordeev" <agordeev@linux.ibm.com>,
        "Kefeng Wang" <wangkefeng.wang@huawei.com>,
        "Niklas Schnelle" <schnelle@linux.ibm.com>,
        "David Laight" <David.Laight@ACULAB.COM>,
        "Stafford Horne" <shorne@gmail.com>,
        "Brian Cain" <bcain@quicinc.com>, linux-hexagon@vger.kernel.org
Subject: Re: [PATCH v4 01/16] hexagon: mm: Convert to GENERIC_IOREMAP
Content-Type: text/plain
Precedence: bulk

On Thu, Feb 16, 2023, at 13:34, Baoquan He wrote:
> diff --git a/arch/hexagon/include/asm/io.h 
> b/arch/hexagon/include/asm/io.h
> index 46a099de85b7..dcd9cbbf5934 100644
> --- a/arch/hexagon/include/asm/io.h
> +++ b/arch/hexagon/include/asm/io.h
> @@ -170,8 +170,13 @@ static inline void writel(u32 data, volatile void 
> __iomem *addr)
>  #define writew_relaxed __raw_writew
>  #define writel_relaxed __raw_writel
> 
> -void __iomem *ioremap(unsigned long phys_addr, unsigned long size);
> -#define ioremap_uc(X, Y) ioremap((X), (Y))
> +/*
> + * I/O memory mapping functions.
> + */
> +#define _PAGE_IOREMAP (_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE | \
> +		       (__HEXAGON_C_DEV << 6))
> +
> +#define ioremap_uc(addr, size) ioremap((addr), (size))

I think we probably want to kill off ioremap_uc() here, and use
the generic version that just returns NULL.

I see that there are only two callers of {devm_,}ioremap_uc() left in the
tree, so maybe we can even take that final step and remove it from
the interface. Maybe we can revisit [1] as part of this series.

     Arnd

[1] https://lore.kernel.org/all/20191111192258.2234502-1-arnd@arndb.de/