[L] Change in coreboot[main]: arch/io.h: Add port I/O functions to other architectures

[Nico Huber (Code Review)]

Attention is currently required from: Alper Nebi Yasak, Arthur Heymans, Jianjun Wang, Ron Minnich, Shelley Chen, Yu-Ping Wu.

Nico Huber has posted comments on this change by Alper Nebi Yasak. ( https://review.coreboot.org/c/coreboot/+/80372?usp=email )

Change subject: arch/io.h: Add port I/O functions to other architectures
......................................................................

Patch Set 5:

(1 comment)

Patchset:

PS5:
> > Sorry, I have to admit I know basically nothing about PCI
>
> Honestly, me too

I can try to fill gaps, but the topic is a bit too big to explain it
all at once. I actually hope that it's all just legacy burden that
we could choose to ignore.

First let me repeat that I don't expect that we need this for actual
hardware. Requiring port IO seems uncommon for today's PCI endpoints.
And looking at implementations, the code looks sound, but the data
(devicetrees) seems incompatible because it breaks assumptions
usually made by software (coreboot/Linux), or doesn't provide port-IO
mappings at all. So I doubt it is widely tested, even with Linux. And
should devices show up that need it, it's still unlikely that we'll
see it in coreboot's drivers.

Some background about today's software design and capabilities:
On traditional PCI platforms (i.e. x86, maybe PPC too?), we have two
completely separate address spaces, memory (MMIO) and port IO (PIO).
The CPU knows how to access both of them. And because that's how the
first PCI platforms did it, firmware and OS expect everything to be
*identity mapped*. If one configures a PCI device to listen at MMIO
address 0xa5df000, the CPU sees this at 0xa5df000. Same for PIO (in
its own address space).

Another legacy thing: The original address width for PIO was 10 bits,
later 16 bits was implemented. PCI allows up to 32 bits, but few cared
to make software compatible with it and not all endpoints support it.
As MMIO prevailed, there is little use for it.

Then platforms came where the CPU didn't know PIO, but they had a
single PCI root, making a single memory mapping of the smaller PIO
space easy. Not identity mapped when crossing address spaces, because
one definitely wants to cover the 16-bit PIO range ;)

Other, modern platforms that adopt PCI don't have a single PCI root and
they tend to have things far more configurable. For instance, don't need
the identity mapping. But it seems people don't want to re-invent every-
thing, so they stick to it (cf. google/cherry/variants/dojo/overridetree.cb
for instance, not sure why it's in the devicetree).

I guess this is an important observation:
Even though the hardware and devicetree concepts support much more,
software still treats every physical PCI MMIO address as unique in the
whole system (same for port IO respectively in its own address space).

And because of the traditional constraints and because we like to keep
things simple, coreboot isn't prepared for any flexibility. I'd argue
that if we implement something, we should just use a single offset as
long as possible (could be in Kconfig). Even with multiple roots, if
they are configurable, we could stitch their ranges together and still
have a single offset.