Linux PCI subsystem development
 help / color / mirror / Atom feed
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
> 


  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