Received-SPF: pass (google.com: domain of linux-kernel+bounces-174478-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <20240430040822.1133339-1-apatel@ventanamicro.com> <CAGETcx8C81OAfpTVBqk1yRdcwFG5v7v0PWVF6Udg2gPK0vH9dQ@mail.gmail.com>
In-Reply-To: <CAGETcx8C81OAfpTVBqk1yRdcwFG5v7v0PWVF6Udg2gPK0vH9dQ@mail.gmail.com>
From: Anup Patel <anup@brainfault.org>
Date: Thu, 9 May 2024 17:37:59 +0530
Message-ID: <CAAhSdy0g_2xeuox3yn=dwtk8aZmozO_ctVAfubNRvQVh=C4MpA@mail.gmail.com>
Subject: Re: [PATCH v3] of: property: Add fw_devlink support for interrupt-map property
To: Saravana Kannan <saravanak@google.com>
Cc: Anup Patel <apatel@ventanamicro.com>, Rob Herring <robh@kernel.org>, 
	Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, 
	Atish Patra <atishp@atishpatra.org>, Andrew Jones <ajones@ventanamicro.com>, 
	Sunil V L <sunilvl@ventanamicro.com>, linux-riscv@lists.infradead.org, 
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 9, 2024 at 2:25=E2=80=AFAM Saravana Kannan <saravanak@google.co=
m> wrote:
>
> On Mon, Apr 29, 2024 at 9:08=E2=80=AFPM Anup Patel <apatel@ventanamicro.c=
om> 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@ventanamicro.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(stru=
ct device_node *np,
> >         return of_irq_parse_one(np, index, &sup_args) ? NULL : sup_args=
np;
> >  }
> >
> > +static struct device_node *parse_interrupt_map(struct device_node *np,
> > +                                              const char *prop_name, i=
nt 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 =3D of_bus_n_addr_cells(np);
> > +
> > +       imap =3D of_get_property(np, "interrupt-map", &imaplen);
> > +       if (!imap || imaplen <=3D (addrcells + intcells))
> > +               return NULL;
> > +       imap_end =3D imap + imaplen;
> > +
> > +       sup_args.np =3D NULL;
> > +       while (imap < imap_end) {
> > +               addr =3D imap;
> > +               imap +=3D addrcells;
> > +
> > +               sup_args.np =3D np;
> > +               sup_args.args_count =3D intcells;
> > +               for (i =3D 0; i < intcells; i++)
> > +                       sup_args.args[i] =3D be32_to_cpu(imap[i]);
> > +               imap +=3D 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 =3D 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@google.com>
>
> -Saravana
>
> > +               imap +=3D sup_args.args_count + 1;
> > +               index--;
> > +       }
> > +
> > +       return NULL;
> > +}
> > +
> >  static struct device_node *parse_remote_endpoint(struct device_node *n=
p,
> >                                                  const char *prop_name,
> >                                                  int index)
> > @@ -1359,6 +1408,7 @@ static const struct supplier_bindings of_supplier=
_bindings[] =3D {
> >         { .parse_prop =3D parse_msi_parent, },
> >         { .parse_prop =3D parse_gpio_compat, },
> >         { .parse_prop =3D parse_interrupts, },
> > +       { .parse_prop =3D parse_interrupt_map, },
> >         { .parse_prop =3D parse_regulators, },
> >         { .parse_prop =3D parse_gpio, },
> >         { .parse_prop =3D parse_gpios, },
> > --
> > 2.34.1
> >

Thanks,
Anup