linux-kernel - Re: I2C OF IRQ parsing issue due to probe ordering

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141030130207.GB19386@ulmo>
Date:	Thu, 30 Oct 2014 14:02:09 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:	Wolfram Sang <wsa@...-dreams.de>, linux-i2c@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: I2C OF IRQ parsing issue due to probe ordering

On Thu, Oct 30, 2014 at 02:53:42PM +0200, Laurent Pinchart wrote:
> Hi Wolfram and Thierry,
> 
> On Monday 27 October 2014 13:58:19 Wolfram Sang wrote:
> > > The i2c@...20000 node is probed before the gpio@...51000 node. The
> > > of_i2c_register_devices() function tries to register all children,
> > > including hdmi@39. It tries to parse and map the I2C client IRQ by
> > > calling irq_of_parse_and_map(), which returns 0 as the interrupt
> > > controller isn't probed yet. The adv7511 driver later probes the hdmi@39
> > > device and gets client->irq set to 0.
> > 
> > I've got this strange feeling of deja vu... Ah, here: Thierry Reding
> > tackled this problem a year ago. His series:
> 
> Thanks for the pointer.
> 
> > https://lkml.org/lkml/2013/9/16/111 (of/irq: Defer interrupt reference
> > resolution)
> > 
> > He did a V2 (which never made it to the i2c list). Seems like the first
> > two patches made it and the rest got stalled without discussion?
> > 
> > https://lkml.org/lkml/2013/9/18/216
> > 
> > Adding Thierry to the queue. Maybe he can bring some light to what
> > happened to his series.
> 
> That's exactly what I need :-) Thierry, do you plan to respin the series ?

Not really. Like I said in my reply to Wolfram, a different set of
patches was merged subsequently to solve this issue for platform
devices, which makes my patchset mostly obsolete. But I think the
solution that you proposed would work well if you do:

-		int irq = irq_of_parse_and_map(dev->of_node, 0);
+		int irq = of_irq_get(dev->of_node, 0);

And then changing irq_create_of_mapping() should no longer be necessary.
I still think it's kind of lame to handle -EPROBE_DEFER specially as was
done in of_irq_get(), but given how worried people were about the more
invasive changes needed to propagate the correct error code all the way
up it seems like that's as good as it's going to get.

Thierry

Content of type "application/pgp-signature" skipped