Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1315799 > unrolled thread

[REGRESSION] gpio: pxa: change initcall level second attempt

Started byMarcel Ziswiler <marcel@ziswiler.com>
First post2016-01-24 02:20 +0100
Last post2016-01-27 01:10 +0100
Articles 4 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [REGRESSION] gpio: pxa: change initcall level second attempt Marcel Ziswiler <marcel@ziswiler.com> - 2016-01-24 02:20 +0100
    Re: [REGRESSION] gpio: pxa: change initcall level second attempt Robert Jarzmik <robert.jarzmik@free.fr> - 2016-01-25 15:30 +0100
      Re: [REGRESSION] gpio: pxa: change initcall level second attempt Robert Jarzmik <robert.jarzmik@free.fr> - 2016-01-26 21:50 +0100
        Re: [REGRESSION] gpio: pxa: change initcall level second attempt Marcel Ziswiler <marcel@ziswiler.com> - 2016-01-27 01:10 +0100

#1315799 — [REGRESSION] gpio: pxa: change initcall level second attempt

FromMarcel Ziswiler <marcel@ziswiler.com>
Date2016-01-24 02:20 +0100
Subject[REGRESSION] gpio: pxa: change initcall level second attempt
Message-ID<qUhvr-5HJ-1@gated-at.bofh.it>
Hi Robert

I tried latest next-20160122 on Colibri PXA270 with a previously
working device tree and got the following DM9000 Ethernet driver issue:

[    1.062495] dm9000 8000000.ethernet: insufficient resources
[    1.068439] dm9000 8000000.ethernet: not found (-2).
[    1.073451] dm9000: probe of 8000000.ethernet failed with error -2

Digging deeper I debugged it to a missing interrupt ressource. A
subsequent git bisect blamed your patch changing the initcall level and
indeed just reverting that made it all work again.

I then also noticed the following message upon boot in the failing case
which is probably related:

[    0.175995] irq: no irq domain found for /pxabus/gpio@40e00000 !

Have you seen this as well or do you know how exactly that should be
worked around?

Cheers

Marcel

[toc] | [next] | [standalone]


#1316748

FromRobert Jarzmik <robert.jarzmik@free.fr>
Date2016-01-25 15:30 +0100
Message-ID<qUQjv-5hx-5@gated-at.bofh.it>
In reply to#1315799
Marcel Ziswiler <marcel@ziswiler.com> writes:

> Hi Robert
>
> I tried latest next-20160122 on Colibri PXA270 with a previously
> working device tree and got the following DM9000 Ethernet driver issue:
>
> [    1.062495] dm9000 8000000.ethernet: insufficient resources
> [    1.068439] dm9000 8000000.ethernet: not found (-2).
> [    1.073451] dm9000: probe of 8000000.ethernet failed with error -2
>
> Digging deeper I debugged it to a missing interrupt ressource. A
> subsequent git bisect blamed your patch changing the initcall level and
> indeed just reverting that made it all work again.
>
> I then also noticed the following message upon boot in the failing case
> which is probably related:
>
> [    0.175995] irq: no irq domain found for /pxabus/gpio@40e00000 !
>
> Have you seen this as well or do you know how exactly that should be
> worked around?
Hi Marcel,

I haven't seen that before on my devicetree boards, I will try this evening on
top of next-20160125.

Could you activate the debug logs in drivers/of/irq.c please, and send me
privately your boot dmesg ? And I'd like to see your board .dts file and your
.config also, to compare with mine for the mioa701.

I think in your dm9000 case we have this callstack :
 - of_irq_get()
     of_irq_parse_one() => fails, for an unknown reason to me
                        => I would have expected it return 0
                        => the following irq_find_host() would return
                           -EPROBE_DEFER, that's what I'd expect
     irq_create_of_mapping()
       irq_create_fwspec_mapping()
         => error message

What is probable is that gpio-pxa was not probed yet, and this triggers the
error. What I don't understand is why you don't end up with -EPROBE_DEFER,
that's why I'd like to have your logs.

Cheers.

-- 
Robert

[toc] | [prev] | [next] | [standalone]


#1318350

FromRobert Jarzmik <robert.jarzmik@free.fr>
Date2016-01-26 21:50 +0100
Message-ID<qViIN-1ad-3@gated-at.bofh.it>
In reply to#1316748
Robert Jarzmik <robert.jarzmik@free.fr> writes:

>> Have you seen this as well or do you know how exactly that should be
>> worked around?
> Hi Marcel,
>
> I haven't seen that before on my devicetree boards, I will try this evening on
> top of next-20160125.
>
> Could you activate the debug logs in drivers/of/irq.c please, and send me
> privately your boot dmesg ? And I'd like to see your board .dts file and your
> .config also, to compare with mine for the mioa701.
>
> I think in your dm9000 case we have this callstack :
>  - of_irq_get()
>      of_irq_parse_one() => fails, for an unknown reason to me
>                         => I would have expected it return 0
>                         => the following irq_find_host() would return
>                            -EPROBE_DEFER, that's what I'd expect
>      irq_create_of_mapping()
>        irq_create_fwspec_mapping()
>          => error message
>
> What is probable is that gpio-pxa was not probed yet, and this triggers the
> error. What I don't understand is why you don't end up with -EPROBE_DEFER,
> that's why I'd like to have your logs.

BTW, would you try also with the patch at the end of this mail applied ? Just to
verify a wild guess.

Cheers.

-- 
Robert

---8<---
diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
index cf94b72dbacd..2c532011ae8e 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1509,6 +1509,10 @@ dm9000_probe(struct platform_device *pdev)
 		goto out;
 	}
 
+	ndev->irq = platform_get_irq(pdev, 0);
+	if (ndev->irq < 0)
+		return ndev->irq;
+
 	db->irq_wake = platform_get_irq(pdev, 1);
 	if (db->irq_wake >= 0) {
 		dev_dbg(db->dev, "wakeup irq %d\n", db->irq_wake);
@@ -1570,7 +1574,6 @@ dm9000_probe(struct platform_device *pdev)
 
 	/* fill in parameters for net-dev structure */
 	ndev->base_addr = (unsigned long)db->io_addr;
-	ndev->irq	= db->irq_res->start;
 
 	/* ensure at least we have a default set of IO routines */
 	dm9000_set_io(db, iosize);

[toc] | [prev] | [next] | [standalone]


#1318488

FromMarcel Ziswiler <marcel@ziswiler.com>
Date2016-01-27 01:10 +0100
Message-ID<qVlQm-3AZ-11@gated-at.bofh.it>
In reply to#1318350
On Tue, 2016-01-26 at 21:41 +0100, Robert Jarzmik wrote:
> Robert Jarzmik <robert.jarzmik@free.fr> writes:
> 
> > > Have you seen this as well or do you know how exactly that should
> > > be
> > > worked around?
> > Hi Marcel,
> > 
> > I haven't seen that before on my devicetree boards, I will try this
> > evening on
> > top of next-20160125.
> > 
> > Could you activate the debug logs in drivers/of/irq.c please, and
> > send me
> > privately your boot dmesg ? And I'd like to see your board .dts
> > file and your
> > .config also, to compare with mine for the mioa701.
> > 
> > I think in your dm9000 case we have this callstack :
> >  - of_irq_get()
> >      of_irq_parse_one() => fails, for an unknown reason to me
> >                         => I would have expected it return 0
> >                         => the following irq_find_host() would
> > return
> >                            -EPROBE_DEFER, that's what I'd expect
> >      irq_create_of_mapping()
> >        irq_create_fwspec_mapping()
> >          => error message
> > 
> > What is probable is that gpio-pxa was not probed yet, and this
> > triggers the
> > error. What I don't understand is why you don't end up with
> > -EPROBE_DEFER,
> > that's why I'd like to have your logs.
> 
> BTW, would you try also with the patch at the end of this mail
> applied ? Just to
> verify a wild guess.

Thanks, but unfortunately that did not change anything on the issue.

> Cheers.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web