1.. _dt_vs_kconfig:
2
3Devicetree versus Kconfig
4#########################
5
6Along with devicetree, Zephyr also uses the Kconfig language to configure the
7source code. Whether to use devicetree or Kconfig for a particular purpose can
8sometimes be confusing. This section should help you decide which one to use.
9
10In short:
11
12* Use devicetree to describe **hardware** and its **boot-time configuration**.
13  Examples include peripherals on a board, boot-time clock frequencies,
14  interrupt lines, etc.
15* Use Kconfig to configure **software support** to build into the final
16  image. Examples include whether to add networking support, which drivers are
17  needed by the application, etc.
18
19In other words, devicetree mainly deals with hardware, and Kconfig with
20software.
21
22For example, consider a board containing a SoC with 2 UART, or serial port,
23instances.
24
25* The fact that the board has this UART **hardware** is described with two UART
26  nodes in the devicetree. These provide the UART type (via the ``compatible``
27  property) and certain settings such as the address range of the hardware
28  peripheral registers in memory (via the ``reg`` property).
29* Additionally, the UART **boot-time configuration** is also described with
30  devicetree. This could include configuration such as the RX IRQ line's
31  priority and the UART baud rate. These may be modifiable at runtime, but
32  their boot-time configuration is described in devicetree.
33* Whether or not to include **software support** for UART in the build is
34  controlled via Kconfig. Applications which do not need to use the UARTs can
35  remove the driver source code from the build using Kconfig, even though the
36  board's devicetree still includes UART nodes.
37
38As another example, consider a device with a 2.4GHz, multi-protocol radio
39supporting both the Bluetooth Low Energy and 802.15.4 wireless technologies.
40
41* Devicetree should be used to describe the presence of the radio **hardware**,
42  what driver or drivers it's compatible with, etc.
43* **Boot-time configuration** for the radio, such as TX power in dBm, should
44  also be specified using devicetree.
45* Kconfig should determine which **software features** should be built for the
46  radio, such as selecting a BLE or 802.15.4 protocol stack.
47
48As another example, Kconfig options that formerly enabled a particular
49instance of a driver (that is itself enabled by Kconfig) have been
50removed.  The devices are selected individually using devicetree's
51:ref:`status <dt-important-props>` keyword on the corresponding hardware
52instance.
53
54There are **exceptions** to these rules:
55
56* Because Kconfig is unable to flexibly control some instance-specific driver
57  configuration parameters, such as the size of an internal buffer, these
58  options may be defined in devicetree.  However, to make clear that they are
59  specific to Zephyr drivers and not hardware description or configuration these
60  properties should be prefixed with ``zephyr,``,
61  e.g. ``zephyr,random-mac-address`` in the common Ethernet devicetree
62  properties.
63* Devicetree's ``chosen`` keyword, which allows the user to select a specific
64  instance of a hardware device to be used for a particular purpose. An example
65  of this is selecting a particular UART for use as the system's console.
66