Am 28.07.2013 20:50, schrieb Javier Martinez Canillas:
On Sun, Jul 28, 2013 at 8:06 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
On Sun, Jul 28, 2013 at 6:45 PM, Alexander Holler <holler@xxxxxxxxxxxxx> wrote:
Am 28.07.2013 18:25, schrieb Linus Walleij:
On Sun, Jul 28, 2013 at 4:25 PM, Alexander Holler <holler@xxxxxxxxxxxxx> wrote:
By the way, if someone decides to touch omap_hsmmc, the driver wrongly
assumes that 0 is not a valid IRQ number and it doesn't check if
gpio_to_irq() returns a negative value. ;)
Zero *is* *not* a valid IRQ number.
Where is that mentioned?
This has been a major debate in the kernel in recent months, and we are
agreed to remove 0 as a valid Linux IRQ number. The fact that up until
two years ago the ARM kernel allowed it is a historical artifact.
Please see this article for background:
http://lwn.net/Articles/470820/
Which falls back to this posting from Torvalds:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-11/7628.html
gpio.txt states:
----
Non-error values returned from gpio_to_irq() can be passed to request_irq()
or free_irq(). They will often be stored into IRQ resources for platform
While IRQ 0 is not an error, it means that this particular GPIO line
does not have an IRQ, or cannot be translated into an IRQ, and
should not be passed to request_irq().
Patches to the documentation is welcome.
With the new patches gpio_to_irq() returns 0.
This is not good. Under which circumstances does that happen?
Documentation/IRQ-domain.txt:
----
The legacy map should only be used if fixed IRQ mappings must be
supported. For example, ISA controllers would use the legacy map for
mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
numbers.
----
You see the 0 too?
Is OMAP still using the legacy map? I don't think that works
on any system utilizing the GIC driver. It is called legacy because
it is not supposed to be used :-/
Not anymore, it was changed recently to use the linear domain mapping
instead in commit ede4d7a5 ("gpio/omap: convert gpio irq domain to
linear mapping").
I don't really care which mapping is in place. I just care if zero is a
valid IRQ number for the IRQ and related APIs. And I have to assume that
those APIs don't switch their internal handling because of the irq
mapping in place.
Of course, having zero as an invalid IRQ number is a handy thing, but I
just didn't find a place where this is written down. And the usually
numbering in IT (starting at zero) makes it very likely that zero could
be valid IRQ number.
The commit message says Reported-by: Linus Walleij
<linus.walleij@xxxxxxxxxx> ;-)
Of ourse, I might be wrong, but you just stated that 0 isn't valid, and
I would be happy to find a source for your statement.
See above.
Yeah, as usual, some mail, discussion, thread, article or similiar in
the small internet everyone has memorized in full. ;)
Once, a maintainer refered me to a discussion and commit which happend
10 years ago and it sounded like I'm a morron because I didn't know that. ;)
Thanks a lot for the article about NO_IRQ, it describes the pit I fell
into too, very good.
Maybe it might be worth to suggest using/returning NO_IRQ in (new)
patches instead of zero. That would make it very clear that the value 0
isn't to be used later.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
