Thread (16 messages) 16 messages, 2 authors, 2016-07-28

Re: [PATCH v4 2/2] irqchip: add J-Core AIC driver

From: Rich Felker <hidden>
Date: 2016-07-27 13:06:15
Also in: linux-sh, lkml

On Wed, Jul 27, 2016 at 11:12:36AM +0100, Mark Rutland wrote:
On Wed, Jul 27, 2016 at 05:35:09AM +0000, Rich Felker wrote:
quoted
+int __init aic_irq_of_init(struct device_node *node, struct device_node *parent)
+{
+	struct aic_data *aic = &aic_data;
+	unsigned min_irq = 64;
+
+	pr_info("Initializing J-Core AIC\n");
+
+	if (!of_device_is_compatible(node, "jcore,aic2")) {
+		unsigned cpu;
+		for_each_possible_cpu(cpu) {
+			void __iomem *base = of_iomap(node, cpu);
+			if (!base)
+				continue;
This sounds like it would be a critical error.

It would be best to at least pr_warn() if you can't map a CPU's AI
interface.
It's looping over possible cpus (per the kernel configuration for max
cpus) so it's expected that a system with fewer cpus will also have
fewer reg ranges for the aic. This is not an error. If you think
there's a different/better way I should write this code, I'm open to
suggestions.
quoted
+			pr_info("Local AIC1 enable for cpu %u at %p\n",
+				cpu, base + AIC1_INTPRI);
+			__raw_writel(0xffffffff, base + AIC1_INTPRI);
+		}
Here base goes out of scope. If you don't need it, it would be best
practice to iounmap it (even if that happens to be a no-op on your
arch).
OK. I can add that.
quoted
+		min_irq = 16;
+	}
+
+	aic->chip.name = node->name;
It's probably best to give the name explicitly in the driver (e.g.
"AIC"), rather than taknig whatever happens to be in the DT (which
should be 'interrupt-controller@<addr>'.
OK.
quoted
+	aic->chip.irq_mask = noop;
+	aic->chip.irq_unmask = noop;
If the core code wants to mask IRQs, how do you handle that? Can you
mask your CPU traps?
There's a global imask in the cpu that masks all interrupts that's
used in the trap entry point, spinlocks, etc. already. This is a cpu
standard feature and not logically part of the AIC. My understanding
is that the kernel already keeps a logical mask of disabled irqs in
addition to mask/disable at the irqchip level so there's a fairly fast
path for ignoring/holding (potentially spurious) irqs while they're
supposed to be disabled and deferring them until they're enabled
again.

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help