On Wed, 24 Aug 2016 13:40:01 -0400 Rich Felker <dalias@xxxxxxxx> wrote: [...] > > IIUC, there is a problem with the interrupt controller where the per irq > > line are not working correctly. Is that correct ? > > I don't think that's a correct characterization. Rather the percpu > infrastructure just means something completely different from what you > would expect it to mean. It has nothing to do with the hardware but > rather with kernel-internal choice of whether to do percpu devid > mapping inside the irq infrastructure, and the choice at the > irq-requester side of whether to do this is required to match the > irqchip driver's choice. I explained this better in another email > which I could dig up if necessary, but the essence is that > request_percpu_irq is a misnamed and unusably broken API. Or just one that simply doesn't fit your needs, because other architectures have different semantics than the ones you take for granted? > > > Regarding Marc Zyngier comments about the irq controller driver being > > almost empty, I'm wondering if something in the irq controller driver > > which shouldn't be added before submitting this timer driver with SMP > > support (eg. irq domain ?). > > I don't think so. At most I could make the driver hard-code the percpu > devid model for certain irqs, but that _does not reflect_ anything > about the hardware. Rather it just reflects bad kernel internals. It I'd appreciate it if instead of ranting about how broken the kernel is, you'd submit a patch fixing it, since you seem to have spotted something that we haven't in several years of using that code on a couple of ARM-related platforms. Thanks, M. -- Jazz is not dead. It just smells funny. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
