From: "Arnd Bergmann" <arnd@arndb.de>
To: "Philipp Stanner" <pstanner@redhat.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Hanjun Guo" <guohanjun@huawei.com>, "Neil Brown" <neilb@suse.de>,
"Kent Overstreet" <kent.overstreet@gmail.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Niklas Schnelle" <schnelle@linux.ibm.com>,
"Uladzislau Koshchanka" <koshchanka@gmail.com>,
"John Sanpe" <sanpeqf@gmail.com>,
"Dave Jiang" <dave.jiang@intel.com>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Kees Cook" <keescook@chromium.org>,
"David Gow" <davidgow@google.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"wuqiang.matt" <wuqiang.matt@bytedance.com>,
"Yury Norov" <yury.norov@gmail.com>,
"Jason Baron" <jbaron@akamai.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"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>,
stable@vger.kernel.org, "Arnd Bergmann" <arnd@kernel.org>
Subject: Re: [PATCH v3 5/5] lib, pci: unify generic pci_iounmap()
Date: Mon, 04 Dec 2023 15:29:07 +0100 [thread overview]
Message-ID: <6d6918ac-a310-45d2-b5fe-c70595918b80@app.fastmail.com> (raw)
In-Reply-To: <e5d53e44709f7da1ba4b8f8a4687efcffdd6addb.camel@redhat.com>
On Mon, Dec 4, 2023, at 15:09, Philipp Stanner wrote:
> On Mon, 2023-12-04 at 14:50 +0100, Arnd Bergmann wrote:
>> On Mon, Dec 4, 2023, at 14:39, Philipp Stanner wrote:
>> > On Mon, 2023-12-04 at 13:38 +0100, Philipp Stanner wrote:
>
> Ok, makes sense.
>
> But should we then adjust iomem_is_ioport() in asm-generic/io.h, as
> well, so that it matches IO_COND()'s behavior?
>
> It currently does this:
>
> uintptr_t start = (uintptr_t)PCI_IOBASE;
> uintptr_t addr = (uintptr_t)addr_raw;
>
> if (addr >= start && addr < start + IO_SPACE_LIMIT)
> return true;
>
> and if the architecture does not set PCI_IOBASE, then it's set per
> default to 0, as well.
>
> So we have two inconsistent definitons
No, I would also keep the logic here, since it makes more sense
and the inconsistency is only for the corner case that doesn't
hit in practice.
The PCI_IOBASE==0 case should never happen here, as that doesn't
work with the generic inb(). I think the only target left that
has I/O ports but doesn't set PCI_IOBASE at all is sparc, but
that is special in a number of ways.
Arnd
next prev parent reply other threads:[~2023-12-04 14:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 12:38 [PATCH v3 0/5] Regather scattered PCI-Code Philipp Stanner
2023-12-04 12:38 ` [PATCH v3 1/5] lib/pci_iomap.c: fix cleanup bugs in pci_iounmap() Philipp Stanner
2023-12-04 13:35 ` Arnd Bergmann
2023-12-04 12:38 ` [PATCH v3 2/5] lib: move pci_iomap.c to drivers/pci/ Philipp Stanner
2023-12-04 12:39 ` kernel test robot
2023-12-04 13:37 ` Arnd Bergmann
2023-12-04 12:38 ` [PATCH v3 3/5] lib: move pci-specific devres code " Philipp Stanner
2023-12-04 12:38 ` [PATCH v3 4/5] pci: move devres code from pci.c to devres.c Philipp Stanner
2023-12-04 12:38 ` [PATCH v3 5/5] lib, pci: unify generic pci_iounmap() Philipp Stanner
2023-12-04 13:39 ` Philipp Stanner
2023-12-04 13:50 ` Arnd Bergmann
2023-12-04 14:09 ` Philipp Stanner
2023-12-04 14:29 ` Arnd Bergmann [this message]
2023-12-04 13:53 ` Arnd Bergmann
2023-12-05 10:44 ` kernel test robot
2023-12-05 14:34 ` Philipp Stanner
2023-12-05 14:43 ` 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=6d6918ac-a310-45d2-b5fe-c70595918b80@app.fastmail.com \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--cc=arnd@kernel.org \
--cc=ben.dooks@codethink.co.uk \
--cc=bhelgaas@google.com \
--cc=dakr@redhat.com \
--cc=dave.jiang@intel.com \
--cc=davidgow@google.com \
--cc=guohanjun@huawei.com \
--cc=herbert@gondor.apana.org.au \
--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=pstanner@redhat.com \
--cc=sanpeqf@gmail.com \
--cc=schnelle@linux.ibm.com \
--cc=skhan@linuxfoundation.org \
--cc=stable@vger.kernel.org \
--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 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.