On Mon, Jan 29, 2007 at 03:47:59PM +0100, Konstantin Kletschke wrote: > Am 2007-01-05 19:01 +0100 schrieb Pavel Pisa: > > > It applies only for interrupts going through GPIO layer. > > The problem has been noticed by Konstantin Kletschke > > some time ago. > > > > No IRQF_TRIGGER set_type function for IRQ 26 (MPU) > > Yes. I reported this also. > > > drivers/serial/imx.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > Index: linux-2.6.19-rt/drivers/serial/imx.c > > =================================================================== > > +++ linux-2.6.19-rt/drivers/serial/imx.c > > @@ -403,7 +403,8 @@ static int imx_startup(struct uart_port > > if (retval) goto error_out2; > > > > retval = request_irq(sport->rtsirq, imx_rtsint, > > - IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, > > + (sport->rtsirq < IMX_IRQS) ? 0 : > > + IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, > > DRIVER_NAME, sport); > > if (retval) goto error_out3; > > > Okay, this indeed fixes my > > No IRQF_TRIGGER set_type function for IRQ 26 (MPU)
Is it really worth adding additional code to shut up this (imho) silly warning? It's just adding needless complexity to drivers. What happens if a driver is used on multiple platforms, some of which support trigger setting and others which don't? Are we going to end up with a large #ifdef in every driver? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
