irqchip/gic-v3-its: Move allocation outside mutex

There's no reason to do the allocation of the new lpi_range inside the
lpi_range_lock. One could change the code to avoid the allocation
altogether in case the freed range can be merged with one or two
existing ranges (in which case the allocation would naturally be done
under the lock), but it's probably not worth complicating the code for
that.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 8d5936c899a66dd7615fbc2c5117214d6db5dada..be6ecd9b75da401e31be37a763795ea69aa374aa 100644 (file)
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1532,22 +1532,19 @@ static int alloc_lpi_range(u32 nr_lpis, u32 *base)
 static int free_lpi_range(u32 base, u32 nr_lpis)
 {
        struct lpi_range *new;
-       int err = 0;
-
-       mutex_lock(&lpi_range_lock);
 
        new = mk_lpi_range(base, nr_lpis);
-       if (!new) {
-               err = -ENOMEM;
-               goto out;
-       }
+       if (!new)
+               return -ENOMEM;
+
+       mutex_lock(&lpi_range_lock);
 
        list_add(&new->entry, &lpi_range_list);
        list_sort(NULL, &lpi_range_list, lpi_range_cmp);
        merge_lpi_ranges();
-out:
+
        mutex_unlock(&lpi_range_lock);
-       return err;
+       return 0;
 }
 
 static int __init its_lpi_init(u32 id_bits)