soc: silabs: s2: make order in soc Kconfig's

[yishai1999]

Made some order in the Kconfig's for silabs series 2 socs.

[nordicjm]

no this is not how soc series Kconfigs work, they do not select each other, only one is selected

[yishai1999]

Ok. Do you have a suggestion of what to call it instead? They hierarchy is efr32mg21 < xg21 < silbas_s2 so I'm not sure how to refer to each? Series? Family? What additional term can I use?

[nordicjm]

family: silabs_s2
  - series: xg21
    - name: efr32mg21 (assuming this is the name of the soc)

[yishai1999]

No, the soc would be efr32mg21a020f1024im32 for example so efr32mg21a020f1024im32 < efr32mg21 < xg21 < silbas_s2

[nordicjm]

then one of those is going to need to be dropped, it is described on https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html#hardware-support-hierarchy

[asmellby]

As I see it, the following information is needed:

• efr32mg21 in order to construct the CMSIS-Device include path in hal_silabs ("device family" in CMSIS and Silabs terms, currently mapped to "series" in hwmv2)
• xg21 in order to have a single symbol to use to avoid complex expressions when multiple device families share a platform ("generic family" in Silabs terms)
• silabs_s2 for the umbrella of platforms in the same generation ("series" in Silabs terms, currently mapped to "family" in hwmv2)

IMO the easiest way out might be to not try to make xg21 be part of the hwmv2 model, and instead declare it like architecture/cpu is done: by doing the definition and select in Kconfig, not Kconfig.soc, and guarding it behind SOC_FAMILY_SILABS_S2. I'm not sure what the symbol should be called, though -- "generic family" doesn't work since family/series has the opposite meaning in Zephyr. Maybe simply SOC_SILABS_XG21?

[yishai1999]

I'm not sure I understood what you mean? Would be enough to just change the current name from SOC_SERIES_XG21 to SOC_SILABS_XG21? I made the changes under that assumption, LMK what you think about it @asmellby @nordicjm

[nordicjm]

The idea is that in future there will be no selections of these symbols (i.e. other than selecting a SOC_MY_SOC from a board - perhaps, or this might be done automatically too) and all SOC_* symbols will be automatically selected by the build system, so adding that does not fit in to that but would need to wait for @tejlmand to get back from vacation to comment on the suitability because the automatic build system parts is his idea

[asmellby]

@yishai1999 Yeah, this was what I was thinking (alternatively also moving it to Kconfig, since it isn't used for hwmv2, but I don't know if that's important -- the docs say "This file selects the SoC family and series in the Kconfig tree and potential other SoC related Kconfig").

There is prior art for this in the tree for STM32: soc/st/stm32/stm32f1x/Kconfig.soc#L40. This one does it the same way as you've done here now, and for exactly the same reason -- to produce a generic symbol that is then used in a clock control driver header: include/zephyr/drivers/clock_control/stm32_clock_control.h#L20

[nordicjm]

basing it on the stm32 example is ok yes

[sonarqubecloud]

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

[yishai1999]

@jhedberg @asmellby Can we merge?

[asmellby]

@nordicjm Do you have any additional required changes now that the "series" duplication is resolved, or can this PR be made ready to merge?

[nordicjm]

Remember to re-request review in the top right when you want reviewers to look at a PR