Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Yang,Wei" <Wei.Yang@windriver.com>
To: <Wei.Yang@windriver.com>, <wei.yang@windriver.com>,
	<david.daney@cavium.com>, <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>, <andreas.herrmann@caviumnetworks.com>
Subject: Re: [PATCH V2] mips/octeon_3xxx: Fix a warning on octeon_3xxx
Date: Wed, 19 Mar 2014 17:51:41 +0800	[thread overview]
Message-ID: <532968AD.4010402@windriver.com> (raw)
In-Reply-To: <1395118084-24018-1-git-send-email-Wei.Yang@windriver.com>

ping.

Wei
On 03/18/2014 12:48 PM, Wei.Yang@windriver.com wrote:
> From: Yang Wei <Wei.Yang@windriver.com>
>
> Since the xlate of interrupts property of GPIO on octeon 3xxx
> does not success, so the following warning would be triggerred.
>
> WARNING: CPU: 1 PID: 1 at drivers/of/platform.c:173 of_device_alloc+0x294/0x2a0()
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc6- #11
> Stack : ffffffff81a20000 0000000000000001 0000000000000004 ffffffff81b50000
>        0000000000000001 0000000000000000 0000000000000000 ffffffff8119e878
>        ffffffff81a20000 ffffffff8119ee98 0000000000000000 0000000000000000
>        ffffffff81b30000 ffffffff81b20000 ffffffff81932900 ffffffff81a11077
>        ffffffff81b27a08 800000041f8704a8 0000000000000001 0000000000000001
>        0000000000000000 800000041fbf7438 0000000000000001 ffffffff81800d90
>        800000041f85fa68 ffffffff8114a60c 0000000000000000 ffffffff811a0838
>        800000041f870000 800000041f85f980 0000000000000001 ffffffff81805080
>        0000000000000000 0000000000000000 0000000000000000 0000000000000000
>        0000000000000000 ffffffff81122620 0000000000000000 0000000000000000
>        ...
> Call Trace:
> [<ffffffff81122620>] show_stack+0xc0/0xe0
> [<ffffffff81805080>] dump_stack+0x8c/0xe0
> [<ffffffff8114a7ac>] warn_slowpath_common+0x94/0xc8
> [<ffffffff81693b1c>] of_device_alloc+0x294/0x2a0
> [<ffffffff81693b74>] of_platform_device_create_pdata+0x4c/0xf0
> [<ffffffff81693d58>] of_platform_bus_create+0x128/0x1a8
> [<ffffffff81693da0>] of_platform_bus_create+0x170/0x1a8
> [<ffffffff81693e8c>] of_platform_bus_probe+0xb4/0x110
> [<ffffffff81100598>] do_one_initcall+0xe8/0x130
> [<ffffffff81a92c5c>] kernel_init_freeable+0x1d4/0x2bc
> [<ffffffff817fe140>] kernel_init+0x20/0x118
> [<ffffffff8111d024>] ret_from_kernel_thread+0x14/0x1c
>
> Signed-off-by: Yang Wei <Wei.Yang@windriver.com>
> ---
>
> Changes:
>   
> In v2:
> Hi David,
>
> According to your suggestion, I modify octeon-irq.c so that it doesn't try to reserve these numbers to fix this issue in v2.
> How about is it?:-)
>
> Thanks
> Wei
>
>
>   arch/mips/cavium-octeon/octeon-irq.c |   25 +++++++++++++++----------
>   1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/arch/mips/cavium-octeon/octeon-irq.c b/arch/mips/cavium-octeon/octeon-irq.c
> index 25fbfae..31c76b1 100644
> --- a/arch/mips/cavium-octeon/octeon-irq.c
> +++ b/arch/mips/cavium-octeon/octeon-irq.c
> @@ -975,10 +975,6 @@ static int octeon_irq_ciu_xlat(struct irq_domain *d,
>   	if (ciu > 1 || bit > 63)
>   		return -EINVAL;
>   
> -	/* These are the GPIO lines */
> -	if (ciu == 0 && bit >= 16 && bit < 32)
> -		return -EINVAL;
> -
>   	*out_hwirq = (ciu << 6) | bit;
>   	*out_type = 0;
>   
> @@ -1010,6 +1006,13 @@ static int octeon_irq_ciu_map(struct irq_domain *d,
>   	if (line > 1 || octeon_irq_ciu_to_irq[line][bit] != 0)
>   		return -EINVAL;
>   
> +	/*
> +	 * If the irq is reserved for GPIO, we set virq to 0 so
> +	 * that GPIO would be able to map it.
> +	 */
> +	if (line == 0 && bit >= 16 && bit <32)
> +		virq = 0;
> +
>   	if (octeon_irq_ciu_is_edge(line, bit))
>   		octeon_irq_set_ciu_mapping(virq, line, bit, 0,
>   					   octeon_irq_ciu_chip,
> @@ -1525,10 +1528,6 @@ static int octeon_irq_ciu2_xlat(struct irq_domain *d,
>   	ciu = intspec[0];
>   	bit = intspec[1];
>   
> -	/* Line 7  are the GPIO lines */
> -	if (ciu > 6 || bit > 63)
> -		return -EINVAL;
> -
>   	*out_hwirq = (ciu << 6) | bit;
>   	*out_type = 0;
>   
> @@ -1570,10 +1569,16 @@ static int octeon_irq_ciu2_map(struct irq_domain *d,
>   	if (!octeon_irq_virq_in_range(virq))
>   		return -EINVAL;
>   
> -	/* Line 7  are the GPIO lines */
> -	if (line > 6 || octeon_irq_ciu_to_irq[line][bit] != 0)
> +	if (octeon_irq_ciu_to_irq[line][bit] != 0)
>   		return -EINVAL;
>   
> +	/*
> +	 * Line 7 are the GPIO lines, we set virq to 0 so
> +	 * that GPIO would be able to map it
> +	 */
> +	if (line > 6 || bit > 63)
> +		virq = 0;
> +
>   	if (octeon_irq_ciu2_is_edge(line, bit))
>   		octeon_irq_set_ciu_mapping(virq, line, bit, 0,
>   					   &octeon_irq_chip_ciu2,

WARNING: multiple messages have this Message-ID (diff)
From: "Yang,Wei" <Wei.Yang@windriver.com>
To: Wei.Yang@windriver.com, wei.yang@windriver.com,
	david.daney@cavium.com, ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, andreas.herrmann@caviumnetworks.com
Subject: Re: [PATCH V2] mips/octeon_3xxx: Fix a warning on octeon_3xxx
Date: Wed, 19 Mar 2014 17:51:41 +0800	[thread overview]
Message-ID: <532968AD.4010402@windriver.com> (raw)
Message-ID: <20140319095141.Q4sMP2Ne5pr2mNQqN0gSCZ2-F1FRZeZJ-E1QT7vnKPg@z> (raw)
In-Reply-To: <1395118084-24018-1-git-send-email-Wei.Yang@windriver.com>

ping.

Wei
On 03/18/2014 12:48 PM, Wei.Yang@windriver.com wrote:
> From: Yang Wei <Wei.Yang@windriver.com>
>
> Since the xlate of interrupts property of GPIO on octeon 3xxx
> does not success, so the following warning would be triggerred.
>
> WARNING: CPU: 1 PID: 1 at drivers/of/platform.c:173 of_device_alloc+0x294/0x2a0()
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc6- #11
> Stack : ffffffff81a20000 0000000000000001 0000000000000004 ffffffff81b50000
>        0000000000000001 0000000000000000 0000000000000000 ffffffff8119e878
>        ffffffff81a20000 ffffffff8119ee98 0000000000000000 0000000000000000
>        ffffffff81b30000 ffffffff81b20000 ffffffff81932900 ffffffff81a11077
>        ffffffff81b27a08 800000041f8704a8 0000000000000001 0000000000000001
>        0000000000000000 800000041fbf7438 0000000000000001 ffffffff81800d90
>        800000041f85fa68 ffffffff8114a60c 0000000000000000 ffffffff811a0838
>        800000041f870000 800000041f85f980 0000000000000001 ffffffff81805080
>        0000000000000000 0000000000000000 0000000000000000 0000000000000000
>        0000000000000000 ffffffff81122620 0000000000000000 0000000000000000
>        ...
> Call Trace:
> [<ffffffff81122620>] show_stack+0xc0/0xe0
> [<ffffffff81805080>] dump_stack+0x8c/0xe0
> [<ffffffff8114a7ac>] warn_slowpath_common+0x94/0xc8
> [<ffffffff81693b1c>] of_device_alloc+0x294/0x2a0
> [<ffffffff81693b74>] of_platform_device_create_pdata+0x4c/0xf0
> [<ffffffff81693d58>] of_platform_bus_create+0x128/0x1a8
> [<ffffffff81693da0>] of_platform_bus_create+0x170/0x1a8
> [<ffffffff81693e8c>] of_platform_bus_probe+0xb4/0x110
> [<ffffffff81100598>] do_one_initcall+0xe8/0x130
> [<ffffffff81a92c5c>] kernel_init_freeable+0x1d4/0x2bc
> [<ffffffff817fe140>] kernel_init+0x20/0x118
> [<ffffffff8111d024>] ret_from_kernel_thread+0x14/0x1c
>
> Signed-off-by: Yang Wei <Wei.Yang@windriver.com>
> ---
>
> Changes:
>   
> In v2:
> Hi David,
>
> According to your suggestion, I modify octeon-irq.c so that it doesn't try to reserve these numbers to fix this issue in v2.
> How about is it?:-)
>
> Thanks
> Wei
>
>
>   arch/mips/cavium-octeon/octeon-irq.c |   25 +++++++++++++++----------
>   1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/arch/mips/cavium-octeon/octeon-irq.c b/arch/mips/cavium-octeon/octeon-irq.c
> index 25fbfae..31c76b1 100644
> --- a/arch/mips/cavium-octeon/octeon-irq.c
> +++ b/arch/mips/cavium-octeon/octeon-irq.c
> @@ -975,10 +975,6 @@ static int octeon_irq_ciu_xlat(struct irq_domain *d,
>   	if (ciu > 1 || bit > 63)
>   		return -EINVAL;
>   
> -	/* These are the GPIO lines */
> -	if (ciu == 0 && bit >= 16 && bit < 32)
> -		return -EINVAL;
> -
>   	*out_hwirq = (ciu << 6) | bit;
>   	*out_type = 0;
>   
> @@ -1010,6 +1006,13 @@ static int octeon_irq_ciu_map(struct irq_domain *d,
>   	if (line > 1 || octeon_irq_ciu_to_irq[line][bit] != 0)
>   		return -EINVAL;
>   
> +	/*
> +	 * If the irq is reserved for GPIO, we set virq to 0 so
> +	 * that GPIO would be able to map it.
> +	 */
> +	if (line == 0 && bit >= 16 && bit <32)
> +		virq = 0;
> +
>   	if (octeon_irq_ciu_is_edge(line, bit))
>   		octeon_irq_set_ciu_mapping(virq, line, bit, 0,
>   					   octeon_irq_ciu_chip,
> @@ -1525,10 +1528,6 @@ static int octeon_irq_ciu2_xlat(struct irq_domain *d,
>   	ciu = intspec[0];
>   	bit = intspec[1];
>   
> -	/* Line 7  are the GPIO lines */
> -	if (ciu > 6 || bit > 63)
> -		return -EINVAL;
> -
>   	*out_hwirq = (ciu << 6) | bit;
>   	*out_type = 0;
>   
> @@ -1570,10 +1569,16 @@ static int octeon_irq_ciu2_map(struct irq_domain *d,
>   	if (!octeon_irq_virq_in_range(virq))
>   		return -EINVAL;
>   
> -	/* Line 7  are the GPIO lines */
> -	if (line > 6 || octeon_irq_ciu_to_irq[line][bit] != 0)
> +	if (octeon_irq_ciu_to_irq[line][bit] != 0)
>   		return -EINVAL;
>   
> +	/*
> +	 * Line 7 are the GPIO lines, we set virq to 0 so
> +	 * that GPIO would be able to map it
> +	 */
> +	if (line > 6 || bit > 63)
> +		virq = 0;
> +
>   	if (octeon_irq_ciu2_is_edge(line, bit))
>   		octeon_irq_set_ciu_mapping(virq, line, bit, 0,
>   					   &octeon_irq_chip_ciu2,

  parent reply	other threads:[~2014-03-19  9:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18  4:48 [PATCH V2] mips/octeon_3xxx: Fix a warning on octeon_3xxx Wei.Yang
2014-03-18  4:48 ` Wei.Yang
2014-03-19  9:51 ` Yang,Wei [this message]
2014-03-19  9:51   ` Yang,Wei
2014-03-19 16:20   ` Andreas Herrmann
2014-03-19 16:20     ` Andreas Herrmann
2014-03-19 18:34     ` David Daney
2014-03-19 18:34       ` David Daney
2014-03-19 22:03       ` [PATCH] MIPS: octeon: Fix warning in of_device_alloc on cn3xxx Andreas Herrmann
2014-03-19 22:03         ` Andreas Herrmann
2014-03-19 22:12         ` David Daney
2014-03-19 22:12           ` David Daney
2014-03-19 23:11         ` Aaro Koskinen
2014-03-20  0:53         ` Yang,Wei
2014-03-20  0:53           ` Yang,Wei

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=532968AD.4010402@windriver.com \
    --to=wei.yang@windriver.com \
    --cc=andreas.herrmann@caviumnetworks.com \
    --cc=david.daney@cavium.com \
    --cc=linux-mips@linux-mips.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