08:24 <arnd> maz, mrutland: I'm trying to kill off the legacy irq entry in arch/arm/ to help with ardb's irqstack series: https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=randconfig-5.16-min

08:25 <arnd> one bit I'm still unsure about is how to deal with IRQ0 on iop32x, as this is considered a valid IRQ number by the platform but not the generic irq code

08:28 <arnd> I /think/ it broke in 2014 after a71b092a9c68 ("ARM: Convert handle_IRQ to use __handle_domain_irq") without anyone caring, but I want to make my version at least superficially sensible, and I need to decide whether to call the arm version of handle_IRQ() which rejects IRQ 0, or generic_handle_irq(), which just passes it into irq_to_desc() and hopes to get a valid descriptor out

08:29 <arnd> maz: is this broken in both cases, or does generic_handle_irq(0) have a chance of working?

09:14 <maz> arnd: it may have a chance to work it you're never using irq domains. the old way to sidestep the problem would be to offset all interrupts by 1, fixing up the offset when interacting with the interrupt controller.

09:14 <maz> work if*

09:15 <maz> but isn't iop32x dead already?

09:16 <arnd> There must have been a reason why we did not remove the platform last January when I went through them all, but it probably was a close call

09:17 <arnd> I know that the debian build infrastructure was a reason a few years ago, but they now build on 64-bit with chroot

09:18 <arnd> Rmk had a machine he was using, I should ask him if he still does

09:18 <arnd> Openwrt removed support a few years ago as well

09:18 <maz> even openwrt seems to have declared it as broken.

09:18 <maz> yup

09:42 <arnd> Apparently I concluded a year ago that there were still enough users. The Thecus N2100 is clearly one of the nicer ARMv5 platforms ever made, with 512MB of RAM and dual SATA, and probably more reliable than the Kirkwood. Whether those users still plan to do kernel updates in the future is another question

09:44 <arnd> maz: I think I'd just start with a patch to offset the interrupt numbers and then do my conversion on top. Do you think a71b092a9c68 ("ARM: Convert handle_IRQ to use __handle_domain_irq") is the correct reference if I want a Fixes tag, or should I just leave it out?

09:50 <maz> arnd: I don't think this commit broke it. we pass 'false' for lookup, so we won't hit any irqdomain, and we then perform the irqdesc lookup.

09:50 <maz> I definitely remember testing this stuff on non-DT platforms with 0 as a valid IRQ (I think it was a PXA270 at the time).

09:56 <arnd> maz: I don't see it yet. It looks like this would run into the 'if (!irq) ack_bad_irq(irq); else generic_handle_irq(irq);' from 76ba59f8366f ("genirq: Add irq_domain-aware core IRQ handler"), and fail there. Am I looking in the wrong place?

09:56 <maz> arnd: ah darn, you must be right.

09:57 <maz> I guess my testing wasn't that great at the time!

10:01 <arnd> maz: If I read this correctly, there is only one pxa board that uses the ssp3 irq: sound/soc/pxa/zylonite.c, the other boards use only the first two audio channels that have non-zero IRQs

10:03 <arnd> and this is only one of the reference boards, which I think in case of pxa are super rare compared to the commercial boards and pcketpc machines

10:03 <arnd> I'm not going to touch that one today

10:05 <maz> I use to have access to one of those, but I think the one I tested on was Zeus. And it is not unlikely that with NR_IRQS_LEGACY > 0, none of the SoC IRQs were anywhere near 0.

10:06 <arnd> actually, pxa is probably fine (at least now), because it seems to use domains correctly

11:58 <arnd> updated the branch now with the added iop32x patch, and managed to kill off handle_IRQ() as well

12:28 <broonie> arnd: The default audio on the Zylonite was AC'97 not SSP.

12:28 <broonie> SSP was only used if you replaced the audio module.