On 9/25/21 2:37 PM, Thomas Gleixner wrote:

On Sat, Sep 25 2021 at 23:21, Thomas Gleixner wrote:

quoted

On Sat, Sep 25 2021 at 12:48, Marc Zyngier wrote:

quoted

On Fri, 24 Sep 2021 18:05:38 +0100, Florian Fainelli [off-list ref] wrote:

quoted

 }
+EXPORT_SYMBOL_GPL(irq_set_affinity_locked);

This doesn't seem right.

This driver seem to try and move interrupts on its own when the CPU
goes down. Why can't it rely on the normal CPU hotplug infrastructure
to do so like all the other drivers (bar some Cavium driver that does
the same thing)?

I'd rather you take this opportunity to move these drivers into the
21st century, so that we can kill irq_cpu_offline() and co altogether.

I wanted to kill these callbacks years ago. Cavium has two variants of
those offline/online callbacks:

 1) octeon_irq_cpu_offline_ciu() which is doing the same as that BCM
    driver. These really can go away. Just remove the callback and
    everything just works.

For BCM this works today when that chip is used on ARM[64] simply
because the only architecture which invokes irq_cpu_offline() is MIPS.

That is correct. How would you recommend addressing that? In premise
when this driver is used on ARM[64] it is used as a second level
interrupt controller hanging off the ARM GIC (or another ARM CPU
interrupt controller), so in that case I suppose I could make the
irq_set_cpu_offline be dependent upon CONFIG_SMP and CONFIG_MIPS, would
that be acceptable?
-- 
Florian