On Tue, Jun 17, 2014 at 3:29 PM, Guenter Roeck <[email protected]> wrote: > On Tue, Jun 17, 2014 at 03:08:24PM -0500, Rob Herring wrote: >> On Tue, Jun 17, 2014 at 1:10 PM, Guenter Roeck <[email protected]> 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.
Then why not put interrupt data into the child nodes? >> 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). Humm, don't see it. In any case, you would need to fall back only if the error is not EPROBE_DEFER. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
