From: Philipp Stanner <pstanner@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>,
Bjorn Helgaas <bhelgaas@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Jakub Kicinski <kuba@kernel.org>,
Dave Jiang <dave.jiang@intel.com>,
Uladzislau Koshchanka <koshchanka@gmail.com>,
Neil Brown <neilb@suse.de>,
Niklas Schnelle <schnelle@linux.ibm.com>,
John Sanpe <sanpeqf@gmail.com>,
Kent Overstreet <kent.overstreet@gmail.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Kees Cook <keescook@chromium.org>,
David Gow <davidgow@google.com>,
Yury Norov <yury.norov@gmail.com>,
"wuqiang.matt" <wuqiang.matt@bytedance.com>,
Jason Baron <jbaron@akamai.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Ben Dooks <ben.dooks@codethink.co.uk>,
Danilo Krummrich <dakr@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Linux-Arch <linux-arch@vger.kernel.org>,
Arnd Bergmann <arnd@kernel.org>,
pstanner@redhat.com
Subject: Re: [PATCH v2 4/4] lib, pci: unify generic pci_iounmap()
Date: Fri, 01 Dec 2023 22:56:05 +0100 [thread overview]
Message-ID: <c902e7e690dcdf57c2e8402e083d27ce84aee21b.camel@redhat.com> (raw)
In-Reply-To: <330df2f8-3796-4f74-8856-06ae1e46ec9b@app.fastmail.com>
On Fri, 2023-12-01 at 22:32 +0100, Arnd Bergmann wrote:
> On Fri, Dec 1, 2023, at 20:37, Philipp Stanner wrote:
> > On Fri, 2023-12-01 at 16:26 +0100, Arnd Bergmann wrote:
> > >
> > > static inline bool struct iomem_is_ioport(void __iomem *p)
> > > {
> > > #ifdef CONFIG_HAS_IOPORT
> > > uintptr_t start = (uintptr_t) PCI_IOBASE;
> > > uintptr_t addr = (uintptr_t) p;
> > >
> > > if (addr >= start && addr < start + IO_SPACE_LIMIT)
> > > return true;
> > > #endif
> > > return false;
> > > }
> > >
> > > > +#else /* CONFIG_GENERIC_IOMAP. Version from lib/iomap.c will
> > > > be
> > > > used.
> > > > */
> > > > +bool iomem_is_ioport(void __iomem *addr);
> > > > +#define ARCH_WANTS_GENERIC_IOMEM_IS_IOPORT
> > >
> > > I'm not sure what this macro is for, since it appears to
> > > do the opposite of what its name suggests: rather than
> > > provide the generic version of iomem_is_ioport(), it
> > > skips that and provides a custom one to go with lib/iomap.c
> >
> > Hmmm well now it's getting tricky.
> >
> > This else-branch is the one where CONFIG_GENERIC_IOMAP is actually
> > set.
> >
> > I think we're running into the "generic not being generic now that
> > IA64
> > has died" problem you were hinting at.
> >
> > If we build for x86 and have CONFIG_GENERIC set, only then do we
> > want
> > iomem_is_ioport() from lib/iomap.c. So the macro serves avoiding a
> > collision between symbols. Because lib/iomap.c might be compiled
> > even
> > if someone else already has defined iomem_is_ioport().
> > I also don't like it, but it was the least bad solution I could
> > come up
> > with
> > Suggestions?
>
> The best I can think of is to move the lib/iomap.c version
> of iomem_is_ioport() to include/asm-generic/iomap.h with
> an #ifndef iomem_is_ioport / #define iomem_is_ioport
> check around it. This file is only included on parisc, alpha,
> sh and when CONFIG_GENERIC_IOMAP is set.
My implementation from lib/iomap.c basically just throws away the
IO_COND macro and does the checks manually:
#if defined(ARCH_WANTS_GENERIC_IOMEM_IS_IOPORT)
bool iomem_is_ioport(void __iomem *addr)
{
unsigned long port = (unsigned long __force)addr;
if (port > PIO_OFFSET && port < PIO_RESERVED)
return true;
return false;
}
#endif /* ARCH_WANTS_GENERIC_IOMEM_IS_IOPORT */
So we'd also need PIO_OFFSET and PIO_RESERVED, which are not present in
asm-generic/iomap.h.
Sure, we could move them there or into a common header. But I'm not
sure if that is wise, meaning: is it really better than the ugly
WANTS_GENERIC_IOMEM... macro?
Our entire goal in this series is, after all, to simplify the
implementation.
P.
>
> The default version in asm-generic/io.h then just needs
> one more #ifdef iomem_is_ioport check around it.
>
> Arnd
>
next prev parent reply other threads:[~2023-12-01 21:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 12:16 [PATCH v2 0/4] Regather scattered PCI-Code Philipp Stanner
2023-12-01 12:16 ` [PATCH v2 1/4] lib: move pci_iomap.c to drivers/pci/ Philipp Stanner
2023-12-01 14:43 ` Arnd Bergmann
2023-12-01 18:56 ` Philipp Stanner
2023-12-01 22:17 ` Arnd Bergmann
2023-12-01 12:16 ` [PATCH v2 2/4] lib: move pci-specific devres code " Philipp Stanner
2023-12-01 14:44 ` Arnd Bergmann
2023-12-01 19:00 ` Philipp Stanner
2023-12-01 22:31 ` Arnd Bergmann
2023-12-01 12:16 ` [PATCH v2 3/4] pci: move devres code from pci.c to devres.c Philipp Stanner
2023-12-01 12:16 ` [PATCH v2 4/4] lib, pci: unify generic pci_iounmap() Philipp Stanner
2023-12-01 15:26 ` Arnd Bergmann
2023-12-01 19:37 ` Philipp Stanner
2023-12-01 21:32 ` Arnd Bergmann
2023-12-01 21:56 ` Philipp Stanner [this message]
2023-12-01 21:59 ` Arnd Bergmann
2023-12-01 16:27 ` [PATCH v2 0/4] Regather scattered PCI-Code Arnd Bergmann
2023-12-01 19:09 ` Philipp Stanner
2023-12-01 22:17 ` Arnd Bergmann
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=c902e7e690dcdf57c2e8402e083d27ce84aee21b.camel@redhat.com \
--to=pstanner@redhat.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=ben.dooks@codethink.co.uk \
--cc=bhelgaas@google.com \
--cc=dakr@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=davidgow@google.com \
--cc=jbaron@akamai.com \
--cc=keescook@chromium.org \
--cc=kent.overstreet@gmail.com \
--cc=koshchanka@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=neilb@suse.de \
--cc=sanpeqf@gmail.com \
--cc=schnelle@linux.ibm.com \
--cc=wangkefeng.wang@huawei.com \
--cc=wuqiang.matt@bytedance.com \
--cc=yury.norov@gmail.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