From: Baoquan He <bhe@redhat.com>
To: Matthew Wilcox <willy@infradead.org>,
Edward Cree <ecree.xilinx@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org, arnd@arndb.de, christophe.leroy@csgroup.eu,
hch@infradead.org, agordeev@linux.ibm.com,
wangkefeng.wang@huawei.com, schnelle@linux.ibm.com,
David.Laight@aculab.com, shorne@gmail.com,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
x86@kernel.org, netdev@vger.kernel.org,
Martin Habets <habetsm.xilinx@gmail.com>
Subject: Re: [PATCH v5 01/17] asm-generic/iomap.h: remove ARCH_HAS_IOREMAP_xx macros
Date: Wed, 1 Mar 2023 17:24:26 +0800 [thread overview]
Message-ID: <Y/8Zyjfuypg3EiDd@MiWiFi-R3L-srv> (raw)
In-Reply-To: <Y/7eceqZ+89iPm1C@casper.infradead.org>
On 03/01/23 at 05:11am, Matthew Wilcox wrote:
> On Wed, Mar 01, 2023 at 04:38:10AM +0000, Edward Cree wrote:
> > On 01/03/2023 03:42, Baoquan He wrote:
> > > diff --git a/drivers/net/ethernet/sfc/io.h b/drivers/net/ethernet/sfc/io.h
> > > index 30439cc83a89..07f99ad14bf3 100644
> > > --- a/drivers/net/ethernet/sfc/io.h
> > > +++ b/drivers/net/ethernet/sfc/io.h
> > > @@ -70,7 +70,7 @@
> > > */
> > > #ifdef CONFIG_X86_64
> > > /* PIO is a win only if write-combining is possible */
> > > -#ifdef ARCH_HAS_IOREMAP_WC
> > > +#ifdef ioremap_wc
> > > #define EFX_USE_PIO 1
> > > #endif
> > > #endif
> >
> > So I don't know how valid what we're doing here is...
>
> Well, x86 defines ARCH_HAS_IOREMAP_WC unconditionally, so it doesn't
> affect you ... but you raise a good question about how a driver can
> determine if it's actually getting WC memory.
Yeah, this change doesn't affect sfc. Because ARCH_HAS_IOREMAP_WC is used to
make ioremap_wc defined in <asm/io.h> override the default one in
<asm-generic/iomap.h>, this patch has made code have the same effect.
Besides, I have a question still in my mind. Surely this is unrelated to
this patch.
In commit 38d9029a652c (parisc: Define ioremap_uc and ioremap_wc),
ioremap_wc definition was added in arch/parisc/include/asm/io.h, and it
didn't add ARCH_HAS_IOREMAP_WC definition. However, it won't cause
redefinition of ioremap_wc, even though there's "#include <asm-generic/iomap.h>"
at below. I could be dizzy on these io.h and iomap.h.
When I added ioremap_wt and ioremap_np to debug, ioremap_np will
cause redefinition, while ioremap_wt woundn't. Does anyone know what
I am missing?
diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
index c05e781be2f5..20d566eec3b3 100644
--- a/arch/parisc/include/asm/io.h
+++ b/arch/parisc/include/asm/io.h
@@ -127,6 +127,8 @@ static inline void gsc_writeq(unsigned long long val, unsigned long addr)
*/
void __iomem *ioremap(unsigned long offset, unsigned long size);
#define ioremap_wc ioremap
+#define ioremap_wt ioremap
+#define ioremap_np ioremap
#define ioremap_uc ioremap
#define pci_iounmap pci_iounmap
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Matthew Wilcox <willy@infradead.org>,
Edward Cree <ecree.xilinx@gmail.com>
Cc: linux-arch@vger.kernel.org, wangkefeng.wang@huawei.com,
arnd@arndb.de, schnelle@linux.ibm.com, netdev@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-mips@vger.kernel.org, hch@infradead.org,
linux-mm@kvack.org, linux-m68k@lists.linux-m68k.org,
David.Laight@aculab.com, loongarch@lists.linux.dev,
Martin Habets <habetsm.xilinx@gmail.com>,
agordeev@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
shorne@gmail.com
Subject: Re: [PATCH v5 01/17] asm-generic/iomap.h: remove ARCH_HAS_IOREMAP_xx macros
Date: Wed, 1 Mar 2023 17:24:26 +0800 [thread overview]
Message-ID: <Y/8Zyjfuypg3EiDd@MiWiFi-R3L-srv> (raw)
In-Reply-To: <Y/7eceqZ+89iPm1C@casper.infradead.org>
On 03/01/23 at 05:11am, Matthew Wilcox wrote:
> On Wed, Mar 01, 2023 at 04:38:10AM +0000, Edward Cree wrote:
> > On 01/03/2023 03:42, Baoquan He wrote:
> > > diff --git a/drivers/net/ethernet/sfc/io.h b/drivers/net/ethernet/sfc/io.h
> > > index 30439cc83a89..07f99ad14bf3 100644
> > > --- a/drivers/net/ethernet/sfc/io.h
> > > +++ b/drivers/net/ethernet/sfc/io.h
> > > @@ -70,7 +70,7 @@
> > > */
> > > #ifdef CONFIG_X86_64
> > > /* PIO is a win only if write-combining is possible */
> > > -#ifdef ARCH_HAS_IOREMAP_WC
> > > +#ifdef ioremap_wc
> > > #define EFX_USE_PIO 1
> > > #endif
> > > #endif
> >
> > So I don't know how valid what we're doing here is...
>
> Well, x86 defines ARCH_HAS_IOREMAP_WC unconditionally, so it doesn't
> affect you ... but you raise a good question about how a driver can
> determine if it's actually getting WC memory.
Yeah, this change doesn't affect sfc. Because ARCH_HAS_IOREMAP_WC is used to
make ioremap_wc defined in <asm/io.h> override the default one in
<asm-generic/iomap.h>, this patch has made code have the same effect.
Besides, I have a question still in my mind. Surely this is unrelated to
this patch.
In commit 38d9029a652c (parisc: Define ioremap_uc and ioremap_wc),
ioremap_wc definition was added in arch/parisc/include/asm/io.h, and it
didn't add ARCH_HAS_IOREMAP_WC definition. However, it won't cause
redefinition of ioremap_wc, even though there's "#include <asm-generic/iomap.h>"
at below. I could be dizzy on these io.h and iomap.h.
When I added ioremap_wt and ioremap_np to debug, ioremap_np will
cause redefinition, while ioremap_wt woundn't. Does anyone know what
I am missing?
diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
index c05e781be2f5..20d566eec3b3 100644
--- a/arch/parisc/include/asm/io.h
+++ b/arch/parisc/include/asm/io.h
@@ -127,6 +127,8 @@ static inline void gsc_writeq(unsigned long long val, unsigned long addr)
*/
void __iomem *ioremap(unsigned long offset, unsigned long size);
#define ioremap_wc ioremap
+#define ioremap_wt ioremap
+#define ioremap_np ioremap
#define ioremap_uc ioremap
#define pci_iounmap pci_iounmap
next prev parent reply other threads:[~2023-03-01 9:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-01 3:42 [PATCH v5 00/17] mm: ioremap: Convert architectures to take GENERIC_IOREMAP way Baoquan He
2023-03-01 3:42 ` [PATCH v5 01/17] asm-generic/iomap.h: remove ARCH_HAS_IOREMAP_xx macros Baoquan He
2023-03-01 3:42 ` Baoquan He
2023-03-01 4:38 ` Edward Cree
2023-03-01 4:38 ` Edward Cree
2023-03-01 5:11 ` Matthew Wilcox
2023-03-01 5:11 ` Matthew Wilcox
2023-03-01 9:24 ` Baoquan He [this message]
2023-03-01 9:24 ` Baoquan He
2023-03-01 3:42 ` [PATCH v5 02/17] hexagon: mm: Convert to GENERIC_IOREMAP Baoquan He
2023-03-01 3:42 ` [PATCH v5 03/17] openrisc: mm: remove unneeded early ioremap code Baoquan He
2023-03-01 3:42 ` [PATCH v5 04/17] mm/ioremap: Define generic_ioremap_prot() and generic_iounmap() Baoquan He
2023-03-01 3:42 ` [PATCH v5 05/17] mm: ioremap: allow ARCH to have its own ioremap method definition Baoquan He
2023-03-01 3:42 ` [PATCH v5 06/17] mm/ioremap: add slab availability checking in ioremap_prot Baoquan He
2023-03-01 3:42 ` [PATCH v5 07/17] arc: mm: Convert to GENERIC_IOREMAP Baoquan He
2023-03-01 3:42 ` Baoquan He
2023-03-01 3:42 ` [PATCH v5 08/17] ia64: " Baoquan He
2023-03-01 3:42 ` Baoquan He
2023-03-01 3:42 ` [PATCH v5 09/17] openrisc: " Baoquan He
2023-03-01 3:42 ` [PATCH v5 10/17] s390: " Baoquan He
2023-03-01 3:42 ` [PATCH v5 11/17] sh: " Baoquan He
2023-03-01 3:42 ` [PATCH v5 12/17] xtensa: " Baoquan He
2023-03-01 3:42 ` [PATCH v5 13/17] parisc: " Baoquan He
2023-03-01 3:42 ` [PATCH v5 14/17] mm/ioremap: Consider IOREMAP space in generic ioremap Baoquan He
2023-03-01 3:42 ` [PATCH v5 15/17] powerpc: mm: Convert to GENERIC_IOREMAP Baoquan He
2023-03-01 3:42 ` [PATCH v5 16/17] arm64 : mm: add wrapper function ioremap_prot() Baoquan He
2023-03-01 3:42 ` [PATCH v5 17/17] mm: ioremap: remove unneeded ioremap_allowed and iounmap_allowed Baoquan He
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=Y/8Zyjfuypg3EiDd@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=David.Laight@aculab.com \
--cc=agordeev@linux.ibm.com \
--cc=arnd@arndb.de \
--cc=christophe.leroy@csgroup.eu \
--cc=ecree.xilinx@gmail.com \
--cc=habetsm.xilinx@gmail.com \
--cc=hch@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=schnelle@linux.ibm.com \
--cc=shorne@gmail.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.