acpi: Use device_set_descf()

No functional change intended.

MFC after: 1 week

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

acpi: Remove unused devclass arguments to DRIVER_MODULE.

acpi_ec: Use device_get_devclass to find devclass in probe.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D34989

acpi_ec(4): Don't probe erroneously if success occurred

In r360131, acpi_ec probe was changed to not clobber an error status prior to
several error cases that did not explicitly set the error variab

acpi_ec(4): Don't probe erroneously if success occurred

In r360131, acpi_ec probe was changed to not clobber an error status prior to
several error cases that did not explicitly set the error variable before
goto'ing the exit path. However, I did not notice that the error variable was
not set to success in the success path. That caused all successful probes to
fail, which is obviously undesirable.

PR: 245778
Reported by: Neel Chauhan <neel AT neelc.org>, Evilham <contact AT evilham.com>
Tested by: Evilham
X-MFC-With: r360131

show more ...

acpi_ec(4): Do not probe "successfully" if an error occurred

All of the 'goto out;' cases in this probe routine without explicit
initialization of 'ret' indicate error cases and were clearly intende

acpi_ec(4): Do not probe "successfully" if an error occurred

All of the 'goto out;' cases in this probe routine without explicit
initialization of 'ret' indicate error cases and were clearly intended
to use the initial definition of 'ret' with ENXIO. However, 'ret' was
accidentally squashed by reuse for a subroutine call near the beginning
of probe.

Use a different variable for the subroutine status to preserve ENXIO ret
for the 'goto out's as a minimal solution to the panic reported at attach
for now.

PR: 245757

show more ...

Merge ^/head r358269 through r358399.

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly mark

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.

This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Mark all obvious cases as MPSAFE. All entries that haven't been marked
as MPSAFE before are by default marked as NEEDGIANT

Approved by: kib (mentor, blanket)
Commented by: kib, gallatin, melifaro
Differential Revision: https://reviews.freebsd.org/D23718

show more ...

MFHead @348740

Sponsored by: The FreeBSD Foundation

Include ktr.h in more compilation units

Similar to r348026, exhaustive search for uses of CTRn() and cross reference
ktr.h includes. Where it was obvious that an OS compat header of some kind
inclu

Include ktr.h in more compilation units

Similar to r348026, exhaustive search for uses of CTRn() and cross reference
ktr.h includes. Where it was obvious that an OS compat header of some kind
included ktr.h indirectly, .c files were left alone. Some of these files
clearly got ktr.h via header pollution in some scenarios, or tinderbox would
not be passing prior to this revision, but go ahead and explicitly include it
in files using it anyway.

Like r348026, these CUs did not show up in tinderbox as missing the include.

Reported by: peterj (arm64/mp_machdep.c)
X-MFC-With: r347984
Sponsored by: Dell EMC Isilon

show more ...

Merge ^/head r340918 through r341763.

acpi/ec: Fix regression caused by r340644

After r340644 there were two things wrong in cases where there is both
an ECDT, and an EC device exposed via acpica. The first is a rather
trivial situation

acpi/ec: Fix regression caused by r340644

After r340644 there were two things wrong in cases where there is both
an ECDT, and an EC device exposed via acpica. The first is a rather
trivial situation where the device desc would say ECDT even when it was
not implicitly created via ECDT (not really sure why the compiler
doesn't seem to warn about this).

The other more pervasive issue is that the code is designed to
essentially not do anything for EC probe when its uid was already
created an EC based on the ECDT's uid. The issue was that probe would
still return 0 in this case, and so we'd end up with some weird
duplication. Now to be honest, I'm not actually sure what exactly broke,
but it was definitely not working as intended. To fix this, all that is
really needed is to make sure we return ENXIO when we're probing the
device already added for the ECDT entry. While here though, move the
check for this earlier to avoid wasted cycles when we know after
obtaining the uid that it's duplicative.

There remains one questionable bit here which I don't want to touch -
when doing probe for PNP0C09, if acquiring _UID for the device fails, 0
is assumed, which is a valid UID used by the implicit ECDT.

Reported by: Charlie Li, et al.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D18311

show more ...

Merge ^/head r340427 through r340868.

acpi: fix acpi_ec_probe to only check EC devices

This patch utilizes the fixed_devclass attribute in order to make sure
other acpi devices with params don't get confused for an EC device.

The exist

acpi: fix acpi_ec_probe to only check EC devices

This patch utilizes the fixed_devclass attribute in order to make sure
other acpi devices with params don't get confused for an EC device.

The existing code assumes that acpi_ec_probe is only ever called with a
dereferencable acpi param. Aside from being incorrect because other
devices of ACPI_TYPE_DEVICE may be probed here which aren't ec devices,
(and they may have set acpi private data), it is even more nefarious if
another ACPI driver uses private data which is not dereferancable. This
will result in a pointer deref during boot and therefore boot failure.

On X86, as it stands today, no other devices actually do this (acpi_cpu
checks for PROCESSOR type devices) and so there is no issue. I ran into
this because I am adding such a device which gets probed before
acpi_ec_probe and sets private data. If ARM ever has an EC, I think
they'd run into this issue as well.

There have been several iterations of this patch. Earlier
iterations had ECDT enumerated ECs not call into the probe/attach
functions of this driver. This change was Suggested by: jhb@.

Reviewed by: jhb
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D16635

show more ...

Merge ^/head r339670 through r339812.

Distinguish _CID match and _HID match and make lower priority probe
when _CID match.

Reviewed by: jhb, imp
Differential Revision:https://reviews.freebsd.org/D16468

Merge ^/head r309263 through r309518.

Fix for endless recursion in the ACPI GPE handler during boot.

When handling a GPE ACPI interrupt object the EcSpaceHandler()
function can be called which checks the EC_EVENT_SCI bit and then
recurs

Fix for endless recursion in the ACPI GPE handler during boot.

When handling a GPE ACPI interrupt object the EcSpaceHandler()
function can be called which checks the EC_EVENT_SCI bit and then
recurse on the EcGpeQueryHandler() function. If there are multiple GPE
events pending the EC_EVENT_SCI bit will be set at the next call to
EcSpaceHandler() causing it to recurse again via the
EcGpeQueryHandler() function. This leads to a slow never ending
recursion during boot which prevents proper system startup, because
the EC_EVENT_SCI bit never gets cleared in this scenario.

The behaviour is reproducible with the ALASKA AMI in combination with
a newer Skylake based mainboard in the following way:

Enter BIOS and adjust the clock one hour forward. Save and exit the
BIOS. System fails to boot due to the above mentioned bug in
EcGpeQueryHandler() which was observed recursing multiple times.

This patch adds a simple recursion guard to the EcGpeQueryHandler()
function and also also adds logic to detect if new GPE events occurred
during the execution of EcGpeQueryHandler() and then loop on this
function instead of recursing.

Reviewed by: jhb
MFC after: 2 weeks

show more ...

Merge ^/head r295902 through r296006.

MFH

Sponsored by: The FreeBSD Foundation

Silence PVS-Studio warning (V595).

Merge sync of head

Merge from HEAD

Merge ^/head r277327 through r277718.

MFhead @ r277659