Lines Matching refs:that

5 Base Boot Requirements) [1] specifications.  Please note that the SBBR
22 ACPI and Linux only, on an ARMv8 system -- that is, what Linux expects of
31 section we summarize a blog post [2] from Grant Likely that outlines the
42 -- ACPI’s OSPM defines a power management model that constrains what the
60    longer any reason to feel that ACPI is only belongs to Windows or that
70 to understand all the minute details of the hardware so that the OS doesn’t
81 really just duplicates something that already works.  ACPI already does what
89 One of the primary motivations for ACPI is standardization, and using that
92 kernel and firmware to agree on a consistent abstraction that can be
100 not be optimal, with the earliest kernel version that first provides support
101 for that baseline version of ACPI.  There may be a need for additional drivers,
124 means that ACPI is only supported on platforms that boot via UEFI.
132 fall back to DT if there are no ACPI tables present.  The basic idea is that
142 kernel has, in effect, determined that ACPI tables are not present at that
165 hardware from other architectures.  Any fields that are not to be used for
209 Tree description for the same device.  This is also one of the reasons that
210 ACPI can be useful -- the driver takes into account that it may have less
217 is that UEFI will leave the device in a reasonable default state, including
229 Source Language (section 19 of the specification).  This means that there
232 that looks like this: Name(KEY0, "value0").  An ACPI device driver would
236 wide registry that maintains a list of names, minimzing re-use; (3)
246 to create a new UUID for the _DSD object.  Note that there is even less
247 regulation of the use of _DSM than there is of _DSD.  Drivers that depend
263 so that they may be used across all operating systems supporting ACPI.
264 Device properties that have not been registered with the UEFI Forum should
267 Before creating new device properties, check to be sure that they have not
278 submitted at the same time.  A driver that supports ACPI and uses device
285 It may make sense to provide notice to the UEFI Forum that there is the
306 The kernel assumes that power control of these resources is represented with
309 get that to work, ACPI assumes each device has defined D-states and that these
325 The kernel ACPI code will also assume that the _PSx methods follow the normal
332       should organize that it is allocated/enabled using the _PS0 method.
349 ACPI makes the assumption that clocks are initialized by the firmware --
356 throttling for power management -- the device driver should expect that
357 process to be abstracted out into some ACPI method that can be invoked
364 they could do so by providing ACPI methods that could be invoked by Linux
377 DO try to structure the driver so that it is data-driven.  That is, set up
380 of the driver operate off of the contents of that struct.  Doing so should
443 as closely as possible, and to only implement functionality that complies with
445 vendors that provide bad ACPI tables or violate the standards in some way.
447 be avoided if possible.  If there are features missing from ACPI that preclude
449 submitted to ASWG and go through the normal approval process; for those that
457 source code, are in the list that follows: