From 67b0cd382ede4b234315c0e87276d99dd9d97320 Mon Sep 17 00:00:00 2001 From: Marti Bolivar Date: Wed, 11 Jan 2023 14:30:33 -0800 Subject: [PATCH] doc: dts: clarify a design requirement There's been some confusion about what we mean by hardware description. We're really talking about the user-facing inputs that need to be configured per SoC, application, etc. It's fine to do things like use ifdeffery on a CMSIS header in an aarch32 support file to decide if the current target has some feature, for instance -- that sort of thing doesn't *have* to come from DT. At the same time, we don't want to encourage vendor-specific hardware configuration languages from creeping into upstream zephyr, so keep the language strong in an effort to avoid that misinterpretation. Signed-off-by: Marti Bolivar --- doc/build/dts/design.rst | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/doc/build/dts/design.rst b/doc/build/dts/design.rst index 90b634dd310..82cfe652287 100644 --- a/doc/build/dts/design.rst +++ b/doc/build/dts/design.rst @@ -8,23 +8,25 @@ changes are expected. The following are the general design goals, along with specific examples about how they impact Zephyr's source code, and areas where more work remains to be done. -Single source for all hardware information -****************************************** +Single source for hardware information +************************************** -Zephyr shall obtain its hardware descriptions exclusively from devicetree. +Zephyr's built-in device drivers and sample applications shall obtain +configurable hardware descriptions from devicetree. Examples ======== - New device drivers shall use devicetree APIs to determine which :ref:`devices - to create ` if possible. + to create `. - In-tree sample applications shall use :ref:`aliases ` to determine which of multiple possible generic devices of a given type will be used in the current build. For example, the :ref:`blinky-sample` uses this to determine the LED to blink. -- Boot-time pin muxing and pin control can be accomplished via devicetree. +- Boot-time pin muxing and pin control for new SoCs shall be accomplished via a + devicetree-based pinctrl driver Example remaining work ====================== @@ -33,7 +35,7 @@ Example remaining work determine the hardware supported by a board. This should be obtained from devicetree instead. -- Various device drivers currently use Kconfig to determine which instances of a +- Legacy device drivers currently use Kconfig to determine which instances of a particular compatible are enabled. This can and should be done with devicetree overlays instead.