linux-kernel - Re: no irq domain found for ... a GPIO interrupt controller

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <56C5F4A5.2000206@arm.com>
Date:	Thu, 18 Feb 2016 16:43:17 +0000
From:	Marc Zyngier <marc.zyngier@....com>
To:	Stefan Agner <stefan@...er.ch>
Cc:	jiang.liu@...ux.intel.com,
	Sanchayan Maity <maitysanchayan@...il.com>, robh@...nel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: no irq domain found for ... a GPIO interrupt controller

Hi Stefan,

On 18/02/16 16:13, Stefan Agner wrote:
> Hi Marc,
> 
> On 2016-02-18 01:14, Marc Zyngier wrote:
> <snip>
>> What your stack trace shows is that the failure occurs at boot time,
>> when of_platform_populate() parses the DT and creates the platform
>> devices. As part of this process, it tries to resolves the interrupt
>> specifiers, but fails to do so for this particular device, since the
>> corresponding irqchip and domain have not been created yet (the GPIO
>> controller is itself a device, while other irqchips are not).
>>
>> But as long as your device driver uses platform_get_irq(), you will
>> force the interrupt specifier to be evaluated again, this time giving
>> you a valid interrupt (and provided that your GPIO driver has
>> initialized in the meantime - check for -EPROBE_DEFER). At some point,
>> we'll be able to kill the interrupt resolution from
>> of_platform_populate().
> 
> The device driver is using platform_get_irq. However, I think it
> currently would not handle EPROBE_DEFER right, but seems also not to
> happen in practice...
> 
>>
>> To summarize, your driver not working may not be related to this issue.
> 
> So this means that despite the warning, nothing I really need to worry
> right? Does this warning will go away in the future?

It is unlikely that the warning will go away anytime soon (there is a
truckload of drivers to fix), but you can safely ignore it as long as
you end up getting a interrupt from platform_get_irq().

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...