From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver Date: Wed, 24 Aug 2016 20:01:52 +0100 Message-ID: <20160824200152.33be0707@arm.com> References: <57BDCE5D.2050609@linaro.org> <20160824174001.GW15995@brightrain.aerifal.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160824174001.GW15995-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rich Felker Cc: Daniel Lezcano , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring , Mark Rutland , Thomas Gleixner List-Id: devicetree@vger.kernel.org On Wed, 24 Aug 2016 13:40:01 -0400 Rich Felker 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html