Skip to content
  • Anatolij Gustschin's avatar
    gpio: mpc8xxx: don't set IRQ_TYPE_NONE when creating irq mapping · de0ccf78
    Anatolij Gustschin authored
    Exporting gpios over sysfs GPIO interface throws genirq
    error messages, i.e. on an mpc5121 based board exporting
    GPIO 5 triggers it:
    
        # echo 229 > /sys/class/gpio/export
        genirq: Setting trigger mode 0 for irq 44 failed
        (mpc512x_irq_set_type+0x0/0x18c)
    
    Similar error messages appear in the kernel boot log since the
    board specifies GPIOs for matrix keypad and also SD Card write
    protect and card detect GPIOs in its device tree. For all these
    GPIOs there is an error message in the log.
    
    The issue is triggered by setting the irq type to IRQ_TYPE_NONE
    in the driver's irq_domain map function mpc8xxx_gpio_irq_map().
    
    ...
      mpc8xxx_gpio_irq_map
        irq_set_irq_type
          __irq_set_trigger
    
    __irq_set_trigger() calls irq_set_type() callback of the mpc8xxx gpio
    irq chip with the IRQ_TYPE_NONE in its 'flags' argument. This callback
    is either mpc8xxx_irq_set_type() or mpc512x_irq_set_type(). Both these
    functions return -EINVAL in the case if IRQ_TYPE_NONE is passed in the
    flow_type argument. This return value triggers the observed error
    message in __irq_set_trigger(). Modifying these callbacks to not
    return an error in IRQ_TYPE_NONE case doesn't make any sense to me.
    The line setting IRQ_TYPE_NONE type has been originally added by
    commit 345e5c8a
    
     "powerpc: Add interrupt support to mpc8xxx_gpio".
    At this time set_irq_type() checked its type argument and returned 0
    if the type argument didn't specify any meaningful type in its type
    sense bits (and thus was equal to IRQ_TYPE_NONE). Effectively this
    line was a nop and I wonder what was the point of adding it.
    
    Remove IRQ_TYPE_NONE setting in the irq_domain mapping function.
    
    Signed-off-by: default avatarAnatolij Gustschin <agust@denx.de>
    Acked-by: default avatarPeter Korsgaard <jacmet@sunsite.dk>
    Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
    de0ccf78