arch/arm64/arm-acpi.rst

41    while DT explicitly does not support this.  For hardware vendors, being
50    as for RAS) which are currently used in production systems.  DT does not.
51    Such bindings could be defined in DT at some point, but doing so means Arm
57    both DT and ACPI if they want to support multiple operating systems.  And,
81 in place.  DT does exactly what Linux needs it to when working with vertically
83 server vendors need.  Linux could potentially get there with DT, but doing so
85 the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
113 exclusive with DT support at compile time.
118 Regardless of whether DT or ACPI is used, the kernel must always be capable
129 When an Arm system boots, it can either have DT information, ACPI tables,
131 the kernel will try to use DT for device enumeration; if there is no DT
135 fall back to DT if there are no ACPI tables present.  The basic idea is that
144 is used, the kernel will disable ACPI and try to use DT to boot instead; the
288 Clocks provide an excellent example.  In DT, clocks need to be specified
297 In DT, the parameters needed by the driver to set up clocks as in the example
308 names ("KEY0") to four characters unlike DT; (2) there is no industry
340 as DT bindings, or the UEFI Forum as device properties.  While we do not want
341 to simply move all DT bindings into ACPI device properties, we can learn from
346 both DT bindings and ACPI device properties for device drivers have review
364 whether DT or ACPI is being used.  This API should be used [5]; it can
366 discourage divergence between DT bindings and ACPI device properties.
445 DO NOT remove any DT handling when adding ACPI support for a driver.  The
452 allow most divergence between ACPI and DT functionality to be kept local to
458          /* DT specific functionality */
486 clear the different names the driver is probed for, both from DT and from