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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]