• G
    irqdomain: Refactor irq_domain_associate_many() · ddaf144c
    Grant Likely 提交于
    Originally, irq_domain_associate_many() was designed to unwind the
    mapped irqs on a failure of any individual association. However, that
    proved to be a problem with certain IRQ controllers. Some of them only
    support a subset of irqs, and will fail when attempting to map a
    reserved IRQ. In those cases we want to map as many IRQs as possible, so
    instead it is better for irq_domain_associate_many() to make a
    best-effort attempt to map irqs, but not fail if any or all of them
    don't succeed. If a caller really cares about how many irqs got
    associated, then it should instead go back and check that all of the
    irqs is cares about were mapped.
    
    The original design open-coded the individual association code into the
    body of irq_domain_associate_many(), but with no longer needing to
    unwind associations, the code becomes simpler to split out
    irq_domain_associate() to contain the bulk of the logic, and
    irq_domain_associate_many() to be a simple loop wrapper.
    
    This patch also adds a new error check to the associate path to make
    sure it isn't called for an irq larger than the controller can handle,
    and adds locking so that the irq_domain_mutex is held while setting up a
    new association.
    
    v3: Fixup missing change to irq_domain_add_tree()
    v2: Fixup x86 warning. irq_domain_associate_many() no longer returns an
        error code, but reports errors to the printk log directly. In the
        majority of cases we don't actually want to fail if there is a
        problem, but rather log it and still try to boot the system.
    Signed-off-by: NGrant Likely <grant.likely@linaro.org>
    
    irqdomain: Fix flubbed irq_domain_associate_many refactoring
    
    commit d39046ec72, "irqdomain: Refactor irq_domain_associate_many()" was
    missing the following hunk which causes a boot failure on anything using
    irq_domain_add_tree() to allocate an irq domain.
    Signed-off-by: NGrant Likely <grant.likely@linaro.org>
    Cc: Michael Neuling <mikey@neuling.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
    Cc: Thomas Gleixner <tglx@linutronix.de>,
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    ddaf144c
devicetree.c 8.4 KB