Zephyr: Post DT API migration review

[erwango]

Describe the bug
Following move to new DT API (https://github.com/zephyrproject-rtos/zephyr/pull/25009 and cie), a systematic code review is needed around impacted code.

First reason is that a lot of code has been changed using scripts which is a usual source of bugs. Most of the time, lot of files where impacted, which is not easy to review, and hence some bugs have been merged (https://github.com/zephyrproject-rtos/zephyr/blame/master/boards/arm/atsamd21_xpro/pinmux.c#L23 -- fixed by https://github.com/zephyrproject-rtos/zephyr/pull/25252)

Second reason is that peripheral instances Kconfig symbols replacement by DT macros is not transparent in all areas. In a driver compiled under CONFIG_SPI control, CONFIG_SPI_1 is equivalent to DT_HAS_NODE_STATUS_OKAY(DT_NODELABEL(spi1)), but this is not valid in other areas.
Under boards/ or soc/, every piece of code under DT_HAS_NODE_STATUS_OKAY(spi1) is compiled in, whatever the status of CONFIG_SPI. So SPI related pins or clocks are activated unconditionally. Since this is the case for all peripherals (SPI, CAN, I2C, ...) this could potentially lead to, among others:

• pin conflicts between peripherals that weren't enabled together until now
• clocks being enabled for disabled peripherals
• ~instances that used to be disabled in Kconfig but DT enables them by default, causing conflicts (eg. with shields).~ Covered separately by #24745.

These two cases are typically tricky to detect, and since current code coverage is not sufficient to guarantee all potential bugs introduced will be detected.
So it is safer to systematically review each change and in case of doubt re-introduce a peripheral Kconfig control on newly introduced instance dt macros:
#if DT_HAS_NODE_STATUS_OKAY(DT_NODELABEL(spi1)) && CONFIG_SPI

Expected behavior
No bugs where introduced following move to new DTS API

Impact
Wide spectrum of bugs in v2.3.0

Actions
I propose that each codeowner reviews, in his own area (boards/, soc/, ..) code impacted by new introduced DT macros (DT_HAS_NODE_STATUS_OKAY, DT_NODE_HAS_COMPAT_STATUS, ATMEL_SAM0_DT_SERCOM_CHECK, ..) and take appropriate actions.

In order to make this a task that can be completed in a finite amount of time, I've giving putting here
the various soc maintainers based on CODEOWNERS. I let people tick their area when they consider things are ok (don't hesitate to rework this list if required).

Check boards/ and soc/ for each of the hardware variants below:

• [x] arc/snps_*/ @vonhust @ruuddw
• [x] nios2/ @nashif @wentongwu
• [x] arm/arm/mps2/ ? (@galak)
• [x] arm/atmel_sam/sam*/ @ioannisg, @nandojve, @fallrisk (boards/)
• [x] arm/bcm*/ @sbranden
• [x] arm/infineon_xmc/ @parthitce
• [x] arm/nxp*/ @MaureenHelm (#25525)
• [x] arm/nordic_nrf/ @ioannisg @anangl (#25533)
• [x] arm/qemu_cortex_a53/ @carlocaione
• [x] arm/st_stm32/ @erwango (https://github.com/zephyrproject-rtos/zephyr/pull/25288)
• [x] arm/ti_simplelink/ @bwitherspoon, @vanti, @Mani-Sadhasivam
• [x] arm/xilinx_zynqmp/ @stephanosio
• [x] xtensa/intel_s1000/ @sathishkuttan @dcpleung
• [x] x86/appolo_lake @jhedberg
• [x] riscv/rv32m1_vega @MaureenHelm (#25540)

Add a dependency to the subsystem Kconfig variable if it was present previously:
#if DT_NODE_UART... && CONFIG_UART

EDIT: Following https://github.com/zephyrproject-rtos/zephyr/pull/25214, DT_HAS_NODE_STATUS_OKAY(spi1) is being replaced by DT_NODE_HAS_STATUS(DT_NODELABEL(spi1), okay)

EDIT: Adding x86 (@andrewboie )

[pabigot]

24745 is related and really should be addressed before release too. That involves assessing board defconfigs vs devicetree status values.

[erwango]

24745 is related and really should be addressed before release too. That involves assessing board defconfigs vs devicetree status values.

Thanks @pabigot, this exactly one of the potential impacts. Btw https://github.com/zephyrproject-rtos/zephyr/issues/24509 is another bug related to that.

[parthitce]

@erwango arm/infineon_xmc/ can be marked as done. Couldn't tick/edit myself.

[pabigot]

For potential pinmux conflicts please see https://github.com/zephyrproject-rtos/zephyr/issues/24745#issuecomment-620236843 which identifies these boards as potentially using the same pin for multiple peripherals (only the boards are identified here; use the referenced script to see the specific pins and roles)

Conflicts for boards/arm/frdm_k22f/pinmux.c:
Conflicts for boards/arm/mec1501modular_assy6885/pinmux.c:
Conflicts for boards/arm/frdm_k82f/pinmux.c:
Conflicts for boards/arm/atsamr21_xpro/pinmux.c:
Conflicts for boards/arm/frdm_k64f/pinmux.c:
Conflicts for boards/arm/mec15xxevb_assy6853/pinmux.c:
Conflicts for boards/arm/twr_ke18f/pinmux.c:
Conflicts for boards/arm/hexiwear_k64/pinmux.c:
Conflicts for boards/arm/frdm_kw41z/pinmux.c:
Conflicts for boards/arm/hexiwear_kw40z/pinmux.c:
Conflicts for boards/riscv/rv32m1_vega/pinmux.c:

Example of script output:

Conflicts for boards/arm/frdm_k64f/pinmux.c:
    pinmux_pin_set(portb, 10, PORT_PCR_MUX(kPORT_MuxAsGpio));
    pinmux_pin_set(portb, 10, PORT_PCR_MUX(kPORT_PinDisabledOrAnalog));
    pinmux_pin_set(portc, 16, PORT_PCR_MUX(kPORT_MuxAlt3));
    pinmux_pin_set(portc, 16, PORT_PCR_MUX(kPORT_MuxAlt4));
    pinmux_pin_set(portc, 17, PORT_PCR_MUX(kPORT_MuxAlt3));
    pinmux_pin_set(portc, 17, PORT_PCR_MUX(kPORT_MuxAlt4));
    pinmux_pin_set(portc, 17, PORT_PCR_MUX(kPORT_MuxAsGpio));

[erwango]

Pinmux conflicts on STM32 based boards with updated script in #24745

Conflicts for boards/arm/nucleo_f767zi/pinmux.c:
    { STM32_PIN_PA7, STM32F7_PINMUX_FUNC_PA7_ETH },
    { STM32_PIN_PA7, STM32F7_PINMUX_FUNC_PA7_SPI1_MOSI },
Conflicts for boards/arm/nucleo_f746zg/pinmux.c:
    { STM32_PIN_PA7, STM32F7_PINMUX_FUNC_PA7_ETH },
    { STM32_PIN_PA7, STM32F7_PINMUX_FUNC_PA7_SPI1_MOSI },
Conflicts for boards/arm/stm32vl_disco/pinmux.c:
    { STM32_PIN_PB10, STM32F1_PINMUX_FUNC_PB10_I2C2_SCL },
    { STM32_PIN_PB10, STM32F1_PINMUX_FUNC_PB10_USART3_TX },
    { STM32_PIN_PB11, STM32F1_PINMUX_FUNC_PB11_I2C2_SDA },
    { STM32_PIN_PB11, STM32F1_PINMUX_FUNC_PB11_USART3_RX },
Conflicts for boards/arm/nucleo_f756zg/pinmux.c:
    { STM32_PIN_PA7, STM32F7_PINMUX_FUNC_PA7_ETH },
    { STM32_PIN_PA7, STM32F7_PINMUX_FUNC_PA7_SPI1_MOSI },

[nandojve]

The pinctrl-0 was introduced for Atmel SAM (not SAM0). It allowed us to remove dts_fixup and soc_pinmap files. In this case, problems can happen only with SAM0 variations that have pinmux.c file.

Should this to be applied on all boards///pínmux*.c files to avoid exceptions? I was wondering if there are exceptions, can we identify at review phase the possibles conflicts.

[erwango]

@nandojve Advice is to review all files that have been impacted by the migration. Conflicts could be identified txs to the script provided in #24745.

[vanti]

@erwango I don't think I see anything that needs to change for ti_simplelink, so marking done.

[carlescufi]

@vonhust and @ruuddw will you take a look for ARC-based platforms please?

[ruuddw]

@vonhust and @ruuddw will you take a look for ARC-based platforms please?

Checked, no issues (ARC EMSK and other boards have a different type of pinmux called pmodmux, no DT relation currently).

[carlescufi]

@nashif @MaureenHelm @ioannisg @anangl @jhedberg could you please check your respective platforms so we can close this soon?