On Thu, Aug 25, 2016 at 10:07:08AM +0200, Thomas Gleixner wrote:

Rich,

On Wed, 24 Aug 2016, Rich Felker wrote:

quoted

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html