On Fri, Nov 22, 2019 at 1:34 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > > On Fri, Nov 22, 2019 at 5:35 AM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > > > On Wed, Nov 20, 2019 at 1:13 AM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > > > > > > Add support for creating device links out of more DT properties. > > > > > > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > > Cc: Vinod Koul <vkoul@xxxxxxxxxx> > > > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> > > > Signed-off-by: Saravana Kannan <saravanak@xxxxxxxxxx> > > > --- > > > drivers/of/property.c | 8 ++++++++ > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c > > > index 0fa04692e3cc..dedbf82da838 100644 > > > --- a/drivers/of/property.c > > > +++ b/drivers/of/property.c > > > @@ -1188,7 +1188,11 @@ DEFINE_SIMPLE_PROP(interconnects, "interconnects", "#interconnect-cells") > > > DEFINE_SIMPLE_PROP(iommus, "iommus", "#iommu-cells") > > > DEFINE_SIMPLE_PROP(mboxes, "mboxes", "#mbox-cells") > > > DEFINE_SIMPLE_PROP(io_channels, "io-channel", "#io-channel-cells") > > > +DEFINE_SIMPLE_PROP(interrupt_parent, "interrupt-parent", NULL) > > > > This one is not going to work most of the time (ignoring the fact that > > the primary controller doesn't have a struct device) because the > > interrupt-parent is typically in a parent node. > > Just to make sure, I'm not parsing this property incorrectly, right? > > Are you saying it's listed at the parent of a bunch of devices and the > interrupt-parent is inherited and won't really create device links for > those child devices? > I mainly added this to make sure IRQ controllers are probed in the > right order. Also, if this delays the parent device probe, by the time > the child devices are added, the interrupt parent most likely would > already be probed. > > > You could make it work > > by specifying 'interrupt-parent' in every node, but that's not a > > pattern I want to encourage. > > I'm trying to take care of the basic per-device properties first. > Adding support for inherited properties isn't too difficult, I just > need to get to those at some point. Also, for inherited properties, we > can't really block probing because the child device might not depend > on that resource. Inherited properties are mainly relevant only for > sync_state() callbacks. You're looking at the wrong property. You need to look for 'interrupts' and 'interrupts-extended'. Pretty good chance if the device has interrupts, then it needs them. The latter is easy. It's just like the others you have (phandle + cells). If you have 'interrupts' then you need to walk the interrupt tree the same way the OF IRQ code already does. > > There's also all the other ways the > > parent can be determined. Any parent node with 'interrupt-controller' > > or 'interrupt-map' property is the parent. And there's > > 'interrupts-extended' too. > > Now I'm confused. Not sure if you are referring to actual device > parent now or if you are talking about an "interrupt supplier". Yes. both. The interrupt tree may or may not mirror the device node tree. Or you could have a mixture. You've got to handle both cases. But really, you just need to use the code that's already there to do all that and deal with all these conditions. Essentially, you need to copy of_irq_get(), but get the struct device from the irq_domain. Rob
