public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Alireza Sanaee <alireza.sanaee@huawei.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Marc Zyngier <maz@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	Timothy Hayes <timothy.hayes@arm.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v4 21/26] irqchip/gic-v5: Add GICv5 IRS/SPI support
Date: Thu, 29 May 2025 11:32:06 +0200	[thread overview]
Message-ID: <aDgplizfKU/iFwe/@lpieralisi> (raw)
In-Reply-To: <20250529094519.0000460e.alireza.sanaee@huawei.com>

On Thu, May 29, 2025 at 09:45:19AM +0100, Alireza Sanaee wrote:

[...]

> > > cpus is a phandle? I think this is going to run into current
> > > discussion on what phandles to CPUs on an SMT system look like (Rob
> > > Herring and Mark Rutland have different views)
> > > https://lore.kernel.org/linux-arm-kernel/20250512080715.82-1-alireza.sanaee@huawei.com/  
> > 
> > I will make sure to steer clear of that then ;-), whatever the outcome
> > the current "cpus" bindings should continue to work as-is, right ?
> > 
> > > Anyhow this doesn't look right to me.
> > > I think it should be of_count_phandle_with_args()   
> > 
> > Aren't they equivalent in functionality if
> > of_count_phandle_with_args() cells_name == NULL ?
> > 
> > I will update the code but if the functionality provided is not the
> > same there is kernel code to fix (it is an example, there are others):
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-apple-aic.c?h=v6.15#n903
> 
> I think this is fine, as long as we have always len(reg) == 1 which
> is our current case in the dt.

I don't understand what you mean. "cpus" is a list of phandles, what
has "reg" got to do with it ?

"reg" of which node ? "cpu" ? why should it be that len(reg) == 1
always ? It describes MPIDR_EL1, it depends on the "cpus" _node_
#address-cells.

I am missing something from the thread above probably.

Lorenzo

> > 
> > > Potentially with cpu-cells as the argument depending on how that
> > > thread goes.
> > >   
> > > > +	if (ncpus < 0)
> > > > +		return -EINVAL;
> > > > +
> > > > +	niaffids = of_property_count_elems_of_size(node,
> > > > "arm,iaffids",
> > > > +						   sizeof(u16));
> > > > +	if (niaffids != ncpus)
> > > > +		return -EINVAL;
> > > > +  
> > > 	u16 *iaffids __free(kfree) = kcalloc(niaffids,
> > > sizeof(*iaffids), GFP_KERNEL);  
> > 
> > Maybe I should rewrite this in Rust :)
> > 
> > > > +	iaffids = kcalloc(niaffids, sizeof(*iaffids),
> > > > GFP_KERNEL);
> > > > +	if (!iaffids)
> > > > +		return -ENOMEM;
> > > > +
> > > > +	ret = of_property_read_u16_array(node, "arm,iaffids",
> > > > iaffids, niaffids);
> > > > +	if (ret)
> > > > +		return ret;
> > > > +
> > > > +	for (i = 0; i < ncpus; i++) {
> > > > +		struct device_node *cpu_node;
> > > > +		u32 cpu_phandle;
> > > > +		int cpu;
> > > > +
> > > > +		if (of_property_read_u32_index(node, "cpus", i,
> > > > &cpu_phandle))
> > > > +			continue;
> > > > +
> > > > +		cpu_node = of_find_node_by_phandle(cpu_phandle);
> > > >  
> > > 
> > > 		cpu_node = of_parse_phandle(node, "cpus", i);
> > > 
> > > not work here?  
> > 
> > I think it would.
> > 
> > >    
> > > > +		if (WARN_ON(!cpu_node))
> > > > +			continue;
> > > > +
> > > > +		cpu = of_cpu_node_to_id(cpu_node);  
> > > 
> > > If this is all you want then Ali's series gives you a helper
> > > 
> > > 		cpu = of_cpu_phandle_to_id(node, &cpu_node, i);
> > > 
> > > Though even better to have a helper that allows
> > > 		cpu = of_cpu_phandle_to_id(node, NULL, i); and
> > > handles the node put as internally.
> > > 
> > > Ali, any reason we can't do that?  Seems to be a fairly common
> > > pattern.
> > > 
> > > 
> > >    
> > > > +		of_node_put(cpu_node);
> > > > +		if (WARN_ON(cpu < 0))
> > > > +			continue;
> > > > +
> > > > +		if (iaffids[i] & ~iaffid_mask) {
> > > > +			pr_warn("CPU %d iaffid 0x%x exceeds IRS
> > > > iaffid bits\n",
> > > > +				cpu, iaffids[i]);
> > > > +			continue;
> > > > +		}
> > > > +
> > > > +		per_cpu(cpu_iaffid, cpu).iaffid = iaffids[i];
> > > > +		per_cpu(cpu_iaffid, cpu).valid = true;
> > > > +
> > > > +		/* We also know that the CPU is connected to
> > > > this IRS */
> > > > +		per_cpu(per_cpu_irs_data, cpu) = irs_data;
> > > > +	}
> > > > +
> > > > +	return ret;
> > > > +}  
> > >   
> > > > diff --git a/drivers/irqchip/irq-gic-v5.c
> > > > b/drivers/irqchip/irq-gic-v5.c index
> > > > a50982e5d98816d88e4fca37cc0ac31684fb6c76..e58ff345dbfaf840b17ad63c4fdb6c227137cf4b
> > > > 100644 --- a/drivers/irqchip/irq-gic-v5.c +++
> > > > b/drivers/irqchip/irq-gic-v5.c
> > > >
> > > > +
> > > > +static int gicv5_spi_irq_set_irqchip_state(struct irq_data *d,
> > > > +					   enum
> > > > irqchip_irq_state which,
> > > > +					   bool val)
> > > > +{  
> > > 
> > > Similar to previous, I'd call the state parameter state rather than
> > > val.  
> > 
> > Right.
> > 
> > > > diff --git a/include/linux/irqchip/arm-gic-v5.h
> > > > b/include/linux/irqchip/arm-gic-v5.h index
> > > > 4ff0ba64d9840c3844671f7850bb3d81ba2eb1b6..187af307de9170d9569898cb1e50de376a38bd0a
> > > > 100644 --- a/include/linux/irqchip/arm-gic-v5.h +++
> > > > b/include/linux/irqchip/arm-gic-v5.h @@ -5,6 +5,8 @@
> > > >  #ifndef __LINUX_IRQCHIP_ARM_GIC_V5_H
> > > >  #define __LINUX_IRQCHIP_ARM_GIC_V5_H  
> > >   
> > > >  
> > > > +#define GICV5_NO_READ_ALLOC		0b0
> > > > +#define GICV5_READ_ALLOC		0b1
> > > > +#define GICV5_NO_WRITE_ALLOC		0b0
> > > > +#define GICV5_WRITE_ALLOC		0b1  
> > > 
> > > Given these are being written to fields called _RA and _WA
> > > so the defines provide value over 0 and 1 in appropriate places?
> > > Maybe just about. Anyhow, your code so on this up to you.
> > >   
> > > > +
> > > > +#define GICV5_NON_CACHE			0b00
> > > > +#define GICV5_WB_CACHE			0b01
> > > > +#define GICV5_WT_CACHE			0b10
> > > > +
> > > > +#define GICV5_NON_SHARE			0b00
> > > > +#define GICV5_OUTER_SHARE		0b10
> > > > +#define GICV5_INNER_SHARE		0b11
> > > > +
> > > > +#define GICV5_IRS_IDR1			0x0004
> > > > +#define GICV5_IRS_IDR2			0x0008
> > > > +#define GICV5_IRS_IDR5			0x0014
> > > > +#define GICV5_IRS_IDR6			0x0018
> > > > +#define GICV5_IRS_IDR7			0x001c
> > > > +#define GICV5_IRS_CR0			0x0080
> > > > +#define GICV5_IRS_CR1			0x0084
> > > > +#define GICV5_IRS_SPI_SELR		0x0108
> > > > +#define GICV5_IRS_SPI_CFGR		0x0114
> > > > +#define GICV5_IRS_SPI_STATUSR		0x0118
> > > > +#define GICV5_IRS_PE_SELR		0x0140
> > > > +#define GICV5_IRS_PE_STATUSR		0x0144
> > > > +#define GICV5_IRS_PE_CR0		0x0148  
> > > 
> > > Blank line here as this is end of register offsets.  
> > 
> > Yep, fixed it.
> > 
> > Thanks for having a look !
> > Lorenzo
> > 
> > > > +#define GICV5_IRS_IDR1_PRIORITY_BITS	GENMASK(22, 20)
> > > > +#define GICV5_IRS_IDR1_IAFFID_BITS	GENMASK(19, 16)  
> > > 
> > > 
> > >   
> > 
> 


  reply	other threads:[~2025-05-29  9:40 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-13 17:47 [PATCH v4 00/26] Arm GICv5: Host driver implementation Lorenzo Pieralisi
2025-05-13 17:47 ` [PATCH v4 01/26] dt-bindings: interrupt-controller: Add Arm GICv5 Lorenzo Pieralisi
2025-05-20 20:43   ` Rob Herring (Arm)
2025-05-29 12:44   ` Lorenzo Pieralisi
2025-05-29 13:17     ` Peter Maydell
2025-05-29 14:21       ` Lorenzo Pieralisi
2025-05-29 14:30         ` Peter Maydell
2025-06-03  7:48       ` Lorenzo Pieralisi
2025-06-03  8:49         ` Peter Maydell
2025-06-03 15:15         ` Rob Herring
2025-06-03 15:36           ` Peter Maydell
2025-06-03 19:11             ` Rob Herring
2025-06-04  7:24               ` Lorenzo Pieralisi
2025-06-04 15:56                 ` Marc Zyngier
2025-06-04 16:35                   ` Lorenzo Pieralisi
2025-06-04 20:09                     ` Peter Maydell
2025-06-05  8:06                       ` Lorenzo Pieralisi
2025-06-03 15:53           ` Lorenzo Pieralisi
2025-06-03 16:04             ` Peter Maydell
2025-06-03 16:54               ` Lorenzo Pieralisi
2025-05-13 17:47 ` [PATCH v4 02/26] arm64/sysreg: Add GCIE field to ID_AA64PFR2_EL1 Lorenzo Pieralisi
2025-05-13 17:47 ` [PATCH v4 03/26] arm64/sysreg: Add ICC_PPI_PRIORITY<n>_EL1 Lorenzo Pieralisi
2025-05-13 17:47 ` [PATCH v4 04/26] arm64/sysreg: Add ICC_ICSR_EL1 Lorenzo Pieralisi
2025-05-13 17:47 ` [PATCH v4 05/26] arm64/sysreg: Add ICC_PPI_HMR<n>_EL1 Lorenzo Pieralisi
2025-05-13 17:47 ` [PATCH v4 06/26] arm64/sysreg: Add ICC_PPI_ENABLER<n>_EL1 Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 07/26] arm64/sysreg: Add ICC_PPI_{C/S}ACTIVER<n>_EL1 Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 08/26] arm64/sysreg: Add ICC_PPI_{C/S}PENDR<n>_EL1 Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 09/26] arm64/sysreg: Add ICC_CR0_EL1 Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 10/26] arm64/sysreg: Add ICC_PCR_EL1 Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 11/26] arm64/sysreg: Add ICC_IDR0_EL1 Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 12/26] arm64/sysreg: Add ICH_HFGRTR_EL2 Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 13/26] arm64/sysreg: Add ICH_HFGWTR_EL2 Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 14/26] arm64/sysreg: Add ICH_HFGITR_EL2 Lorenzo Pieralisi
2025-05-28 11:28   ` Jonathan Cameron
2025-05-28 14:30     ` Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 15/26] arm64: Disable GICv5 read/write/instruction traps Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 16/26] arm64: cpucaps: Rename GICv3 CPU interface capability Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 17/26] arm64: cpucaps: Add GICv5 CPU interface (GCIE) capability Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 18/26] arm64: smp: Support non-SGIs for IPIs Lorenzo Pieralisi
2025-05-14 10:39   ` Lorenzo Pieralisi
2025-05-14 16:05     ` Lorenzo Pieralisi
2025-05-28 12:17   ` Jonathan Cameron
2025-05-28 14:28     ` Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 19/26] arm64: Add support for GICv5 GSB barriers Lorenzo Pieralisi
2025-05-28 13:17   ` Jonathan Cameron
2025-05-28 14:34     ` Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 20/26] irqchip/gic-v5: Add GICv5 PPI support Lorenzo Pieralisi
2025-05-28 14:15   ` Jonathan Cameron
2025-05-29  7:57     ` Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 21/26] irqchip/gic-v5: Add GICv5 IRS/SPI support Lorenzo Pieralisi
2025-05-28 16:03   ` Jonathan Cameron
2025-05-29  8:38     ` Lorenzo Pieralisi
2025-05-29  8:45       ` Alireza Sanaee
2025-05-29  9:32         ` Lorenzo Pieralisi [this message]
2025-05-29 11:17           ` Alireza Sanaee
2025-05-13 17:48 ` [PATCH v4 22/26] irqchip/gic-v5: Add GICv5 LPI/IPI support Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 23/26] irqchip/gic-v5: Enable GICv5 SMP booting Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 24/26] irqchip/gic-v5: Add GICv5 ITS support Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 25/26] irqchip/gic-v5: Add GICv5 IWB support Lorenzo Pieralisi
2025-05-13 17:48 ` [PATCH v4 26/26] arm64: Kconfig: Enable GICv5 Lorenzo Pieralisi

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=aDgplizfKU/iFwe/@lpieralisi \
    --to=lpieralisi@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=alireza.sanaee@huawei.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jirislaby@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=robh@kernel.org \
    --cc=sascha.bischoff@arm.com \
    --cc=tglx@linutronix.de \
    --cc=timothy.hayes@arm.com \
    --cc=will@kernel.org \
    /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