On Thu, Aug 25, 2016 at 10:07:08AM +0200, Thomas Gleixner wrote: > Rich, > > On Wed, 24 Aug 2016, Rich Felker wrote: > > 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. > > I slowly get tired about your permanent ranting about misnamed, misdesigned > and unusable code in the kernel. This is the only instance I'm aware of, and my intent was not to rant. If you're aware of other cases where I've done this and it's come across abrasive to you or others, I'd appreciate it if you could point them out so I can try to avoid doing so in the future. As for this topic, what happened is that, after the first and second time of expressing confusion about how the infrastructure did not make sense and whether I should even be using it, I did not get anything resembling an explanation of why it's the way it is or why I might be wrong in thinking it's a bug, and so I went forward with the assumption that is was just a bug. Now that Mark Rutland has explained it well (and with your additional explanation below in your email), I see what the motivation was, but I still think it could be done in a less-confusing and more-consistent way that doesn't assume ARM-like irq architecture. > If your particular hardware has the old scheme of seperate interrupt numbers > for per cpu interrupts, then you can simply use the normal interrupt scheme > and request a seperate interrupt per cpu. Nominally it uses the same range of hardware interrupt numbers for all (presently both) cpus, but some of them get delivered to a specific cpu associated with the event (presently, IPI and timer; IPI is on a fixed number at synthesis time but timer is runtime configurable) while others are conceptually deliverable to either cpu (presently only delivered to cpu0, but that's treated as an implementation detail). It currently works requesting the irq with flags that ensure the handler runs on the same cpu it was delivered on, without using any other percpu irq framework. If you have concerns about ways this could break and want me to make the drivers do something else, I'm open to suggestions. Rich -- 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
