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

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

From: Rich Felker <dalias@libc.org>
Date: 2016-07-27 17:08:34
Also in: linux-sh, lkml

On Wed, Jul 27, 2016 at 02:27:54PM +0100, Mark Rutland wrote:
On Wed, Jul 27, 2016 at 09:08:21AM -0400, Rich Felker wrote:
quoted
On Wed, Jul 27, 2016 at 11:15:38AM +0100, Mark Rutland wrote:
quoted
On Wed, Jul 27, 2016 at 05:35:09AM +0000, Rich Felker wrote:
quoted
For simplicity, there is no aic1-specific logic in the driver beyond
setting the priority register, which is necessary for interrupts to
work at all. Eventually aic1 will likely be phased out, but it's
currently in use in deployments and all released bitstream binaries.
[...]
quoted
+	if (!of_device_is_compatible(node, "jcore,aic2")) {
If this is only meant to run for AIC1, it would be better to check for
the "jcore,aic1" compatible string explicitly.

While that shouldn't matter much currently, it better matches the intent
described in the commit message, and avoids surprises and/or churn in
future if you have AIC3+.
My intent in doing this was to support a DT that might claim an aic2
is aic1-compatible as a fallback "compatible" property. The hardware
is designed such that this works (ignoring the spurious writes to
unused prio registers) as long as the DT still has the right irq
numbers for attached devices.
Ok.

If the HW ignores it, what's the cost of those one-off spurious writes?
If it's not noticeable, you could allow the kernel to perform them
regardless.
Indeed, it essentially costs nothing. My motivation was more just to
document that it's not needed/used for aic2.
Otherwise, please add a comment above the check, explaining why we do
the check this way around.
Since the intent is documenting this might be the best approach.

Rich
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help