On Tue, Dec 2, 2014 at 7:32 PM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > Hi Linus, Alexandre, > > On Fri, Nov 28, 2014 at 11:29 AM, Linus Walleij > <linus.walleij@xxxxxxxxxx> wrote: >> On Wed, Nov 19, 2014 at 8:51 AM, Alexandre Courbot <acourbot@xxxxxxxxxx> wrote: >>> Replace the ARCH_NR_GPIOS-sized static array of GPIO descriptors by >>> dynamically-allocated arrays for each GPIO chip. >>> >>> This change makes gpio_to_desc() perform in O(n) (where n is the number >>> of GPIO chips registered) instead of O(1), however since n is rarely >>> bigger than 1 or 2 no noticeable performance issue is expected. >>> Besides this provides more incentive for GPIO consumers to move to the >>> gpiod interface. One could use a O(log(n)) structure to link the GPIO >>> chips together, but considering the low limit of n the hypothetical >>> performance benefit is probably not worth the added complexity. >>> >>> This patch uses kcalloc() in gpiochip_add(), which removes the ability >>> to add a chip before kcalloc() can operate. I am not aware of such >>> cases, but if someone bisects up to this patch then I will be proven >>> wrong... >>> >>> Signed-off-by: Alexandre Courbot <acourbot@xxxxxxxxxx> >> >> OK patch applied. Let's see if the world explodes. > > This patch changes a return value from -EPROBE_DEFER to -EINVAL in > regulator-gpio when a GPIO cannot be found yet, causing probe failures > on r8a7791/koelsch: Hi Geert, Thanks for signaling this. I think I understand what is going wrong and will send a fixup patch in a few minutes. Cheers, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html