linux-kernel - Re: [PATCH] of: property: Add device link support for interrupts

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: <20201231211240.GA2333246@robh.at.kernel.org>
Date:   Thu, 31 Dec 2020 14:12:40 -0700
From:   Rob Herring <robh@...nel.org>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Saravana Kannan <saravanak@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Frank Rowand <frowand.list@...il.com>,
        Kevin Hilman <khilman@...libre.com>, kernel-team@...roid.com,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] of: property: Add device link support for interrupts

On Mon, Dec 21, 2020 at 09:30:45AM +0000, Marc Zyngier wrote:
> On 2020-12-18 21:07, Saravana Kannan wrote:
> > Add support for creating device links out of interrupts property.
> > 
> > Cc: Marc Zyngier <maz@...nel.org>
> > Cc: Kevin Hilman <khilman@...libre.com>
> > Signed-off-by: Saravana Kannan <saravanak@...gle.com>
> > ---
> > Rob/Greg,
> > 
> > This might need to go into driver-core to avoid conflict
> > due to fw_devlink refactor series that merged there.
> > 
> > Thanks,
> > Saravana
> > 
> > 
> >  drivers/of/property.c | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > index 5f9eed79a8aa..e56a5eae0a0b 100644
> > --- a/drivers/of/property.c
> > +++ b/drivers/of/property.c
> > @@ -1271,6 +1271,22 @@ static struct device_node
> > *parse_iommu_maps(struct device_node *np,
> >  	return of_parse_phandle(np, prop_name, (index * 4) + 1);
> >  }
> > 
> > +static struct device_node *parse_interrupts(struct device_node *np,
> > +					    const char *prop_name, int index)
> > +{
> > +	struct device_node *sup;
> > +
> > +	if (strcmp(prop_name, "interrupts") || index)
> > +		return NULL;
> > +
> > +	of_node_get(np);
> > +	while (np && !(sup = of_parse_phandle(np, "interrupt-parent", 0)))
> > +		np = of_get_next_parent(np);
> > +	of_node_put(np);
> > +
> > +	return sup;
> > +}
> > +
> >  static const struct supplier_bindings of_supplier_bindings[] = {
> >  	{ .parse_prop = parse_clocks, },
> >  	{ .parse_prop = parse_interconnects, },
> > @@ -1296,6 +1312,7 @@ static const struct supplier_bindings
> > of_supplier_bindings[] = {
> >  	{ .parse_prop = parse_pinctrl6, },
> >  	{ .parse_prop = parse_pinctrl7, },
> >  	{ .parse_prop = parse_pinctrl8, },
> > +	{ .parse_prop = parse_interrupts, },
> >  	{ .parse_prop = parse_regulators, },
> >  	{ .parse_prop = parse_gpio, },
> >  	{ .parse_prop = parse_gpios, },
> 
> You don't really describe what this is for so I'm only guessing
> from the context. If you want to follow the interrupt hierarchy,
> "interrupt-parent" isn't enough. You also need to track
> things like interrupt-map, or anything that carries a phandle
> to an interrupt controller.

We don't need to follow the hierarchy, we just need the immediate 
dependencies. But you are right that 'interrupt-map' also needs to be 
tracked.

I also noticed that we define 'interrupt-parent' as a dependency to 
parse, but that's wrong. The dependency is where 'interrupts' appears 
and where 'interrupt-parent' appears is irrelevant.

Rob