[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090614234546.GJ3639@local>
Date: Mon, 15 Jun 2009 01:45:46 +0200
From: "Hans J. Koch" <hjk@...utronix.de>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: "Hans J. Koch" <hjk@...utronix.de>,
Wolfram Sang <w.sang@...gutronix.de>,
linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
devicetree-discuss@...abs.org, Magnus Damm <magnus.damm@...il.com>,
Greg KH <gregkh@...e.de>
Subject: Re: [PATCH 2/2] uio: add an of_genirq driver
On Mon, Jun 15, 2009 at 12:12:07AM +0100, Alan Cox wrote:
> > > + if (!uioinfo->irq)
> > > + uioinfo->irq = UIO_IRQ_NONE;
> >
> > Please don't do this. It's inconsistent if all other UIO drivers require
> > people to use UIO_IRQ_NONE and you also allow zero. UIO_IRQ_NONE was
> > introduced because 0 may be a legal interrupt number on some platforms.
>
> Zero is not a valid IRQ number in the kernel (except in arch specific
> depths). IRQ numbers are also *unsigned* so -1 isn't a safe definition.
The above uioinfo->irq is a signed long.
>
> Zero means no IRQ. If any old UIO code is assuming otherwise it wants
> fixing.
It doesn't. It won't complain about IRQ 0 and will pass it on to
request_irq, which will probably fail if it is as you say.
I did it that way because I saw IRQ 0 in /proc/interrupts on every PC...
>
> It is the job of the platform to map a physical IRQ 0 to some other
> representation if it exists outside of arch specific code.
Funny.
> This was
> decided some years ago and a large part of the kernel simply doesn't
> support any notion of a real IRQ 0.
Can you tell me the reason for that decision or point me to some ml archive?
Thanks,
Hans
>
> Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists