Use sizeofs of structures corresponding to the parsed device entry.
This does not change the calculation, but fixes logical inconsistency.
Sponsored by: The FreeBSD Foundation
Sponsored by: Advanced Micro Devices (AMD)
MFC after: 1 week
and apply the consistent format for device ids used in other IVRS
elements. The field seems to be the PCI Device ID of the IOMMU itself,
instead of an abstract unit ID.
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
and disable warnings about unused function args coming from the vendor
acpi headers.
Reviewed by: markj
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D44634
The field comes from the ACPI NFIT table and must be already properly
aligned by BIOS (at least so is written in the spec).
Reviewed by: markj
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D44634
acpidump(8) uses iasl(8) to parse acpi information.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44596
rc.suspend has gained an rcorder keyword recently. Document it alongside
the existing resume keyword.
Reviewed By: mhorne, Pau Amma <pauamma@gundo.com>
Differential Revision: https://reviews.freebsd.org/D40484
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
This function intentionally saves a pointer to an on-stack variable in
a global as a dubious way of reading the stack pointer.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D37535
To support the Arm Statistical Profiling Extension (SPE) ACPI 6.3 added
a place to hold the SPE interrupt. Add to acpidump to show when printing
the Arm Generic Interrupt data.
Sponsored by: The FreeBSD Foundation
There is a workaround in acpidump for an old IBM laptop. This is being
hit on a modern arm64 system causing acpidump to use the wrong field
when reading a later address.
As the laptop has a 32-bit CPU the only FreeBSD support for it is i386.
As such limit the workaround to that architecture.
Reviewed by: emaste, jkim, jhb (all earlier version)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32573
These are allowed to be zero when the hardware reduced APCI flag is set
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D23207
Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
for older compilers.
Reviewed by: imp (earlier version), emaste, jhb
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D24802
ACPI Control Method Batteries have a _BIF and/or _BIX object which
provide static properties of the battery. FreeBSD acpi_cmbat module
supported _BIF object only, which was deprecated as of ACPI 4.0.
_BIX is an extended version of _BIF defined in ACPI 4.0 or later.
As of writing, _BIX has two revisions. One is in ACPI 4.0 (rev.0) and
another is in ACPI 6.0 (rev.1). It seems that hardware vendors still
stick to _BIF only or _BIX rev.0 + _BIF for the maximum compatibility.
Microsoft requires _BIX rev.0 for Windows machines, so there are some
laptop machines with _BIX rev.0 only. In this case, FreeBSD does not
recognize the battery information.
After this change, the acpi_cmbat module gets battery information from
_BIX or _BIF object and internally uses _BIX rev.1 data structure as
the primary information store in the kernel. ACPIIO_BATT_GET_BI[FX]
returns an acpi_bi[fx] structure built by using information obtained
from a _BIF or a _BIX object found on the system. The revision number
field can be used to check which field is available. The acpiconf(8)
utility will show additional information if _BIX is available.
Although ABIs of ACPIIO_BATT_* were changed, the existing APIs for
userland utilities are not changed and the backward-compatible ABIs
are provided. This means that older versions of acpiconf(8) can also
work with the new kernel. The (union acpi_battery_ioctl_arg) was
padded to 256 byte long to avoid another ABI change in the future.
A _BIX object with its revision number >1 will be treated as
compatible with the rev.1 _BIX format.
Reviewed by: takawata
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D23728
is specified by its number (index), starting with zero. Previously,
sometimes users would try to literally invoke `acpiconf -i batt' in
their console and become confused as to why this did not work.
Approved by: bcr (manpages)
Differential Revision: https://reviews.freebsd.org/D18659
and runs scripts containing "KEYWORD: resume" with single "resume" argument.
Working example is the port sysutils/cpupdate that defines
extra_commands="resume" to reload CPU microcode cleared
by suspend/resume sequence.
This change does nothing for a system having no scripts with KEYWORD: resume.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D15247
the ACPI_ROOT_OBJECT and ACPI_TO_POINTER macros from acpica's actypes.h
header, that they use arithmetic on a null pointer treated as a cast
from integer to pointer, which is a GNU extension. We turn off the
warning, because this is in contributed code.
Requested by: rakuco
Improve options handling and error out if multiple mutually exclusive
options are passed to acpiconf. Switch from using atoi() to strtol() for
argument parsing, and add error checking and handling, instead of blindly
trusting that the integer conversion is OK.
Cange err() to errx() in once case, the errno value was garbage there.
Reviewed by: emaste
Approved by: emaste
Differential Revision: D13430
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
No functional change intended.
