On 9/25/21 2:37 PM, Thomas Gleixner wrote: > On Sat, Sep 25 2021 at 23:21, Thomas Gleixner wrote: > >> On Sat, Sep 25 2021 at 12:48, Marc Zyngier wrote: >>> On Fri, 24 Sep 2021 18:05:38 +0100, Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: >>>> } >>>> +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
