On 20/04/2023 00.40, Simon Glass wrote:

On Wed, 19 Apr 2023 at 22:11, Rasmus Villemoes rasmus.villemoes@prevas.dk wrote:

...

By the time we jump to the err label, count represents the number of gpios we've succesfully requested. So by subtracting one, we fail to free the most recently requested.

Signed-off-by: Rasmus Villemoes rasmus.villemoes@prevas.dk

drivers/gpio/gpio-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass sjg@chromium.org

Could the tests catch this bug?

Perhaps, I don't have time to run this through, but something like

diff --git a/test/dm/gpio.c b/test/dm/gpio.c index 0d88ec24bd..45620c1dde 100644 --- a/test/dm/gpio.c +++ b/test/dm/gpio.c @@ -348,6 +348,12 @@ static int dm_test_gpio_phandles(struct unit_test_state *uts) ut_asserteq(-ENOENT, gpio_request_by_name(dev, "test-gpios", 5, &desc, 0));

+ ut_assertok(gpio_request_by_name(dev, "test-gpios", 1, &desc_list[1], 0)); + ut_asserteq(-EBUSY, gpio_request_list_by_name(dev, "test-gpios", + desc_list2, 2, 0)); + ut_assertok(gpio_request_by_name(dev, "test-gpios", 0, &desc_list[0], 0)); + ut_assertok(gpio_free_list(dev, desc_list, 2)); + /* Last GPIO is ignored as it comes after <0> */ ut_asserteq(3, gpio_request_list_by_name(dev, "test-gpios", desc_list, ARRAY_SIZE(desc_list), 0));

might do it. Feel free to turn that into a real patch if it works (i.e. detects the bug without the fix).

Rasmus