linux-kernel - Re: [PATCH] of: property: Add device link support for interrupt-parent, dmas and -gpio(s)

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

Date:   Fri, 22 Nov 2019 14:42:27 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Frank Rowand <frowand.list@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vinod Koul <vkoul@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] of: property: Add device link support for
 interrupt-parent, dmas and -gpio(s)

On Fri, Nov 22, 2019 at 1:34 PM Saravana Kannan <saravanak@...gle.com> wrote:
>
> On Fri, Nov 22, 2019 at 5:35 AM Rob Herring <robh+dt@...nel.org> wrote:
> >
> > On Wed, Nov 20, 2019 at 1:13 AM Saravana Kannan <saravanak@...gle.com> wrote:
> > >
> > > Add support for creating device links out of more DT properties.
> > >
> > > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > Cc: Thomas Gleixner <tglx@...utronix.de>
> > > Cc: Vinod Koul <vkoul@...nel.org>
> > > Cc: Linus Walleij <linus.walleij@...aro.org>
> > > Signed-off-by: Saravana Kannan <saravanak@...gle.com>
> > > ---
> > >  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