From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Rob Herring <robh@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Stafford Horne <shorne@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Johannes Berg <johannes@sipsolutions.net>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-csky@vger.kernel.org,
linux-riscv <linux-riscv@lists.infradead.org>,
linux-um@lists.infradead.org, PCI <linux-pci@vger.kernel.org>,
"open list:GENERIC INCLUDE/ASM HEADER FILES"
<linux-arch@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] asm-generic: Add new pci.h and use it
Date: Fri, 22 Jul 2022 20:23:36 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.21.2207222006140.48997@angie.orcam.me.uk> (raw)
In-Reply-To: <CAL_JsqJHZEcnJi+UHQbYWVoy1okQjHSc9T377P1q8oOJnHBWFw@mail.gmail.com>
On Fri, 22 Jul 2022, Rob Herring wrote:
> > Maybe the right thing to do here is actually to make the default
> > definitions of these macros non-zero, or to add some sort of ARCH_
> > flavor of them and move that non-zero requirement closer to where it
> > comes from? From the look of it any port that uses the generic port I/O
> > functions and has 0 for these will be broken in the same way.
> >
> > That said, I'm not really a PCI guy so maybe Bjorn or Maciej has a
> > better idea?
>
> >From fu740:
> ranges = <0x81000000 0x0 0x60080000 0x0
> 0x60080000 0x0 0x10000>, /* I/O */
> <0x82000000 0x0 0x60090000 0x0
> 0x60090000 0x0 0xff70000>, /* mem */
> <0x82000000 0x0 0x70000000 0x0
> 0x70000000 0x0 0x1000000>, /* mem */
> <0xc3000000 0x20 0x00000000 0x20
> 0x00000000 0x20 0x00000000>; /* mem prefetchable */
>
> So again, how does one get a 0 address handed out when that's not even
> a valid region according to DT? Is there some legacy stuff that
> ignores the bridge windows?
It doesn't matter as <asm/pci.h> just sets it as a generic parameter for
the platform, reflecting the limitation of PCI core, which in the course
of the discussion referred was found rather infeasible to remove. The
FU740 does not decode to PCI at 0, but another RISC-V device could. And I
think that DT should faithfully describe hardware and not our software
limitations.
Mind that PCI has originated from the x86 world where decoding low 24-bit
memory space to ISA has been implied (implicitly decoded on PCI systems by
the southbridge) for areas not decoded to DRAM by the memory controller.
So the inability of our PCI core to handle MMIO at 0 did not matter at the
time it was introduced as the value of 0 would never be used for a memory
BAR.
Maciej
next prev parent reply other threads:[~2022-07-22 19:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220718004114.3925745-1-shorne@gmail.com>
2022-07-18 0:41 ` [PATCH v3 1/2] asm-generic: Remove pci.h copying remaining code to x86 Stafford Horne
2022-07-18 8:22 ` Geert Uytterhoeven
2022-07-19 12:02 ` Pierre Morel
2022-07-18 0:41 ` [PATCH v3 2/2] asm-generic: Add new pci.h and use it Stafford Horne
2022-07-19 15:58 ` Palmer Dabbelt
2022-07-21 22:05 ` Stafford Horne
2022-07-21 22:53 ` Palmer Dabbelt
2022-07-21 23:06 ` Rob Herring
2022-07-22 10:53 ` Arnd Bergmann
2022-07-22 15:27 ` Palmer Dabbelt
2022-07-22 16:36 ` Rob Herring
2022-07-22 19:23 ` Maciej W. Rozycki [this message]
2022-07-22 19:42 ` Rob Herring
2022-07-22 22:28 ` Maciej W. Rozycki
2022-07-22 19:55 ` Arnd Bergmann
2022-07-22 21:39 ` Jessica Clarke
2022-07-22 21:44 ` Rob Herring
2022-07-22 22:41 ` Maciej W. Rozycki
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=alpine.DEB.2.21.2207222006140.48997@angie.orcam.me.uk \
--to=macro@orcam.me.uk \
--cc=anton.ivanov@cambridgegreys.com \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=guoren@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-um@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=shorne@gmail.com \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).