lkml.org 
[lkml]   [2019]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Is IRQ number 0 a valid IRQ ?
From
Date
Hi,

On 10/14/19 2:25 PM, Thomas Gleixner wrote:
> Hans,
>
> On Sat, 5 Oct 2019, Hans de Goede wrote:
>
>> This is something which I have been wondering for ever since there are
>> several places in the kernel where IRQ number 0 is treated as not being
>> valid (as no IRQ found mostly I guess). Where as other places do treat
>> IRQ number 0 as valid... ?
>
> IRQ0 is a historical x86 nuisance. On x86 irq0 is still valid - it's the
> legacy timer irq. I'd be happy to fix that up, but there are quite some
> assumptions vs. the irq numbering of the x86 legacy interrupt numbers in
> general. BIOS/ACPI has them hard coded as well, so it's not entirely
> trivial to fix that up.
>
> For everything else than x86 (and maybe ia64( irq 0 should not exist and DT
> based irq enumeration treated it as invalid interrupt number forever.
>
> Though there were some old ARM subarchs which used to have hardcoded legacy
> interrupt numbers including 0 as well.
>
>> Some examples which treat IRQ 0 special:
>>
>> drivers/base/platform.c: __platform_get_irq() :
>>
>> if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node) {
>> int ret;
>>
>> ret = of_irq_get(dev->dev.of_node, num);
>> if (ret > 0 || ret == -EPROBE_DEFER)
>> return ret;
>> }
>>
>> Note if (ret > 0) not if (ret >= 0)
>
> Yeah. It makes the code fall through when ret == 0 so it can try the other
> methods. What a mess...
>
>> Other example: drivers/usb/dwc3/gadget.c: dwc3_gadget_get_irq() :
>>
>> if (!irq)
>> irq = -EINVAL;
>
> That one translates irq0 into an error code.
>
>> So 2 questions:
>>
>> 1) Is this special handling of IRQ number 0 valid code, or just
>> mostly some leftover from older days when IRQ number 0 was maybe
>> special ?
>
> Kinda both.
>
>> 2) Either way (*) I think we (I volunteer) should document this somewhere,
>> other then adding a note about this to the platform_get_irq docs any
>> other place where it would be good to specify this?
>>
>> *) Either IRQ number 0 is not special and then we need to stop the
>> cargo-culting of treating it special, or it is special and then we
>> need to document that.
>
> One way to solve it would be to change the '0' return value from the core
> functions (irqdomain) to -EINVAL or such, but that needs some thorough
> analysis whether there is valid irq 0 usage outside of x86/ia64.

I see, so the TL;DR: is its complicated. So I guess it is best to leave
this as is, thank you for your explanation.

Regards,

Hans

\
 
 \ /
  Last update: 2019-10-16 10:43    [W:0.075 / U:3.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site