All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Andy Gross <agross@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Phil Edworthy <phil.edworthy@renesas.com>,
	Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [PATCH v5 2/5] irqchip: Add RZ/G2L IA55 Interrupt Controller driver
Date: Sat, 25 Jun 2022 17:09:46 +0100	[thread overview]
Message-ID: <87y1xkencl.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+V-a8td93QOCC8cHLEPaba-hnX2gjydmKTbaCrF+zgH7hH8Jg@mail.gmail.com>

On Sat, 25 Jun 2022 13:48:08 +0100,
"Lad, Prabhakar" <prabhakar.csengg@gmail.com> wrote:
> 
> Hi Marc,
> 
> On Sat, Jun 25, 2022 at 1:08 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Sat, 25 Jun 2022 11:54:44 +0100,
> > "Lad, Prabhakar" <prabhakar.csengg@gmail.com> wrote:
> > >
> > > Hi Marc,
> > >
> > > Thank you for the review.
> > >
> > > On Sat, Jun 25, 2022 at 10:30 AM Marc Zyngier <maz@kernel.org> wrote:
> > > >
> > > > On Mon, 23 May 2022 18:42:35 +0100,
> > > > Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> > > > >
> >
> > [...]
> >
> > > > > +static int rzg2l_irqc_alloc(struct irq_domain *domain, unsigned int virq,
> > > > > +                         unsigned int nr_irqs, void *arg)
> > > > > +{
> > > > > +     struct rzg2l_irqc_priv *priv = domain->host_data;
> > > > > +     unsigned long *chip_data = NULL;
> > > >
> > > > Why the init to NULL?
> > > >
> > > Can be dropped.
> > >
> > > > > +     struct irq_fwspec spec;
> > > > > +     irq_hw_number_t hwirq;
> > > > > +     int tint = -EINVAL;
> > > > > +     unsigned int type;
> > > > > +     unsigned int i;
> > > > > +     int ret;
> > > > > +
> > > > > +     ret = irq_domain_translate_twocell(domain, arg, &hwirq, &type);
> > > > > +     if (ret)
> > > > > +             return ret;
> > > > > +
> > > > > +     /*
> > > > > +      * For TINT interrupts ie where pinctrl driver is child of irqc domain
> > > > > +      * the hwirq and TINT are encoded in fwspec->param[0].
> > > > > +      * hwirq for TINT range from 9-40, hwirq is embedded 0-15 bits and TINT
> > > > > +      * from 16-31 bits. TINT from the pinctrl driver needs to be programmed
> > > > > +      * in IRQC registers to enable a given gpio pin as interrupt.
> > > > > +      */
> > > > > +     if (hwirq > IRQC_IRQ_COUNT) {
> > > > > +             tint = TINT_EXTRACT_GPIOINT(hwirq);
> > > > > +             hwirq = TINT_EXTRACT_HWIRQ(hwirq);
> > > > > +
> > > > > +             if (hwirq < IRQC_TINT_START)
> > > > > +                     return -EINVAL;
> > > > > +     }
> > > > > +
> > > > > +     if (hwirq > (IRQC_NUM_IRQ - 1))
> > > > > +             return -EINVAL;
> > > > > +
> > > > > +     chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
> > > >
> > > > Are we really allocating an unsigned long for something that already
> > > > fits in something that is pointer-sized?
> > > >
> > > I think I received some feedback to use unsigned long.  Let me know
> > > what you want me to use here.
> >
> > I think this is just a waste of memory, but I don't really care.
> >
> Is there any better way I can handle it?

How about (shock, horror) a cast?

> 
> > >
> > > > > +     if (!chip_data)
> > > > > +             return -ENOMEM;
> > > > > +     *chip_data = tint;
> > > >
> > > > So here, *chip_data can be set to -EINVAL if hwirq <= IRQC_IRQ_COUNT?
> > > > This can't be right.
> > > >
> > > Yes *chip_data can be -EINVAL. IRQC block handles IRQ0-7 and
> > > GPIOINT0-122. So the -EINVAL here is for IRQ0-7 case were dont
> > > required the chip data in the call backs hence -EINVAL, Whereas for
> > > GPIOINT0-122 we need chip_data in the callbacks as this value needs to
> > > be programmed in the hardware registers.
> >
> > I can't see anything that checks it (let alone the difference in
> > types). And if it isn't checked, this means that the allocation is
> > pointless.
> >
> There are checks for example below:
> 
> static void rzg2l_irqc_irq_enable(struct irq_data *d)
> {
>     unsigned int hw_irq = irqd_to_hwirq(d);
> 
>     if (hw_irq >= IRQC_TINT_START && hw_irq < IRQC_NUM_IRQ) {
>         struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
>         unsigned long chip_data = *(unsigned long *)d->chip_data;
>         u32 offset = hw_irq - IRQC_TINT_START;
>         u32 tssr_offset = TSSR_OFFSET(offset);
>         u8 tssr_index = TSSR_INDEX(offset);
>         u32 reg;
> 
>         raw_spin_lock(&priv->lock);
>         reg = readl_relaxed(priv->base + TSSR(tssr_index));
>         reg |= (TIEN | chip_data) << TSSEL_SHIFT(tssr_offset);
>         writel_relaxed(reg, priv->base + TSSR(tssr_index));
>         raw_spin_unlock(&priv->lock);
>     }
>     irq_chip_enable_parent(d);
> }
> 
> This check hw_irq >= IRQC_TINT_START && hw_irq < IRQC_NUM_IRQ here
> would mean its GPIOINT0-122 and then the chip data will be used.

That doesn't check the content of chip_data if outside of this
condition. Nonetheless, you allocate an unsigned long to store
-EINVAL. Not only this is a pointless allocation, but you use it to
store something that you never retrieve the first place. Don't you see
the problem?

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-06-25 16:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-23 17:42 [PATCH v5 0/5] Renesas RZ/G2L IRQC support Lad Prabhakar
2022-05-23 17:42 ` [PATCH v5 1/5] dt-bindings: interrupt-controller: Add Renesas RZ/G2L Interrupt Controller Lad Prabhakar
2022-05-23 17:42 ` [PATCH v5 2/5] irqchip: Add RZ/G2L IA55 Interrupt Controller driver Lad Prabhakar
2022-06-25  9:30   ` Marc Zyngier
2022-06-25 10:54     ` Lad, Prabhakar
2022-06-25 12:08       ` Marc Zyngier
2022-06-25 12:48         ` Lad, Prabhakar
2022-06-25 16:09           ` Marc Zyngier [this message]
2022-06-25 19:26             ` Lad, Prabhakar
2022-05-23 17:42 ` [PATCH v5 3/5] gpio: gpiolib: Allow free() callback to be overridden Lad Prabhakar
2022-05-24  8:54   ` Linus Walleij
2022-05-24  9:06     ` Lad, Prabhakar
2022-05-24  9:29       ` Linus Walleij
2022-05-23 17:42 ` [PATCH v5 4/5] dt-bindings: pinctrl: renesas,rzg2l-pinctrl: Document the properties to handle GPIO IRQ Lad Prabhakar
2022-06-02 13:36   ` Rob Herring
2022-05-23 17:42 ` [PATCH v5 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ domain to handle GPIO interrupt Lad Prabhakar
2022-05-24  8:57   ` Linus Walleij
2022-05-24  9:01     ` Lad, Prabhakar
2022-05-24  9:26       ` Linus Walleij
     [not found]         ` <CA+V-a8uu5sTOWrWZVY=YaUaOfQZFHx46snHTRnW7ddJyH-obvA@mail.gmail.com>
2022-05-24 11:58           ` Linus Walleij
2022-06-19 19:29 ` [PATCH v5 0/5] Renesas RZ/G2L IRQC support Lad, Prabhakar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y1xkencl.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=agross@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=jonathanh@nvidia.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=phil.edworthy@renesas.com \
    --cc=prabhakar.csengg@gmail.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.