On Wed, 25 Jul 2018, Christoph Hellwig wrote: > On Wed, Jul 25, 2018 at 12:18:39PM +0100, Marc Zyngier wrote: > > This feels odd. It means that you cannot have the following sequence: > > > > local_irq_disable(); > > enable_irq(x); // where x is owned by a remote hart > > > > as smp_call_function_single() requires interrupts to be enabled. > > > > More fundamentally, why are you trying to make these interrupts look > > global while they aren't? arm/arm64 have similar restrictions with GICv2 > > and earlier, and treats these interrupts as per-cpu. > > > > Given that the drivers that deal with drivers connected to the per-hart > > irqchip are themselves likely to be aware of the per-cpu aspect, it > > would make sense to align things (we've been through that same > > discussion about the clocksource driver a few weeks back). > > Right now the only direct consumers are said clocksource, the PLIC > driver later in this series and the RISC-V arch IPI code. None of them > is going to do a manual enable_irq, so I guess the remote case of the > code is simply dead code. I'll take a look at converting them to > per-cpu. I guess the GICv2 driver is the best template? Confused. The timer and the IPI are separate causes and have nothing to do with the per cpu irq domain. That's what the low level interrupt handling code tells me. If I understand correctly then the per cpu irq domain is for device interrupts, right? If so, then this simply cannot work and there is no way to make it work with per cpu interrupts either. Is there some high level documentation about the design (or the lack of) or can someone give a concise explanation how this stuff is supposed to work? Thanks, tglx -- 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
