hwmv2: series/ and families/ application folders

[erwango]

Is your enhancement proposal related to a problem? Please describe.
As one of the additions of hwmv2, it was added the possibility to factorize configuration (dts overlays, Kconfig fragments) for a given soc under a new application folder named soc/.
This new folder provide the same functionality of boards/ folder, but allows to put all configuration that depends on a soc into a single file, hence sparing the need to replicate these configurations in various boards that uses the same soc version.

This new possibility is likely pretty useful in down stream projects (see related golioth blog post as example).

Though, in zephyr tree, the possibility of usages of socs/ folder is relatively limited because this is not often that several boards share the exact same soc, and even if it happens, within in tree applications (samples, tests) we usually want to have one board for each soc but not more. Sometime even, we just want to have one board per whole soc series, as aim is to maximize test coverage at series level while minimizing the CI load.

Describe the solution you'd like
In the same vein as socs\ folders, add series\ and families\ application folders.
Using these folder, it would be easy to provide application specific configuration at the right level while minimizing the number of files to maintain, limit CI load and ensure tests and samples compatibility with the maximum of boards.

For instance:
Replace

samples/drivers/dac/
├── boards
│   ├── b_u585i_iot02a.overlay
│   ├── disco_l475_iot1.overlay
│   ├── nucleo_f091rc.overlay
│   ├── nucleo_f207zg.overlay
│   ├── nucleo_f429zi.overlay
│   ├── nucleo_f746zg.overlay
│   ├── nucleo_f767zi.overlay
│   ├── nucleo_g071rb.overlay
│   ├── nucleo_g431rb.overlay
│   ├── nucleo_g474re.overlay
│   ├── nucleo_h743zi.overlay
│   ├── nucleo_l073rz.overlay
│   ├── nucleo_l152re.overlay
│   ├── nucleo_l552ze_q.overlay
│   ├── nucleo_u575zi_q.overlay
│   ├── nucleo_wl55jc.overlay
│   ├── stm32f3_disco.overlay
│   └── stm32l562e_dk.overlay

with

samples/drivers/dac/
├── families
│   └── stm32.overlay

About CI load, one of the major issues in CI load is the frequent use of filter that impose to prebuild board configurations before being able to apply the filters. series/ and families folder could help reducing the usage of those filters as well.

For instance:

  drivers.spi.stm32_spi_16bits_frames.loopback:
    extra_args:
      - EXTRA_CONF_FILE="overlay-stm32-spi-16bits.conf"
      - DTC_OVERLAY_FILE="overlay-stm32-spi-16bits.overlay"
    filter: CONFIG_SOC_FAMILY_STM32
    platform_allow:
      - nucleo_h743zi
      - nucleo_h753zi
      - nucleo_h745zi_q/stm32h745xx/m4
      - nucleo_h745zi_q/stm32h745xx/m7

could be replaced by families/stm32.conf and families/stm32.overlay, with the additional benefit that this configuration would apply also when running west, not only when running twister.

Describe alternatives you've considered
Introduce Kconfig.defconfig files in samples and tests (if that's even doable).

[erwango]

^^ @zephyrproject-rtos/testing

[ajf58]

This would be very useful.

A suggestion:

Could this be namespaced either in the folder name, or by being a set of subfolders? Eg.

samples/drivers/adc/
├── soc_series
│   └── rp2350.overlay
samples/drivers/dac/
├── soc_family
│   |── rpi_pico.overlay
│   └── stm32.overlay

or using subdirectories:

samples/drivers/adc/soc/
├── series
│   └── rp2350.overlay
samples/drivers/dac/soc/
├── family
│   |── rpi_pico.overlay
│   └── stm32.overlay

This might be easier to understand than families or series(es) without some kind of qualifier/prefix.

[erwango]

Stumbled on https://github.com/zephyrproject-rtos/zephyr/pull/94716/files which made me think again to this issue.

I agree with @ajf58 that having soc_series and soc_family might be easier to understand.
Going further what about re-using soc folder for all soc/series/family.

So we'd have:

samples/drivers/dac/soc/
├── soc
│   ├── stm32c031xx.overlay
│   |── stm32f1x.overlay
│   └── stm32.overlay

And the script would find out by itself if overlay should apply to a soc, a series or a family.
Alternatively, to make it clearer/easier, file prefixes could be used:

samples/drivers/dac/soc/
├── soc
│   ├── stm32c031xx.overlay
│   |── series_stm32f1x.overlay
│   └── family_stm32.overlay

[hakehuang]

the board variation on io/pin settings, can not be covered by this, any idea to enhance?

[erwango]

the board variation on io/pin settings, can not be covered by this, any idea to enhance?

I think that is a different topic. Would you mind open a dedicated issue ?

[ajf58]

@zephyrproject-rtos/testing what's the next step here? Is there interest/would their be "buy-in" on this? From my (bias) perspective this feels more elegant than the current situation.

[hakehuang]

@ajf58 , we need do a full regression on this. @anasnashif maybe github CI need involved as well, I will post my report here once done.