All of lore.kernel.org
 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,

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.