[PATCH v3 1/3] test: gpio: include in build, and fixup bitrot
Rasmus Villemoes
ravi at prevas.dk
Tue Nov 4 18:44:56 CET 2025
Commit ebaa3d053e5 ("test: fix CONFIG_ACPIGEN dependencies"), which
got into v2022.10-rc1, accidentally left out a $
before (CONFIG_DM_GPIO), with the effect that test/dm/gpio.c has not
been built for three years.
Unsurprisingly, the code in there has bit-rotted.
- There's a missing ; causing plain build fail.
That code was added in 9bf87e256c2 ("test: dm: update test for
open-drain/open-source emulation in gpio-uclass"), which was part of
v2020.07-rc3, i.e. long before the commit causing gpio.c to not be
built at all. It did build at that time, but also, the missing
semicolon wasn't found when fa847bb409d ("test: Wrap assert macros
in ({ ... }) and fix missing semicolons") happened in 2023.
- Commit 592b6f394ae ("led: add function naming option from linux")
bumped sandbox,gpio-count for bank gpio_a in test.dts to 25, but
didn't update the expected global gpio numbers accordingly.
- The "lookup by label" test likely worked when it was added, but then I
inadvertently broke it when I noticed that dm_gpio_lookup_label()
seemed to be broken in commit 10e66449d7e ("gpio-uclass: fix gpio
lookup by label") - which landed in v2023.01-rc1, so after gpio.c
was no longer being built.
The "label" (which is a u-boot concept) that a "hogged gpio" gets is
<gpio hog node name>.gpio-hog, which is why it used to work with the
strncmp() but doesn't with strcmp().
We can either revert 10e66449d7e or append the ".gpio-hog" suffix as
done below. I don't really have a dog in that race; when I did
10e66449d7e, it was because I thought the "lookup by label" was
actually about the standardized gpio-line-names property, but then I
learnt it was not, so is not at all useful to me.
- The leak check now fails.
Test: gpio_leak: gpio.c
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a95b0 (2790832), got 0x2a9650 (2790992)
test/dm/gpio.c:328, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
Test: gpio_leak: gpio.c (flat tree)
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a9650 (2790992), got 0x2a9700 (2791168)
test/dm/gpio.c:328, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
And it fails with the same differences (160/176) even if I
remove the three lines that actually exercise any of the gpio code,
i.e. make the whole function amount to
ut_assertok(dm_leak_check_end(uts));
Test: gpio_leak: gpio.c
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a95b0 (2790832), got 0x2a9650 (2790992)
test/dm/gpio.c:325, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
Test: gpio_leak: gpio.c (flat tree)
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a9650 (2790992), got 0x2a9700 (2791168)
test/dm/gpio.c:325, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
So I suspect that the leak is somewhere in the test framework
setup/teardown code - dm_leack_check_end() isn't really used
anywhere else except in a dm/core test. Bisecting to figure out
where that was introduced is somewhat of a hassle because of the
other bitrot, and because of the SWIG failure that makes it very
hard to build older U-Boots.
So since it's better to have most of the gpio tests actually
working instead of leaving all of gpio.c as dead code, #if 0 that
part out and leave it as an archeological exercise.
Signed-off-by: Rasmus Villemoes <ravi at prevas.dk>
---
test/dm/Makefile | 2 +-
test/dm/gpio.c | 13 ++++++++-----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 2db0e3b8dfd..a261b3fb4b7 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -25,7 +25,7 @@ ifeq ($(CONFIG_ACPIGEN),y)
obj-y += acpi.o
obj-y += acpigen.o
obj-y += acpi_dp.o
-obj-(CONFIG_DM_GPIO) += gpio.o
+obj-$(CONFIG_DM_GPIO) += gpio.o
obj-y += irq.o
endif
obj-$(CONFIG_ADC) += adc.o
diff --git a/test/dm/gpio.c b/test/dm/gpio.c
index b45946c143c..34a5d1a974e 100644
--- a/test/dm/gpio.c
+++ b/test/dm/gpio.c
@@ -29,14 +29,14 @@ static int dm_test_gpio(struct unit_test_state *uts)
/*
* We expect to get 4 banks. One is anonymous (just numbered) and
- * comes from plat. The other are named a (20 gpios),
+ * comes from plat. The other are named a (25 gpios),
* b (10 gpios) and c (10 gpios) and come from the device tree. See
* test/dm/test.dts.
*/
ut_assertok(gpio_lookup_name("b4", &dev, &offset, &gpio));
ut_asserteq_str(dev->name, "extra-gpios");
ut_asserteq(4, offset);
- ut_asserteq(CONFIG_SANDBOX_GPIO_COUNT + 20 + 4, gpio);
+ ut_asserteq(CONFIG_SANDBOX_GPIO_COUNT + 25 + 4, gpio);
name = gpio_get_bank_info(dev, &offset_count);
ut_asserteq_str("b", name);
@@ -110,7 +110,7 @@ static int dm_test_gpio(struct unit_test_state *uts)
name = gpio_get_bank_info(dev, &offset_count);
ut_asserteq_str("a", name);
- ut_asserteq(20, offset_count);
+ ut_asserteq(25, offset_count);
/* add gpio hog tests */
ut_assertok(gpio_hog_lookup_name("hog_input_active_low", &desc));
@@ -135,7 +135,7 @@ static int dm_test_gpio(struct unit_test_state *uts)
ut_asserteq(0, dm_gpio_get_value(desc));
/* Check if lookup for labels work */
- ut_assertok(gpio_lookup_name("hog_input_active_low", &dev, &offset,
+ ut_assertok(gpio_lookup_name("hog_input_active_low.gpio-hog", &dev, &offset,
&gpio));
ut_asserteq_str(dev->name, "base-gpios");
ut_asserteq(10, offset);
@@ -161,7 +161,7 @@ static int dm_test_gpio_opendrain_opensource(struct unit_test_state *uts)
ut_asserteq_str("pinmux-gpios", gpio_c->name);
ut_asserteq(8, gpio_request_list_by_name(dev, "test3-gpios", desc_list,
- ARRAY_SIZE(desc_list), 0))
+ ARRAY_SIZE(desc_list), 0));
ut_asserteq(true, !!device_active(gpio_c));
ut_asserteq_ptr(gpio_c, desc_list[0].dev);
@@ -309,6 +309,8 @@ static int dm_test_gpio_copy(struct unit_test_state *uts)
DM_TEST(dm_test_gpio_copy, UTF_SCAN_PDATA | UTF_SCAN_FDT);
/* Test that we don't leak memory with GPIOs */
+/* Disabled for now as there seems to be a leak in the test framework itself. */
+#if 0
static int dm_test_gpio_leak(struct unit_test_state *uts)
{
ut_assertok(dm_test_gpio(uts));
@@ -319,6 +321,7 @@ static int dm_test_gpio_leak(struct unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_gpio_leak, UTF_SCAN_PDATA | UTF_SCAN_FDT);
+#endif
/* Test that we can find GPIOs using phandles */
static int dm_test_gpio_phandles(struct unit_test_state *uts)
--
2.51.0
More information about the U-Boot
mailing list