[PATCH 18/24] irqchip/gic-v5: Add GICv5 PPI support

[Lorenzo Pieralisi]

On Wed, Apr 09, 2025 at 09:30:52AM +0200, Lorenzo Pieralisi wrote:

[...]

> > > +static int __init gicv5_of_init(struct device_node *node,
> > > +				struct device_node *parent)
> > > +{
> > > +	int ret;
> > > +
> > > +	ret = gicv5_init_domains(&node->fwnode);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	gicv5_set_cpuif_pribits();
> > > +
> > > +	ret = gicv5_starting_cpu(smp_processor_id());
> > 
> > You invoke the CPU hotplug callback for the boot CPU explicitly, but
> > what the heck installs the actual hotplug callback for the secondary
> > CPUs?
> 
> That comes with a subsequent patch[21]. I mentioned in the cover letter
> that I tried to split the functionality into interrupt types to ease
> review (well, it does not look like I succeeded, sorry) and then in
> patch [21] (when LPIs backing IPIs are implemented), enable SMP.
> 
> The point is, we need patches [18-21] to enable SMP booting.
> 
> I can squash [18-21] all together or I can enable the hotplug callback
> here but this patch stand alone is not functional for the reasons
> above, let me know please what's best in your opinion and I will do.

I would squash patches [18-21] for v2 because that's the only option to
have a single logical and functional SMP working entity, unless you are
against it.

We need IPIs for SMP booting, those are built on LPIs that in turn
requires the IRS code to function - I tried to split all this code
but whatever I came up with makes no sense from a functional
perspective.

The only thing I could do is taking SPI enablement code (SPI IRQs are
optional) out of [18-21] and make it a separate patch, to be honest
SPI management I don't think it is a lot of code so that won't change
much IMO.

Please let me know, thanks a lot.

Lorenzo