lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkdZ1qg6ecA5DyVEGUHQxLh0SnC=GC5JZdevT99YVWU0ypA@mail.gmail.com>
Date: Mon, 13 Oct 2025 12:49:06 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Wolfram Sang <wsa+renesas@...g-engineering.com>, 
	Hoan Tran <hoan@...amperecomputing.com>, Bartosz Golaszewski <brgl@...ev.pl>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, Magnus Damm <magnus.damm@...il.com>, 
	Saravana Kannan <saravanak@...gle.com>, Serge Semin <fancer.lancer@...il.com>, 
	Phil Edworthy <phil.edworthy@...esas.com>, linux-gpio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-renesas-soc@...r.kernel.org, Pascal Eberhard <pascal.eberhard@...com>, 
	Miquel Raynal <miquel.raynal@...tlin.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v4 7/8] soc: renesas: Add support for Renesas RZ/N1 GPIO
 Interrupt Multiplexer

On Wed, Oct 1, 2025 at 5:42 PM Herve Codina <herve.codina@...tlin.com> wrote:
> On Wed, 1 Oct 2025 13:08:57 +0200
> Linus Walleij <linus.walleij@...aro.org> wrote:

> I don't see how IRQ_DOMAIN_HIERARCHY would help.
>
> The irq-mux only muxes irq signal without performing any operations usually
> done by an interrupt controller.
>
> That's why I used interrupt-map in the irq-mux.
>
> The only information needed by the irq-mux is the interrupt line muxing that
> needs to be applied. This information is available in the interrupt-map.
>
> If we introduce IRQ_DOMAIN_HIERARCHY, either it is done at gpio controller
> level to route gpio interrupts to GIC interrupts and, in that case, the
> irq-mux is skipped and cannot apply the muxing.

I meant to introduce the muxing code directly into the
GPIO driver instead of using a separate muxing driver,
using the struct gpio_irq_chip supplanted by IRQ_DOMAIN_HIERARCHY.

Are these IRQ lines ever muxed for anything else than
GPIO? In that case go ahead with this solution, I guess.
But the title of your patch seems to suggest it is
only used by GPIO.

If it is only used for GPIO, why make it a separate
driver instead of just putting the muxing into the
GPIO driver?

> Or it is introduced at irq-mux level and irq-mux need to be an interrupt
> controller but is component is not an interrupt controller.

It is a hierarchy, as all interrupts are routed through
it. Just becaus you don't have to ACK every IRQ in the
hierarchy doesn't mean it's not a hierarchy.

> Maybe I missed some points or I misunderstood the purpose of
> IRQ_DOMAIN_HIERARCHY.
>
> Can you give me some details on how IRQ_DOMAIN_HIERARCHY should be
> used in my case?

The gpio_irq_chip ->child_to_parent_hwirq() is called
as part of the translation of each IRQ and in this callback
you can set up your mux. You can return
negative if you run out of muxable GPIO lines.
This means the irqdomain hierarchy fits as abstraction
for this usecase.

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ