Mitigate changes in peripheral enable state after Kconfig replaced by DT status

[pabigot]

Recent patches change Zephyr device instance checks to be based on the status property from the devicetree node alone, by eliminating the Kconfig options to enable individual instances. Unfortunately in several cases (often related to shield-exposed functions like Arduino Serial) the Kconfig option disabled a peripheral, while the devicetree node specified it was enabled. As a result peripherals are now enabled that were not in the past; example patches necessary to fix the applications are found in #24423 and #24710. In addition to visable breakage in existing applications this can also silently increase power for peripherals that are suddenly enabled but never used.

A related issue is that the pinmux.c files in some targets leave open the possibility of enabling multiple peripherals on the same pin; for example three distinct pins in frdm_k64f have at least two potentially conflicting peripheral configurations (B10, C16, C17). This is primarily addressed by #25251.

Some tasks that might reduce the amount of future confusion related to this:

• Clarify in the general recommendations whether shield-based functions like I2C and serial should be default-enabled or default-disabled;
• Review the removal of Kconfig instance enable flags to determine what peripherals changed default enable state as a consequence;
• Update devicetree status= defaults to reproduce the behavior that had been the default in the past;
• Update the pinmux files to produce a build-time diagnostic if multiple peripherals demand the same pin be selected for distinct roles.

[pabigot]

The following script can be used to identify boards with potential pinmux conflicts and the pins that have multiple selected functions. There are ten such boards at the moment.

cd ${ZEPHYR_BASE}
find boards/ -name pinmux.c \
| while read pn ; do
  bn=$(basename $(dirname ${pn}))
  sf=/tmp/pm-${bn}.sed
  grep pinmux_pin_set ${pn} \
    | sort \
    | uniq \
    | awk '{print $1,$2}' \
    | uniq -d \
    > ${sf}
  if [ -s ${sf} ] ; then
    sed -i -e 's@^@/@' -e 's/ / */g' -e 's@$@/p@' ${sf}
    echo "Conflicts for ${pn}:"
    sed -n -f ${sf} ${pn} \
      | sort
    echo
  fi
  rm -f ${sf}
done

[erwango]

@pabigot , script version to get STM32 conflicts as well:

cd ${ZEPHYR_BASE}
find boards/ -name pinmux.c \
| while read pn ; do
  bn=$(basename $(dirname ${pn}))
  sf=/tmp/pm-${bn}.sed
  grep -e STM32_PIN_ -e pinmux_pin_set ${pn} \
    | sort \
    | uniq \
    | awk '{print $1,$2}' \
    | uniq -d \
    > ${sf}
  if [ -s ${sf} ] ; then
    sed -i -e 's@^@/@' -e 's/ / */g' -e 's@$@/p@' ${sf}
    echo "Conflicts for ${pn}:"
    sed -n -f ${sf} ${pn} \
      | sort
    echo
  fi
  rm -f ${sf}
done

[erwango]

@pabigot , regarding the following point:

• Clarify in the general recommendations whether shield-based functions like I2C and serial should be default-enabled or default-disabled;

What you are referring to is not fully clear to me (Kconfig symbols, shields nodes , other ?). Though, I was indeed thinking of refreshing the guidelines based on the recent changes in boards configuration capabilities.
Here are few points I have in mind, and I'll be happy to discuss them:

• As part of default board configuration, devices should configured (assign pins, provide boot time configuration, provide an alias or connector)
• Status of devices should be set to "okay" only for the ones that would be used by ~ all applications (serial device assigned to the console, gpio ports). Others devices should keep status as "disabled"
• As a consequence, it would be up to the application to enable required devices.

This proposal would allow to control with the best granularity, device activation. This would avoid to compile in all configured I2C peripherals, just because an application enabled CONFIG_I2C and default board configuration features 3 I2C devices (i2c1 for sensors present on the board support package, arduino_i2c and 3 for what not other application).
To achieve this, however, we'd need to generalize "zephyr application aliases" (or alternate node labels such as zephyr_spi : spi_2 { ... };) so that we don't have to modify samples each time we want a new board to be added to the list of the compatible boards.