linux-kernel - Re: [PATCH 5/6] soc: renesas: Add support for Renesas RZ/N1 GPIO Interrupt Multiplexer

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: <20250801111753.382f52ac@bootlin.com>
Date: Fri, 1 Aug 2025 11:17:53 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Rob Herring <robh@...nel.org>
Cc: Hoan Tran <hoan@...amperecomputing.com>, Linus Walleij
 <linus.walleij@...aro.org>, Bartosz Golaszewski <brgl@...ev.pl>, 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, Miquel
 Raynal <miquel.raynal@...tlin.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 5/6] soc: renesas: Add support for Renesas RZ/N1 GPIO
 Interrupt Multiplexer

Hi Rob,

On Wed, 30 Jul 2025 15:47:33 -0500
Rob Herring <robh@...nel.org> wrote:

...
> > > > +
> > > > +static int irqmux_imap_cb(void *data, const __be32 *imap,
> > > > +			  const struct of_phandle_args *parent_args)
> > > > +{
> > > > +	struct irqmux_cb_data *priv = data;
> > > > +	u32 src_hwirq;
> > > > +	int index;
> > > > +
> > > > +	/*
> > > > +	 * The child #address-cells is 0. Already checked in irqmux_setup().
> > > > +	 * The first value in imap is the src_hwirq
> > > > +	 */
> > > > +	src_hwirq = be32_to_cpu(*imap);    
> > > 
> > > The iterator should take care of the endianness conversion.  
> > 
> > Ok, it will take care.
> >   
> > >   
> > > > +
> > > > +	/*
> > > > +	 * Get the index in our interrupt array that matches the parent in the
> > > > +	 * interrupt-map
> > > > +	 */
> > > > +	index = irqmux_find_interrupt_index(priv->dev, priv->np, parent_args);
> > > > +	if (index < 0)
> > > > +		return dev_err_probe(priv->dev, index, "output interrupt not found\n");
> > > > +
> > > > +	dev_info(priv->dev, "interrupt %u mapped to output interrupt[%u]\n",
> > > > +		 src_hwirq, index);    
> > > 
> > > Do you even need "interrupts"? Just make the "interrupt-map" index 
> > > important and correspond to the hw index. That would greatly simplify 
> > > all this.  
> > 
> > I would like to avoid to be based on the interrupt-map index.
> > 
> > Indeed, IMHO, it is less robust. I don't thing that we can enforce the
> > interrupt-map items order. Based on interrupt-map index, we need to ensure
> > that the first item is related to GIC 103, the second one to GIC 104 and so
> > on.  
> 
> How exactly are you enforcing that order for "interrupts"? You can't.

I can impose interrupt-names property in the binding and at least, those
names are to be in order (checked by dtbs_check).

Based on that if a mismatch is present between interrupt-names and
interrupts it is an issue in the dts used.

With interrupt-map, nothing can be imposed and so nothing can be checked.

> 
> Aren't you just duplicating the information in "interrupts" in the 
> interrupt-map.
> 

I will remove 'interrupts' in the next iteration and use only 'interrupt-map'.

I will add some information related to the order of the interrup-map item in the
binding (description of the interrupt-map property).

Best regards,
Hervé