This patch adds required definitions to allow for PCI buses on OpenRISC.
This is being in the QEMU virt platform.
OpenRISC does not have IO ports so this defines PCI IO to be allowed in
any range. Keeping PIO_RESERVED defined as 0 allows OpenRISC to use
MMIO for all IO.
Also, since commit 66bcd06099bb ("parport_pc: Also enable driver for PCI
systems") all platforms that support PCI also need to support parallel
port. We add a generic header to support parallel port drivers.
Signed-off-by: Stafford Horne <[email protected]>
---
arch/openrisc/Kconfig | 7 ++++---
arch/openrisc/include/asm/Kbuild | 1 +
arch/openrisc/include/asm/io.h | 4 ++--
arch/openrisc/include/asm/pci.h | 36 ++++++++++++++++++++++++++++++++
4 files changed, 43 insertions(+), 5 deletions(-)
create mode 100644 arch/openrisc/include/asm/pci.h
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index e814df4c483c..327241988819 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -21,7 +21,9 @@ config OPENRISC
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
select GENERIC_IOMAP
+ select GENERIC_PCI_IOMAP
select GENERIC_CPU_DEVICES
+ select HAVE_PCI
select HAVE_UID16
select GENERIC_ATOMIC64
select GENERIC_CLOCKEVENTS_BROADCAST
@@ -32,6 +34,8 @@ config OPENRISC
select CPU_NO_EFFICIENT_FFS if !OPENRISC_HAVE_INST_FF1
select ARCH_USE_QUEUED_RWLOCKS
select OMPIC if SMP
+ select PCI_DOMAINS_GENERIC if PCI
+ select PCI_MSI if PCI
select ARCH_WANT_FRAME_POINTERS
select GENERIC_IRQ_MULTI_HANDLER
select MMU_GATHER_NO_RANGE if MMU
@@ -46,9 +50,6 @@ config MMU
config GENERIC_HWEIGHT
def_bool y
-config NO_IOPORT_MAP
- def_bool y
-
# For now, use generic checksum functions
#These can be reimplemented in assembly later if so inclined
config GENERIC_CSUM
diff --git a/arch/openrisc/include/asm/Kbuild b/arch/openrisc/include/asm/Kbuild
index 3386b9c1c073..c8c99b554ca4 100644
--- a/arch/openrisc/include/asm/Kbuild
+++ b/arch/openrisc/include/asm/Kbuild
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
generic-y += extable.h
generic-y += kvm_para.h
+generic-y += parport.h
generic-y += spinlock_types.h
generic-y += spinlock.h
generic-y += qrwlock_types.h
diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h
index c298061c70a7..1595aa69d96d 100644
--- a/arch/openrisc/include/asm/io.h
+++ b/arch/openrisc/include/asm/io.h
@@ -17,9 +17,9 @@
#include <linux/types.h>
/*
- * PCI: can we really do 0 here if we have no port IO?
+ * PCI: All address space can be used for IO
*/
-#define IO_SPACE_LIMIT 0
+#define IO_SPACE_LIMIT ~(0UL)
/* OpenRISC has no port IO */
#define HAVE_ARCH_PIO_SIZE 1
diff --git a/arch/openrisc/include/asm/pci.h b/arch/openrisc/include/asm/pci.h
new file mode 100644
index 000000000000..e0865d2f3f42
--- /dev/null
+++ b/arch/openrisc/include/asm/pci.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ASM_OPENRISC_PCI_H
+#define __ASM_OPENRISC_PCI_H
+
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/dma-mapping.h>
+
+#include <asm/io.h>
+
+#define PCIBIOS_MIN_IO 0
+#define PCIBIOS_MIN_MEM 0
+
+/* OpenRISC bootloaders do not initialize PCI bus */
+#define pcibios_assign_all_busses() 1
+
+#define ARCH_GENERIC_PCI_MMAP_RESOURCE 1
+
+extern int isa_dma_bridge_buggy;
+
+#ifdef CONFIG_PCI
+static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
+{
+ /* no legacy IRQs on or1k */
+ return -ENODEV;
+}
+
+static inline int pci_proc_domain(struct pci_bus *bus)
+{
+ /* always show the domain in /proc */
+ return 1;
+}
+#endif /* CONFIG_PCI */
+
+#endif /* __ASM_OPENRISC_PCI_H */
--
2.36.1
On Sat, Jul 9, 2022 at 11:15 PM Stafford Horne <[email protected]> wrote:
>
> This patch adds required definitions to allow for PCI buses on OpenRISC.
> This is being in the QEMU virt platform.
>
> OpenRISC does not have IO ports so this defines PCI IO to be allowed in
> any range. Keeping PIO_RESERVED defined as 0 allows OpenRISC to use
> MMIO for all IO.
>
> /*
> - * PCI: can we really do 0 here if we have no port IO?
> + * PCI: All address space can be used for IO
> */
> -#define IO_SPACE_LIMIT 0
> +#define IO_SPACE_LIMIT ~(0UL)
I think '0' is the correct limit here if you don't support PCI controllers
that can map their I/O ports into MMIO space. If you don't define
PCI_IOBASE to a meaningful value and set IO_SPACE_LIMIT as you
do here, every virtual address is treated as an I/O port, so accessing
a low port through /dev/ioport or a PCI driver results in an access to
a NULL pointer, which is either a userspace address or low kernel
memory, both of which are bad.
Most PCI controller are however able to map I/O ports into the
physical address space of the CPU, and in that case you can just
define an otherwise unused address as PCI_IOBASE and map the
ports there from the PCI host bridge driver.
Arnd
On Sun, Jul 10, 2022 at 05:54:22PM +0200, Arnd Bergmann wrote:
> On Sat, Jul 9, 2022 at 11:15 PM Stafford Horne <[email protected]> wrote:
> >
> > This patch adds required definitions to allow for PCI buses on OpenRISC.
> > This is being in the QEMU virt platform.
> >
> > OpenRISC does not have IO ports so this defines PCI IO to be allowed in
> > any range. Keeping PIO_RESERVED defined as 0 allows OpenRISC to use
> > MMIO for all IO.
>
> >
> > /*
> > - * PCI: can we really do 0 here if we have no port IO?
> > + * PCI: All address space can be used for IO
> > */
> > -#define IO_SPACE_LIMIT 0
> > +#define IO_SPACE_LIMIT ~(0UL)
>
> I think '0' is the correct limit here if you don't support PCI controllers
> that can map their I/O ports into MMIO space. If you don't define
> PCI_IOBASE to a meaningful value and set IO_SPACE_LIMIT as you
> do here, every virtual address is treated as an I/O port, so accessing
> a low port through /dev/ioport or a PCI driver results in an access to
> a NULL pointer, which is either a userspace address or low kernel
> memory, both of which are bad.
OK, I see, but I think IO_SPACE_LIMIT needs to be defined as something other
than 0. It is used to define kernel/resource.c's ioport_resource. For example
on risc-v they set it to 16MB.
I will setup a LIMIT smaller than 4GB and add a PCI_IOBASE.
> Most PCI controller are however able to map I/O ports into the
> physical address space of the CPU, and in that case you can just
> define an otherwise unused address as PCI_IOBASE and map the
> ports there from the PCI host bridge driver.
OK, understood, do you think this needs to be documented in a architecture
manual? Maybe it's fine for it to be linux specific.
-Stafford
On Sun, Jul 10, 2022 at 11:22 PM Stafford Horne <[email protected]> wrote:
> On Sun, Jul 10, 2022 at 05:54:22PM +0200, Arnd Bergmann wrote:
>
> OK, I see, but I think IO_SPACE_LIMIT needs to be defined as something other
> than 0. It is used to define kernel/resource.c's ioport_resource.
I think the kernel/resource.c one is fine, it just means that any attempt to
register an I/O port resource below the 0-length root resource will fail, which
is what you need when inb/outb cannot be used.
> For example on risc-v they set it to 16MB.
>
> I will setup a LIMIT smaller than 4GB and add a PCI_IOBASE.
Do you support multiple PCI domains? Usually you want at most 64KB
per domain, as that is the traditional limit and what the normal
pci_remap_iospace() will assign to a domain. The 16MB limit for riscv
is way more than what one may need on a 32-bit machine, since that
is enough for 4096 domains even with the largest possible I/O space,
and each domain has up to 65536 PCI functions attached to it.
> > Most PCI controller are however able to map I/O ports into the
> > physical address space of the CPU, and in that case you can just
> > define an otherwise unused address as PCI_IOBASE and map the
> > ports there from the PCI host bridge driver.
>
> OK, understood, do you think this needs to be documented in a architecture
> manual? Maybe it's fine for it to be linux specific.
Of course it's Linux specific, but it's also architecture specific since
there are different ways of making I/O space available: Generally you
can leave it out completely, unless you have to support devices from
two decades ago, some architectures that existed back then have custom
instructions, some hardcode part of the virtual address space to access
MMIO registers at a fixed location, some rely on an indirect method
going through a particular MMIO register to access all I/O space, and
some use a per hostbridge window that gets mapped using
pci_remap_iospace().
Do you have a driver for your host bridge available somewhere?
It should be clear from that driver which method you need.
Arnd