Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: David Daney <ddaney.cavm@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	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:58:05 -0700	[thread overview]
Message-ID: <51ED9CDD.2090507@caviumnetworks.com> (raw)
In-Reply-To: <20130722203912.GA31864@blackmetal.musicnaut.iki.fi>

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 <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 ?
>
> 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.

Thanks,
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.
>
> A.
>

WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: David Daney <ddaney.cavm@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	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:58:05 -0700	[thread overview]
Message-ID: <51ED9CDD.2090507@caviumnetworks.com> (raw)
Message-ID: <20130722205805.eM2YYOP2A84_p-M84HluQgp4og8QkWWDbuSpHDB3DPA@z> (raw)
In-Reply-To: <20130722203912.GA31864@blackmetal.musicnaut.iki.fi>

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 <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 ?
>
> 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.

Thanks,
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.
>
> A.
>

  reply	other threads:[~2013-07-22 20:58 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
2013-07-22 20:39   ` Aaro Koskinen
2013-07-22 20:58     ` David Daney [this message]
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=51ED9CDD.2090507@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=david.daney@cavium.com \
    --cc=ddaney.cavm@gmail.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