linux-kernel - Re: [PATCH v4 0/8] Device Tree support for the at91sam9261ek

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, 12 Feb 2014 14:01:39 +0100
From:	Jean-Jacques Hiblot <jjhiblot@...phandler.com>
To:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:	Jean-Jacques Hiblot <jjhiblot@...phandler.com>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	boris brezillon <b.brezillon@...rkiz.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 0/8] Device Tree support for the at91sam9261ek

Thomas,

I wasn't very informative indeed.

The dm9000 is instantiated from the DT, its irq is described as <&pioC
2 IRQ_TYPE_EDGE_BOTH>
The problem, as I see it, is that at the time the IRQ description is
translated the irq domain doesn't exist yet and the translation fails.
The result is that the ressource of the platform driver do not contain
any information about an IRQ.
The irq domain is added later when the gpio driver is probed
(pinctrl-at91.c:1684).
A bit later the dm9000 gets probed and fails lamely because it can't
find an IRQ ressource.

Jean-Jacques



2014-02-12 13:44 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@...e-electrons.com>:
> Dear Jean-Jacques Hiblot,
>
> On Wed, 12 Feb 2014 13:36:08 +0100, Jean-Jacques Hiblot wrote:
>
>> >> For dm9000 the issue is (again) related to an ordering problem:
>> >> the Ethernet need an interrupt provided by the gpio driver. Unfortunately,
>> >> the gpio driver initialization is called after the dm900 driver
>> >> initialization.
>> >
>> > And -EPROBE_DEFER doesn't solve this problem?
>> not really the problem happens before the driver is actually probed
>> when the ressource for the platform driver are filled
>
> Sorry, I don't have all the context. If I understand correctly what you
> mean, the GPIO driver is probed through the DT, but the DM9000 driver
> is probed in a legacy way from the board file, and you have the case
> where the DM9000 platform_device gets registered before the GPIOs are
> actually available? In this case, what about having the
> of_platform_populate() call *before* the platform_device_register() for
> your DM9000 ? Again, I don't have all the context, so I might very well
> be getting the situation incorrectly.
>
> Of course, ideally, the DM9000 driver should be probed using the DT,
> but I guess this needs the SMC DT binding that is still being
> discussed, if I followed correctly.
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/