u-boot.git/test/dm/gpio.c, branch master

test: gpio: add test for gpio-line-names lookup

2025-11-11T20:53:40+00:00

Signed-off-by: Rasmus Villemoes 
Reviewed-by: Heiko Schocher

test: gpio: include in build, and fixup bitrot

2025-11-11T20:53:40+00:00

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, 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 
Reviewed-by: Heiko Schocher

test: Rename unit-test flags

2024-08-27T00:51:48+00:00

The UT_TESTF_ macros read as 'unit test test flags' which is not right.
Rename to UTF ('unit test flags').

This has the benefit of being shorter, which helps keep UNIT_TEST()
declarations on a single line.

Give the enum a name and reference it from the UNIT_TEST() macros while
we are here.

Signed-off-by: Simon Glass

Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"

2024-05-20T19:35:03+00:00

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman 
Signed-off-by: Tom Rini

Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

2024-05-19T14:16:36+00:00

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman 
Signed-off-by: Tom Rini

test: Remove and add needed includes

2024-05-06T21:05:04+00:00

Remove  from all "test/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini

test:dm:fix typo

2023-01-06T02:21:56+00:00

Fix typos in the 'test/dm' directory.

Signed-off-by: Yuepeng Xing 
Reviewed-by: Simon Glass

gpio: sandbox: Add GPIOD_IS_AF for gpio configured in alternate function

2022-09-15T13:55:30+00:00

This allows to test if a pin's label if displayed using gpio_get_status()
when this pin is configured in alternate function.

Signed-off-by: Patrice Chotard 
Reviewed-by: Simon Glass 
Reviewed-by: Patrick Delaunay

gpio: Add a way to read 3-way strapping pins

2021-03-03T20:40:47+00:00

Using the internal vs. external pull resistors it is possible to get
27 different combinations from 3 strapping pins. Add an implementation
of this.

This involves updating the sandbox GPIO driver to model external and
(weaker) internal pull resistors. The get_value() method now takes account
of what is driving a pin:

   sandbox: GPIOD_EXT_DRIVEN - in which case GPIO_EXT_HIGH provides the
          value
   outside source - in which case GPIO_EXT_PULL_UP/DOWN indicates the
          external state and we work the final state using those flags and
          the internal GPIOD_PULL_UP/DOWN flags

Of course the outside source does not really exist in sandbox. We are just
modelling it for test purpose.

Signed-off-by: Simon Glass

dm: gpio: Add a way to update flags

2021-03-03T20:40:10+00:00

It is convenient to be able to adjust some of the flags for a GPIO while
leaving others alone. Add a function for this.

Update dm_gpio_set_dir_flags() to make use of this.

Also update dm_gpio_set_value() to use this also, since this allows the
open-drain / open-source features to be implemented directly in the
driver, rather than using the uclass workaround.

Update the sandbox tests accordingly. This involves a lot of changes to
dm_test_gpio_opendrain_opensource() since we no-longer have the direciion
being reported differently depending on the open drain/open source flags.

Also update the STM32 drivers to let the uclass handle the active low/high
logic.

Drop the GPIOD_FLAGS_OUTPUT() macro which is no-longer used.

Signed-off-by: Simon Glass 
Tested-by: Kory Maincent 
Reviewed-by: Patrick Delaunay 
Tested-by: Patrick Delaunay 
Reviewed-by: Patrick Delaunay 
Tested-by: Patrick Delaunay