[Top] [All Lists]

Re: [PATCH v2] MIPS: cavium-octeon: fix I/O space setup on non-PCI syste

To: Aaro Koskinen <>
Subject: Re: [PATCH v2] MIPS: cavium-octeon: fix I/O space setup on non-PCI systems
From: David Daney <>
Date: Mon, 22 Jul 2013 13:58:05 -0700
Cc: David Daney <>, Ralf Baechle <>, David Daney <>, Faidon Liambotis <>, <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
On 07/22/2013 01:39 PM, Aaro Koskinen wrote:
On Mon, Jul 22, 2013 at 01:08:51PM -0700, David Daney wrote:
On 07/22/2013 12:55 PM, Aaro Koskinen wrote:
Fix I/O space setup, so that on non-PCI systems using inb()/outb()
won't crash the system. Some drivers may try to probe I/O space and for
that purpose we can just allocate some normal memory initially. Drivers
trying to reserve a region will fail early as we set the size to 0. If
a real I/O space is present, the PCI/PCIe support code will re-adjust
the values accordingly.

Tested with EdgeRouter Lite by enabling CONFIG_SERIO_I8042 that caused
the originally reported crash.

Reported-by: Faidon Liambotis <>
Signed-off-by: Aaro Koskinen <>

        v2: Address the issues found from the first version of the patch

  arch/mips/cavium-octeon/setup.c | 28 ++++++++++++++++++++++++++++
  arch/mips/pci/pci-octeon.c      |  9 +++++----
  2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index 48b08eb..6775bd1 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -8,6 +8,7 @@
   *   written by Ralf Baechle <>
  #include <linux/compiler.h>
+#include <linux/vmalloc.h>
  #include <linux/init.h>
  #include <linux/kernel.h>
  #include <linux/console.h>
@@ -1139,3 +1140,30 @@ static int __init edac_devinit(void)
        return err;
+static void __initdata *octeon_dummy_iospace;
+static int __init octeon_no_pci_init(void)
+       /*
+        * Initially assume there is no PCI. The PCI/PCIe platform code will
+        * later re-initialize these to correct values if they are present.
+        */
+       octeon_dummy_iospace = vzalloc(IO_SPACE_LIMIT);
+       set_io_port_base((unsigned long)octeon_dummy_iospace);
+       ioport_resource.start = MAX_RESOURCE;
+       ioport_resource.end = 0;
+       return 0;

Do we have any guarantee that this will happen before the
arch/mips/pci/* arch_initcalls ?

Yes, it's guaranteed by the linking order ie. in which order the obj-y
stuff gets listed in mips/Makefile. Currently cavium-octeon/ is processed
before pci/.

Yes, I understand that. The problem is when we start to use things like GCC's LTO, where we effectively compile the entire kernel as a single file. Will this still work then? I would rather not screw around with it.

Can you test it by making it a core_initcall() instead? If that works you can add Acked-by: me.

David Daney

Quoting including/linux/init.h:

/* initcalls are now grouped by functionality into separate
  * subsections. Ordering inside the subsections is determined
  * by link order.


<Prev in Thread] Current Thread [Next in Thread>