Skip to content

Conversation

@mnkp
Copy link
Member

@mnkp mnkp commented Dec 29, 2019

The pinmux_basic_api test relies on a hardware loopback, manual
shorting of two GPIO pins. The Zephyr test framework does not allow
currently to define such pins in a generic way. The pinmux_basic_api
test hard codes pin numbers specific to a few evaluation boards.

The test has a few more flaws and limitations:

  • it verifies that pin configured to function A can be controlled by
    GPIO driver. It doesn't verify that pin configured to function B can
    be contorolled by a corresponding peripheral driver.
  • the test relies on level sensitive interrupt support which is not
    always available.
  • the test will pass even if there are erros when pin is configured to
    function B.
  • the test allows to configure both test pins as an output therefore
    shorting the outputs.

Considering the flaws and limited coverage of the test as well as
missing features of the Zephyr test framework this commit removes the
testcase. It is not currently possible to write a generic pinmux
testcase that supports multiple boards and can be used to assess the
quality of the driver. Instead, to ensure the driver code will not
degrade, we need to rely on implicit testing done by the board
initialization code located in boards/ folder.

The pinmux_basic_api test relies on a hardware loopback, manual
shorting of two GPIO pins. The Zephyr test framework does not allow
currently to define such pins in a generic way. The pinmux_basic_api
test hard codes pin numbers specific to a few evaluation boards.

The test has a few more flaws and limitations:
- it verifies that pin configured to function A can be controlled by
  GPIO driver. It doesn't verify that pin configured to function B can
  be contorolled by a corresponding peripheral driver.
- the test relies on level sensitive interrupt support which is not
  always available.
- the test will pass even if there are erros when pin is configured to
  function B.
- the test allows to configure both test pins as an output therefore
  shorting the outputs.

Considering the flaws and limited coverage of the test as well as
missing features of the Zephyr test framework this commit removes the
testcase. It is not currently possible to write a generic pinmux
testcase that supports multiple boards and can be used to assess the
quality of the driver. Instead, to ensure the driver code will not
degrade, we need to rely on implicit testing done by the board
initialization code located in boards/ folder.

Signed-off-by: Piotr Mienkowski <[email protected]>
@mnkp mnkp added area: Pinmux area: Tests Issues related to a particular existing or missing test labels Dec 29, 2019
@mnkp mnkp requested a review from nashif as a code owner December 29, 2019 22:56
Copy link
Contributor

@pabigot pabigot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of removing a test unless it's redundant with an existing test. Also the pinmux API is pretty weakly defined, so any clues about how it was intended to be used could be helpful. This may be the only self-contained example of combining it with GPIO operations. I don't see any benefit in dropping it except that it eliminates the need to convert it to the new GPIO API. Also we certainly can adapt it for multiple boards with overlays in the test even if that's not "clean".

Won't approve, won't block.

@MaureenHelm MaureenHelm merged commit 49bcafc into zephyrproject-rtos:master Jan 27, 2020
@mnkp mnkp deleted the test_pinmux branch January 27, 2020 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: Pinmux area: Tests Issues related to a particular existing or missing test

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants