acpi_timer: remove leftovers from Garbage-collect ACPI-safe timer and friends

Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D45669

acpi_timer: remove unused variable

the fixes kernel building after 00d061855deb

Garbage-collect ACPI-safe timer and friends

In 2001 when the ACPI timer was introduced, it included code to check
for a bug present in some Pentium II and Pentium III chipsets; if the
bug was found

Garbage-collect ACPI-safe timer and friends

In 2001 when the ACPI timer was introduced, it included code to check
for a bug present in some Pentium II and Pentium III chipsets; if the
bug was found to be present, ACPI-safe (which was slower but had a
workaround for the bug) would be used rather than ACPI-fast (which
read the same timer but without the workaround).

In a8b89dff6ac0 (September 2021) I disabled this check by default,
with a loader tunable available to re-enable it; I announced at the
time that it would go away in FreeBSD 15 if I didn't receive any
reports of problems. I have received no such problems, so this code
is now going away.

The debug.acpi.timer_test loader variable triggered a lengthy (in fact,
infinitely long) test of the ACPI timer and appears to have been
introduced as part of the process of writing the ACPI timer (and the
associated ACPI-safe workaround) in 2001; since we are dropping support
for systems with this ACPI bug, there is no need to keep that test code
either.

show more ...

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/

Adjust function definition in acpi_timer.c to avoid clang 15 warnings

With clang 15, the following -Werror warning is produced:

sys/dev/acpica/acpi_timer.c:402:16: error: a function declaration

Adjust function definition in acpi_timer.c to avoid clang 15 warnings

With clang 15, the following -Werror warning is produced:

sys/dev/acpica/acpi_timer.c:402:16: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
acpi_timer_test()
^
void

This is because acpi_timer_test() is declared with a (void) argument
list, but defined with an empty argument list. Make the definition match
the declaration.

MFC after: 3 days

show more ...

acpi: Remove unused devclass arguments to DRIVER_MODULE.

acpica: Remove CTLFLAG_NEEDGIANT from most sysctls.

MFC after: 2 weeks

Disable acpi_timer_test by default

This disables testing the ACPI timer by default, forcing the use of
ACPI-fast rather than ACPI-safe. The broken-ACPI-timers workaround
can be re-enabled by settin

Disable acpi_timer_test by default

This disables testing the ACPI timer by default, forcing the use of
ACPI-fast rather than ACPI-safe. The broken-ACPI-timers workaround
can be re-enabled by setting the hw.acpi.timer_test_enabled=1 tunable.

This speeds up the FreeBSD boot process by 140 ms on an EC2 c5.xlarge
instance.

This change will not be MFCed.

Assuming no problems are reported, acpi_timer_test, the associated
tunable, and the ACPI-safe timecounter should be removed in FreeBSD 15.

Relnotes: The ACPI-safe timer is disabled in favour of ACPI-fast;
if timekeeping issues are observed, please test with
hw.acpi.timer_test_enabled=1 in loader.conf and report
if that fixes the problem.

show more ...

Hide acpi_timer_test behind a tunable

When hw.acpi.timer_test_enabled is set to 0, this makes acpi_timer_test
return 1 without actually testing the ACPI timer; this results in the
ACPI-fast timecoun

Hide acpi_timer_test behind a tunable

When hw.acpi.timer_test_enabled is set to 0, this makes acpi_timer_test
return 1 without actually testing the ACPI timer; this results in the
ACPI-fast timecounter always being used rather than potentially using
ACPI-safe.

The ACPI timer testing was introduced in 2002 as a workaround for
errata in Pentium II and Pentium III chipsets, and is unlikely to be
needed in 2021.

While I'm here, add TSENTER/TSEXIT to make it easier to see the time
spent on the test (if it is enabled).

Reviewed by: allanjude, imp
MFC After: 1 week

show more ...

acpica: clean up empty lines in .c and .h files

Remove double-calls to tc_get_timecount() to warm timecounters.

It seems that second call does not add any useful state change for all
implemented timecounters.

Discussed with: bde
Sponsored by: Th

Remove double-calls to tc_get_timecount() to warm timecounters.

It seems that second call does not add any useful state change for all
implemented timecounters.

Discussed with: bde
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks

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 ...

MFH

Sponsored by: The FreeBSD Foundation

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physic

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).

Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.

Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)

Tested PAE and devinfo on virtualbox (live CD)

Special thanks to bz for his testing on ARM.

Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544

show more ...

MfH @r295202

Expect to see panics in routing code at least now.

Merge ^/head r294777 through r294960.

MFH

Sponsored by: The FreeBSD Foundation

Convert rman to use rman_res_t instead of u_long

Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources. For
now, this is still compatible with u_long.

This is step on

Convert rman to use rman_res_t instead of u_long

Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources. For
now, this is still compatible with u_long.

This is step one in migrating rman to use uintmax_t for resources instead of
u_long.

Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.

This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.

Reviewed By: jhb
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075

show more ...

Catch up with HEAD (r280229-r284686).

Merge sync of head

Merge from HEAD

If the power management timer is unsupported the PmTimerLength value will
be zero.

Merge from head@274682