linux-kernel - Re: [REGRESSION] gpio: pxa: change initcall level second attempt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Jan 2016 01:05:24 +0100
From:	Marcel Ziswiler <marcel@...wiler.com>
To:	Robert Jarzmik <robert.jarzmik@...e.fr>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] gpio: pxa: change initcall level second attempt

On Tue, 2016-01-26 at 21:41 +0100, Robert Jarzmik wrote:
> Robert Jarzmik <robert.jarzmik@...e.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.