linux-kernel - Re: [PATCH v3] of: property: Add fw_devlink support for interrupt-map property

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: Thu, 9 May 2024 17:37:59 +0530
From: Anup Patel <anup@...infault.org>
To: Saravana Kannan <saravanak@...gle.com>
Cc: Anup Patel <apatel@...tanamicro.com>, Rob Herring <robh@...nel.org>, 
	Palmer Dabbelt <palmer@...belt.com>, Paul Walmsley <paul.walmsley@...ive.com>, 
	Atish Patra <atishp@...shpatra.org>, Andrew Jones <ajones@...tanamicro.com>, 
	Sunil V L <sunilvl@...tanamicro.com>, linux-riscv@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3] of: property: Add fw_devlink support for interrupt-map property

On Thu, May 9, 2024 at 2:25 AM Saravana Kannan <saravanak@...gle.com> wrote:
>
> On Mon, Apr 29, 2024 at 9:08 PM Anup Patel <apatel@...tanamicro.com> wrote:
> >
> > Some of the PCI controllers (such as generic PCI host controller)
> > use "interrupt-map" DT property to describe the mapping between
> > PCI endpoints and PCI interrupt pins. This the only case where
> > the interrupts are not described in DT.
> >
> > Currently, there is no fw_devlink created based on "interrupt-map"
> > DT property so interrupt controller is not guaranteed to be probed
> > before PCI host controller. This affects every platform where both
> > PCI host controller and interrupt controllers are probed as regular
> > platform devices.
> >
> > This creates fw_devlink between consumers (PCI host controller) and
> > supplier (interrupt controller) based on "interrupt-map" DT property.
> >
> > Signed-off-by: Anup Patel <apatel@...tanamicro.com>
> > ---
> > Changes since v2:
> > - No need for a loop to find #interrupt-cells property value
> > - Fix node de-reference leak when index is greater than number
> >   of entries in interrupt-map property
> > Changes since v1:
> > - Updated commit description based on Rob's suggestion
> > - Use of_irq_parse_raw() for parsing interrupt-map DT property
> > ---
> >  drivers/of/property.c | 50 +++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 50 insertions(+)
> >
> > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > index a6358ee99b74..7326ca07adfe 100644
> > --- a/drivers/of/property.c
> > +++ b/drivers/of/property.c
> > @@ -1311,6 +1311,55 @@ static struct device_node *parse_interrupts(struct device_node *np,
> >         return of_irq_parse_one(np, index, &sup_args) ? NULL : sup_argsnp;
> >  }
> >
> > +static struct device_node *parse_interrupt_map(struct device_node *np,
> > +                                              const char *prop_name, int index)
> > +{
> > +       const __be32 *imap, *imap_end, *addr;
> > +       struct of_phandle_args sup_args;
> > +       u32 addrcells, intcells;
> > +       int i, imaplen;
> > +
> > +       if (!IS_ENABLED(CONFIG_OF_IRQ))
> > +               return NULL;
> > +
> > +       if (strcmp(prop_name, "interrupt-map"))
> > +               return NULL;
> > +
> > +       if (of_property_read_u32(np, "#interrupt-cells", &intcells))
> > +               return NULL;
> > +       addrcells = of_bus_n_addr_cells(np);
> > +
> > +       imap = of_get_property(np, "interrupt-map", &imaplen);
> > +       if (!imap || imaplen <= (addrcells + intcells))
> > +               return NULL;
> > +       imap_end = imap + imaplen;
> > +
> > +       sup_args.np = NULL;
> > +       while (imap < imap_end) {
> > +               addr = imap;
> > +               imap += addrcells;
> > +
> > +               sup_args.np = np;
> > +               sup_args.args_count = intcells;
> > +               for (i = 0; i < intcells; i++)
> > +                       sup_args.args[i] = be32_to_cpu(imap[i]);
> > +               imap += intcells;
> > +
> > +               if (of_irq_parse_raw(addr, &sup_args))
> Can you leave a comment above this call saying of_irq_parse_raw()
> updates sup_args.np? It's really a problem with the function IMO, but
> a comment here would be helpful.

Sure, I will add a comment about this.

>
> > +                       return NULL;
> > +
> > +               if (!index)
> > +                       return sup_args.np;
> > +
> > +               of_node_put(sup_args.np);
> > +               sup_args.np = NULL;
>
> Why do you need to set it to NULL? Can we just delete this line?

These NULL assignments are residue from previous revision. I will
remove these assignments.

>
> If you take care of these minor comments, then
>
> Reviewed-by: Saravana Kannan <saravanak@...gle.com>
>
> -Saravana
>
> > +               imap += sup_args.args_count + 1;
> > +               index--;
> > +       }
> > +
> > +       return NULL;
> > +}
> > +
> >  static struct device_node *parse_remote_endpoint(struct device_node *np,
> >                                                  const char *prop_name,
> >                                                  int index)
> > @@ -1359,6 +1408,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
> >         { .parse_prop = parse_msi_parent, },
> >         { .parse_prop = parse_gpio_compat, },
> >         { .parse_prop = parse_interrupts, },
> > +       { .parse_prop = parse_interrupt_map, },
> >         { .parse_prop = parse_regulators, },
> >         { .parse_prop = parse_gpio, },
> >         { .parse_prop = parse_gpios, },
> > --
> > 2.34.1
> >

Thanks,
Anup