From: David Daney <ddaney.cavm@gmail.com>
To: Aaro Koskinen <aaro.koskinen@iki.fi>, Ralf Baechle <ralf@linux-mips.org>
Cc: David Daney <david.daney@cavium.com>,
Faidon Liambotis <paravoid@debian.org>,
linux-mips@linux-mips.org
Subject: Re: [PATCH v2] MIPS: cavium-octeon: fix I/O space setup on non-PCI systems
Date: Mon, 22 Jul 2013 13:08:51 -0700 [thread overview]
Message-ID: <51ED9153.4080904@gmail.com> (raw)
In-Reply-To: <1374522901-30290-1-git-send-email-aaro.koskinen@iki.fi>
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 <paravoid@debian.org>
> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> ---
>
> v2: Address the issues found from the first version of the patch
> (http://marc.info/?t=137434204000002&r=1&w=2).
>
> 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 <ralf@linux-mips.org>
> */
> #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;
> }
> device_initcall(edac_devinit);
> +
> +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;
> +}
> +arch_initcall(octeon_no_pci_init);
> +
Do we have any guarantee that this will happen before the
arch/mips/pci/* arch_initcalls ?
If not, can we move this to a core_iitcall?
David Daney
> +static int __init octeon_no_pci_release(void)
> +{
> + /*
> + * Release the allocated memory if a real IO space is there.
> + */
> + if ((unsigned long)octeon_dummy_iospace != mips_io_port_base)
> + vfree(octeon_dummy_iospace);
> + return 0;
> +}
> +late_initcall(octeon_no_pci_release);
> diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
> index 95c2ea8..59cccd9 100644
> --- a/arch/mips/pci/pci-octeon.c
> +++ b/arch/mips/pci/pci-octeon.c
> @@ -586,15 +586,16 @@ static int __init octeon_pci_setup(void)
> else
> octeon_dma_bar_type = OCTEON_DMA_BAR_TYPE_BIG;
>
> - /* PCI I/O and PCI MEM values */
> - set_io_port_base(OCTEON_PCI_IOSPACE_BASE);
> - ioport_resource.start = 0;
> - ioport_resource.end = OCTEON_PCI_IOSPACE_SIZE - 1;
> if (!octeon_is_pci_host()) {
> pr_notice("Not in host mode, PCI Controller not initialized\n");
> return 0;
> }
>
> + /* PCI I/O and PCI MEM values */
> + set_io_port_base(OCTEON_PCI_IOSPACE_BASE);
> + ioport_resource.start = 0;
> + ioport_resource.end = OCTEON_PCI_IOSPACE_SIZE - 1;
> +
> pr_notice("%s Octeon big bar support\n",
> (octeon_dma_bar_type ==
> OCTEON_DMA_BAR_TYPE_BIG) ? "Enabling" : "Disabling");
>
next prev parent reply other threads:[~2013-07-22 20:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-22 19:55 [PATCH v2] MIPS: cavium-octeon: fix I/O space setup on non-PCI systems Aaro Koskinen
2013-07-22 20:08 ` David Daney [this message]
2013-07-22 20:39 ` Aaro Koskinen
2013-07-22 20:58 ` David Daney
2013-07-22 20:58 ` David Daney
2013-07-22 22:26 ` Aaro Koskinen
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=51ED9153.4080904@gmail.com \
--to=ddaney.cavm@gmail.com \
--cc=aaro.koskinen@iki.fi \
--cc=david.daney@cavium.com \
--cc=linux-mips@linux-mips.org \
--cc=paravoid@debian.org \
--cc=ralf@linux-mips.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