[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a006de4d-46bc-442d-9f8e-92e5d219b8b9@kernel.org>
Date: Fri, 1 Nov 2024 07:23:43 +0100
From: Jiri Slaby <jirislaby@...nel.org>
To: Advait Dhamorikar <advaitdhamorikar@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Fabrizio Castro <fabrizio.castro.jz@...esas.com>
Cc: linux-kernel@...r.kernel.org, skhan@...uxfoundation.org,
anupnewsmail@...il.com
Subject: Re: [PATCH-next] irqchip/renesas-rzv2h: Fix potentially mismatched
datatype
Hi,
On 31. 10. 24, 20:36, Advait Dhamorikar wrote:
> This patch updates the type of hw_irq to unsigned long to
> match irq_hw_number_t.
>
> The variable hw_irq is defined as unsigned int at places,
> However when it is initialized using irqd_to_hwirq(), it returns
> an irq_hw_number_t, which inturn is a typedef for unsigned long.
"in turn"
But what's the purpose of this? First, why wouldn't you use
irq_hw_number_t then?
Nevertheless, the HW does not support hw irqs > uint (it supports
1+16+32, actually). So why all this in the first place?
> @@ -265,9 +265,9 @@ static int rzv2h_tint_set_type(struct irq_data *d, unsigned int type)
> u32 titsr, titsr_k, titsel_n, tien;
> struct rzv2h_icu_priv *priv;
> u32 tssr, tssr_k, tssel_n;
> - unsigned int hwirq;
> + unsigned long hwirq;
> u32 tint, sense;
> - int tint_nr;
> + unsigned long tint_nr;
Switching tint_nr to unsigned might still be a good thing to avoid weird
signed overflows in the future. But I don't think it warrants for a patch...
thanks,
--
js
suse labs
Powered by blists - more mailing lists