tests/samples: drivers: adc: rework tests filtering and configuration #94585

JarmouniA · 2025-08-17T12:11:34Z

Make tests/samples test scenarios depend on the existence of required DT elements (aliases, "zephyr,user" properties...).

Motivation behind the filtering changes:
The number of board overlays in ADC tests/samples is completely out of control in my opinion. And the reason is: most of their test scenarios get triggered, & fail every single time a board PR is opened and has the adc tag in [board].yaml (& almost always it does because most people assume those tags are a general list of supported features..., not test dedicated), then an overlay is added, as a fix for CI, eventhough the exact ADC IP/driver is already tested elsewhere on many boards.

samples/drivers/adc/adc_dt/Kconfig

samples/drivers/adc/adc_dt/sample.yaml

butok · 2025-09-11T08:31:14Z

Remove the overlays of redundant platforms that are testing the same IP/Driver, and only keep 1 platform from each SoC series.

@JarmouniA Please clarify.
Does it mean that building of the samples/tests for the "redundant" platforms will be failed?

JarmouniA · 2025-09-11T09:56:37Z

Remove the overlays of redundant platforms that are testing the same IP/Driver, and only keep 1 platform from each SoC series.

@JarmouniA Please clarify. Does it mean that building of the samples/tests for the "redundant" platforms will be failed?

If you mean in CI, they won't be built anymore because of the filtering in test conf yaml file.

scripts/pylib/twister/expr_parser.py

etienne-lms · 2025-09-10T08:19:36Z

scripts/pylib/twister/expr_parser.py

            return True
        return False
+    elif ast[0] == "dt_node_has_prop":
+        # 1st arg 'label' must be a valid node alias or a node path


I think it would be nice to rename dt_node_prop_enabled into dt_nodelabel_prop_enabled to clarify that its 1st argument is a label. There's only 1 place where it's used (samples/boards/nxp/mimxrt1170_evk_cm7/magic_addr/sample.yaml).
It would make your added dt_node_has_prop clearer that its 1st arg is a node path/alias.

In a follow-up PR where I will document the different expressions as well.

butok · 2025-09-16T07:54:08Z

Remove the overlays of redundant platforms that are testing the same IP/Driver, and only keep 1 platform from each SoC series.

@JarmouniA Please clarify. Does it mean that building of the samples/tests for the "redundant" platforms will be failed?

If you mean in CI, they won't be built anymore because of the filtering in test conf yaml file.

Not just CI.
Since this PR removes many platform overlays, the "west build" for removed platforms is not possible for these samples.

JarmouniA · 2025-09-19T11:56:43Z

If you mean in CI, they won't be built anymore because of the filtering in test conf yaml file.

Not just CI. Since this PR removes many platform overlays, the "west build" for removed platforms is not possible for these samples.

So here is how I see it, putting CI aside, samples are for demonstration purposes. In the case of ADC, the utility of an overlay/conf is to show a user how to configure a certain ADC IP/driver for a certain usecase. Hence, having 1 overlay/conf per IP/driver per usecase is sufficient in my opinion to fulfill this aim. There is absolutely no added value whatsoever in having 10s of overlays/confs for the same ADC IP/driver with different boards.

Having said that, I think I will leave the overlays/confs clean up for another PR and focus on enhancing test scenarios filtering/selection in this one in order to get this merged sooner.

butok · 2025-09-25T14:53:59Z

There is absolutely no added value whatsoever in having 10s of overlays/confs for the same ADC IP/driver with different boards.

The added value is that the samples/tests work out of the box for these boards.

JarmouniA · 2025-09-25T15:12:05Z

There is absolutely no added value whatsoever in having 10s of overlays/confs for the same ADC IP/driver with different boards.

The added value is that the samples/tests work out of the box for these boards.

Following this logic, you would be fine with having 847 (number of supported boards rn) overlay/conf files in each sample? Or let's say just the ADC sample (assuming all Zephyr supported boards have an ADC)?

JarmouniA · 2025-09-25T15:19:51Z

There is absolutely no added value whatsoever in having 10s of overlays/confs for the same ADC IP/driver with different boards.

The added value is that the samples/tests work out of the box for these boards.

Tests are a completely different matter than samples in my opinion, they are not supposed to build/run on any board, that makes no sense, they are not demos, rather they should build/run only one targets used on vendor test benches and Zephyr Project CI, and the selection of those targets should be based on well defined criterias like:

maximizing coverage of SoCs, IPs/drivers/subsystems...,
avoiding redundancy in coverage,
using the most performant target to test a certain IP to cut test time....

butok · 2025-10-01T08:24:13Z

There is absolutely no added value whatsoever in having 10s of overlays/confs for the same ADC IP/driver with different boards.

The added value is that the samples/tests work out of the box for these boards.

Tests are a completely different matter than samples in my opinion, they are not supposed to build/run on any board, that makes no sense, they are not demos, rather they should build/run only one targets used on vendor test benches and Zephyr Project CI, and the selection of those targets should be based on well defined criterias like:

maximizing coverage of SoCs, IPs/drivers/subsystems...,

avoiding redundancy in coverage,

using the most performant target to test a certain IP to cut test time....

Hi @hakehuang
Is there any statement from the Zephyr Testing group regarding the twister scope limitation?

hakehuang · 2025-10-03T02:02:40Z

Is there any statement from the Zephyr Testing group regarding the twister scope limitation?

we do not have aligned agreement on this yet. I would say for now the module owner can make the judgement .

Add 'dt_node_has_prop' expression to use the existence of a node property as a filter in Twister test configuration yaml files. First argument must be a node alias (in aliases node) or a node path, not a nodelabel. Signed-off-by: Abderrahmane JARMOUNI <[email protected]>

Make ADC tests' test scenarios depend on the existence of required DT elements. Signed-off-by: Abderrahmane JARMOUNI <[email protected]>

Make ADC samples' test scenarios depend on the existence of required DT elements. Signed-off-by: Abderrahmane JARMOUNI <[email protected]>

sonarqubecloud · 2025-10-04T10:40:31Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

JarmouniA · 2025-10-04T11:20:48Z

Update: postponed the clean-up of platform_allow, overlays/confs, integration_platforms... until there is consensus on the topic.

JarmouniA · 2025-10-06T14:47:56Z

@butok @anangl Could you please have a look? Thanks!

anangl · 2025-10-07T06:12:04Z

scripts/pylib/twister/expr_parser.py

+        # 1st arg 'label' must be a valid node alias or a node path
+        label = ast[1][0]
+        try:
+            node = edt.get_node(label)


Why not name this variable path (as the get_node() parameter is named)? label is a bit confusing.

It can be an alias too, but I agree it's confusing, will recheck in a follow-up PR to document these expressions and address #94585 (comment)

JarmouniA force-pushed the fix_adc_api_test_filter branch 2 times, most recently from fee055b to 60289a3 Compare August 17, 2025 14:32

JarmouniA marked this pull request as ready for review August 17, 2025 15:37

zephyrbot added area: ADC Analog-to-Digital Converter (ADC) area: Samples Samples platform: NXP NXP platform: GD32 GigaDevice platform: Renesas RA Renesas Electronics Corporation, RA labels Aug 17, 2025

zephyrbot requested review from anangl, butok, cameled, decsny, DerekSnell, dleach02, duynguyenxa, EmilioCBen, kartben, KhiemNguyenT, mmahadevan108, nandojve, nashif, soburi and thaoluonguw August 17, 2025 15:38

zephyrbot assigned kartben Aug 17, 2025

butok reviewed Aug 18, 2025

View reviewed changes

samples/drivers/adc/adc_dt/Kconfig Outdated Show resolved Hide resolved

JarmouniA force-pushed the fix_adc_api_test_filter branch from 60289a3 to c046f0e Compare August 19, 2025 07:25

zephyrbot added the area: Twister Twister label Aug 19, 2025

JarmouniA force-pushed the fix_adc_api_test_filter branch 2 times, most recently from 5df6649 to bcb7286 Compare August 19, 2025 21:31

kartben assigned anangl Aug 20, 2025

hakehuang reviewed Sep 9, 2025

View reviewed changes

samples/drivers/adc/adc_dt/sample.yaml Show resolved Hide resolved

JarmouniA mentioned this pull request Sep 9, 2025

st: wba65: add stm32wba65i_dk1 board, 'ns' variant for dk1 and nucleo boards #95722

Open

etienne-lms reviewed Sep 12, 2025

View reviewed changes

JarmouniA mentioned this pull request Sep 15, 2025

stm32: tests/samples : add support for nucleo_h753zi on some tests and samples #95744

Merged

JarmouniA mentioned this pull request Sep 26, 2025

Add support for ADC16 driver on RA2A1 MCU #95710

Open

JarmouniA mentioned this pull request Oct 2, 2025

Add silabs series 2 IADC driver with scan conversion and DMA support. #94264

Open

JarmouniA force-pushed the fix_adc_api_test_filter branch from a425e78 to 80e5aa1 Compare October 4, 2025 10:11

zephyrbot added area: Boards/SoCs area: Tests Issues related to a particular existing or missing test platform: NXP MCU labels Oct 4, 2025

JarmouniA added 3 commits October 4, 2025 12:19

tests: drivers: adc: enhance test scenarios filtering

2215b12

Make ADC tests' test scenarios depend on the existence of required DT elements. Signed-off-by: Abderrahmane JARMOUNI <[email protected]>

samples: drivers: adc: enhance test scenarios filtering

efacc1d

Make ADC samples' test scenarios depend on the existence of required DT elements. Signed-off-by: Abderrahmane JARMOUNI <[email protected]>

JarmouniA force-pushed the fix_adc_api_test_filter branch from 80e5aa1 to efacc1d Compare October 4, 2025 10:31

JarmouniA requested review from hakehuang and etienne-lms October 6, 2025 08:13

anangl approved these changes Oct 7, 2025

View reviewed changes

JarmouniA added this to the v4.3.0 milestone Oct 7, 2025

tests/samples: drivers: adc: rework tests filtering and configuration #94585

Are you sure you want to change the base?

tests/samples: drivers: adc: rework tests filtering and configuration #94585

Conversation

JarmouniA commented Aug 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

butok commented Sep 11, 2025

Uh oh!

JarmouniA commented Sep 11, 2025

Uh oh!

Uh oh!

etienne-lms Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

JarmouniA Oct 4, 2025

Choose a reason for hiding this comment

Uh oh!

butok commented Sep 16, 2025

Uh oh!

JarmouniA commented Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

butok commented Sep 25, 2025

Uh oh!

JarmouniA commented Sep 25, 2025

Uh oh!

JarmouniA commented Sep 25, 2025

Uh oh!

butok commented Oct 1, 2025

Uh oh!

hakehuang commented Oct 3, 2025

Uh oh!

sonarqubecloud bot commented Oct 4, 2025

Quality Gate passed

Uh oh!

JarmouniA commented Oct 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JarmouniA commented Oct 6, 2025

Uh oh!

anangl Oct 7, 2025

Choose a reason for hiding this comment

Uh oh!

JarmouniA Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JarmouniA commented Aug 17, 2025 •

edited

Loading

JarmouniA commented Sep 19, 2025 •

edited

Loading

JarmouniA commented Oct 4, 2025 •

edited

Loading

JarmouniA Oct 7, 2025 •

edited

Loading