lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Y/8Zyjfuypg3EiDd@MiWiFi-R3L-srv>
Date:   Wed, 1 Mar 2023 17:24:26 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Matthew Wilcox <willy@...radead.org>,
        Edward Cree <ecree.xilinx@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-mm@...ck.org, arnd@...db.de, christophe.leroy@...roup.eu,
        hch@...radead.org, agordeev@...ux.ibm.com,
        wangkefeng.wang@...wei.com, schnelle@...ux.ibm.com,
        David.Laight@...lab.com, shorne@...il.com,
        loongarch@...ts.linux.dev, linux-m68k@...ts.linux-m68k.org,
        linux-mips@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        x86@...nel.org, netdev@...r.kernel.org,
        Martin Habets <habetsm.xilinx@...il.com>
Subject: Re: [PATCH v5 01/17] asm-generic/iomap.h: remove ARCH_HAS_IOREMAP_xx
 macros

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ