Hello Thomas, On Mon, Mar 18, 2013 at 02:20:26PM +0100, Uwe Kleine-König wrote: > This interrupt controller is found on Cortex-M3 and Cortex-M4 machines. > > Support for this controller appeared in Catalin's Cortex tree based on > 2.6.33 but was nearly completely rewritten. > > Signed-off-by: Catalin Marinas <catalin.mari...@arm.com> > Signed-off-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de> > --- > Hello, > > changes since v1: > > - fixed base address to match documentation > So reading ICTR (which isn't in the nvic's address range) uses a new > #define > in asm/v7m.h which isn't in mainline yet. That's ugly but I don't have a > better idea how to solve it without platform code. > - s/NVIC_IPRI/NVIC_IPR/ to match documentation > - use pr_warn instead of WARN/WARN_ON > - do proper error handling, don't use IS_ERR_VALUE > - drop the wrong skipping of the 16 system exceptions. They are not counted > in > ICTR_INTLINESNUM. > - dynamically allocate chip data > - drop the irq_domain* member from chip data as it's only used in the probe > callback > - change compatible string to arm,armv7m-nvic > - drop a few unused #includes, use some linux/ #includes instead of asm/ ones > - change indention to please tglx' eyes > > A failure to probe the nvic makes the machine unresponsive. Does this > have any implications on how the driver should behave when something > goes wrong? Another issue is that up to now the exception handling > simply calls asm_do_IRQ(16, ..) for the first nvic interrupt. So there > is a mismatch if irq_alloc_descs_from(16, ...) doesn't return 16. I > added error handling for that assuming that's fine for now, but in the long > run > a better fix would be nice. What is the preferred approach to fix that? Use a > global variable that holds the irq_base? Or should I use a mapping function > instead? I didn't hear back from you since I sent out v2. Do you still have some concerns?
I intend to put the Cortex-M3 stuff into next. Assuming it's just lack of time on your side that stops you from commenting, would you mind if I put this patch into next, too? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/