[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231129154131.GA2492847-robh@kernel.org>
Date: Wed, 29 Nov 2023 09:41:31 -0600
From: Rob Herring <robh@...nel.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: James Tai <james.tai@...ltek.com>,
Thomas Gleixner <tglx@...utronix.de>,
Marc Zyngier <maz@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
kernel test robot <lkp@...el.com>,
Dan Carpenter <error27@...il.com>
Subject: Re: [PATCH v3 2/6] irqchip: Add interrupt controller support for
Realtek DHC SoCs
On Wed, Nov 29, 2023 at 11:21:06AM +0300, Dan Carpenter wrote:
> On Wed, Nov 29, 2023 at 01:43:35PM +0800, James Tai wrote:
> > +static int realtek_intc_subset(struct device_node *node, struct realtek_intc_data *data, int index)
> > +{
> > + struct realtek_intc_subset_data *subset_data = &data->subset_data[index];
> > + const struct realtek_intc_subset_cfg *cfg = &data->info->cfg[index];
> > + int irq;
> > +
> > + irq = irq_of_parse_and_map(node, index);
> > + if (irq <= 0)
> > + return irq;
>
> I don't think irq_of_parse_and_map() can return negatives. Only zero
> on error. Returning zero on error is a historical artifact with IRQ
> functions and a constant source of bugs. But here returning zero is
> success. See my blog for more details:
> https://staticthinking.wordpress.com/2023/08/07/writing-a-check-for-zero-irq-error-codes/
It's worse than that. The irq functions historically returned NO_IRQ on
error, but that could be 0 or -1 depending on the arch.
Use of_irq_get() instead. It's a bit better in that it returns an error
code for most cases. But still returns 0 on mapping failure.
Rob
Powered by blists - more mailing lists