Is IRQ number 0 a valid IRQ ?

Is IRQ number 0 a valid IRQ ?

[Hans de Goede]

Hi Thomas,

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... ?

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)

Other example: drivers/usb/dwc3/gadget.c: dwc3_gadget_get_irq() :

         if (!irq)
                 irq = -EINVAL;

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 ?

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?

Regards,

Hans


*) 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.

Re: Is IRQ number 0 a valid IRQ ?

[Thomas Gleixner]

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.

Thanks,

	tglx

Re: Is IRQ number 0 a valid IRQ ?

[Hans de Goede]

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