On Thu, 17 Mar 2016, Jon Hunter wrote: > Setting the interrupt type for private peripheral interrupts (PPIs) may > not be supported by a given GIC because it is IMPLEMENTATION DEFINED > whether this is allowed. There is no way to know if setting the type is > supported for a given GIC and so the value written is read back to > verify it matches the desired configuration. If it does not match then > an error is return. > > There are cases where the interrupt configuration read from firmware > (such as a device-tree blob), has been incorrect and hence > gic_configure_irq() has returned an error. This error has gone > undetected because the error code returned was ignored but the interrupt > still worked fine because the configuration for the interrupt could not > be overwritten. > > Given that this has done undetected and we should only fail to set the > type for PPIs whose configuration cannot be changed anyway, don't return > an error and simply WARN if this fails. This will allows us to fix up any > places in the kernel where we should be checking the return status and > maintain back compatibility with firmware images that may have incorrect > interrupt configurations. Though silently returning 0 is really the wrong thing to do. You can add the warn, but why do you want to return success? Thanks, tglx -- 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
