Re: Problems with commit 9ec36cafe4 (of/irq: do irq resolution in platform_get_irq) and mfd client devices

[Guenter Roeck <linux@roeck-us.net>]

On Tue, Jun 17, 2014 at 03:08:24PM -0500, Rob Herring wrote:
> On Tue, Jun 17, 2014 at 1:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > Hi,
> >
> > I have an mfd master and client drivers on a system which has devicetree
> > enabled. The mfd master driver passes interrupts to the clients using
> > mfd cells and 'struct resource'. The client driver is a platform driver
> > which retrieves the irq using platform_get_irq().
> >
> > After commit 9ec36cafe (of/irq: do irq resolution in platform_get_irq),
> > this code no longer works. This is because platform_get_irq() does no
> > longer call platform_get_resource() if OF is enabled and if dev->of_node
> > is not NULL (it is not NULL because there is other [static] information
> > which is passed to the client with devicetree data).
> >
> > Any idea how to solve this problem ? How do I now pass a virtual interrupt
> > from an mfd master to its clients if devicetree is enabled ?
> 
> The node ptr points to the MFD node or a child node? If there are
> child nodes in DT, then why not define interrupts there too? If there
> are not child nodes, then perhaps the child drivers should not have DT
> knowledge.
> 
There is a whole bunch of secondary data in the child's dt node.
One of the child/client drivers is an i2c controller with attached
i2c muxes and several i2c devices, another is a gpio controller
with a large number of gpio pins which itself acts as interrupt
controller.

> Does it fail to get an interrupt or gets the parent interrupt instead?
> 
It fails to get an interrupt and returns -EINVAL.

> We could probably make an error fall-back to looking at resources. Or
> try to get irq from resources first, then call of_irq_get.
> 
I submitted a patch implementing the first approach a few minutes ago.
That fixes the problem for me. Not sure if that is the right solution
though, as it doesn't handle -EPROBE_DEFER. Let me know when you see
the patch if there is a better way to handle it (maybe abort with
-EPROBE_DEFER if of_irq_get returns it would do).

Guenter