From: Marc Zyngier <maz@kernel.org>
To: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Thomas Gleixner <tglx@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Antoine Tenart <atenart@kernel.org>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Frank Li <Frank.Li@nxp.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Mark-PK Tsai <mark-pk.tsai@mediatek.com>,
Daniel Palmer <daniel@thingy.jp>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
Nishanth Menon <nm@ti.com>, Tero Kristo <kristo@kernel.org>,
Santosh Shilimkar <ssantosh@kernel.org>,
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-rpi-kernel@lists.infradead.org, imx@lists.linux.dev,
linux-amlogic@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 3/4] irqchip/gic: Use GIC_* DT binding definitions
Date: Thu, 05 Mar 2026 10:13:53 +0000 [thread overview]
Message-ID: <86v7fa7fdq.wl-maz@kernel.org> (raw)
In-Reply-To: <d22488d128d39fcd90359f59559fac637bb4b04c.1772644406.git.geert+renesas@glider.be>
On Wed, 04 Mar 2026 17:21:58 +0000,
Geert Uytterhoeven <geert+renesas@glider.be> wrote:
>
> Replace magic numbers by symbolic DT binding definitions. This improves
> readability, and makes it easier to find where the various GIC
> interrupts types are handled.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/irqchip/irq-gic-v3.c | 14 ++++++++------
> drivers/irqchip/irq-gic.c | 6 ++++--
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index d75163e71bf22473..6ac103cb40097acc 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -35,6 +35,8 @@
> #include <asm/smp_plat.h>
> #include <asm/virt.h>
>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> #include "irq-gic-common.h"
>
> static u8 dist_prio_irq __ro_after_init = GICV3_PRIO_IRQ;
> @@ -1602,25 +1604,25 @@ static int gic_irq_domain_translate(struct irq_domain *d,
> return -EINVAL;
>
> switch (fwspec->param[0]) {
> - case 0: /* SPI */
> + case GIC_SPI:
I'd rather not do that. I use *numeric* values on purpose, because
that's what the DT *binding* describes, and I have no control over
what lives in that include file (it gets changed without me being even
Cc'd).
So I want to stick to the binding, and not to the interpretation of
it. If you want symbolic values to be used, describe them in the
binding, have a tool to generate the values from the binding, and use
that everywhere.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-03-05 10:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 17:21 [PATCH 0/4] irqchip/gic: Use GIC_* DT binding definitions Geert Uytterhoeven
2026-03-04 17:21 ` [PATCH 1/4] dt-bindings: interrupt-controller: arm,gic: Document symbolic definitions Geert Uytterhoeven
2026-03-05 8:12 ` Krzysztof Kozlowski
2026-03-04 17:21 ` [PATCH 2/4] genirq: Document interaction between <linux/irq.h> and DT binding defs Geert Uytterhoeven
2026-03-04 17:21 ` [PATCH 3/4] irqchip/gic: Use GIC_* DT binding definitions Geert Uytterhoeven
2026-03-05 10:13 ` Marc Zyngier [this message]
2026-03-05 10:24 ` Geert Uytterhoeven
2026-03-05 10:38 ` Marc Zyngier
2026-03-04 17:21 ` [PATCH 4/4] iirqchip/gic children: " Geert Uytterhoeven
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=86v7fa7fdq.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=atenart@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=conor+dt@kernel.org \
--cc=daniel@thingy.jp \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=florian.fainelli@broadcom.com \
--cc=geert+renesas@glider.be \
--cc=hayashi.kunihiko@socionext.com \
--cc=imx@lists.linux.dev \
--cc=jbrunet@baylibre.com \
--cc=jonathanh@nvidia.com \
--cc=kernel@pengutronix.de \
--cc=khilman@baylibre.com \
--cc=kristo@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mark-pk.tsai@mediatek.com \
--cc=martin.blumenstingl@googlemail.com \
--cc=matthias.bgg@gmail.com \
--cc=mhiramat@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=nm@ti.com \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=ssantosh@kernel.org \
--cc=tglx@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox