asmc(4): Stop building it on i386, as it supports only 64-bit chipsets
Reported by: ngie
Fixes: fde9fe18219f ("i386: Fix kernel compilation after introduction of ASMC_DEBUG option")
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 8342d9f7b5f13d0623861cb8b88caf10a15571f6)
t_ptrace_wait.c: clean up trailing whitespace
This is being done to aid with future potential updates of this file.
MFC after: 1 week
(cherry picked from commit fa3519d068d95f87e773d27f96e9f1e18f70075a)
t_ptrace_wait.c: clean up trailing whitespace
This is being done to aid with future potential updates of this file.
MFC after: 1 week
(cherry picked from commit fa3519d068d95f87e773d27f96e9f1e18f70075a)
chore: asmc: minor code cleanup
- Use symbolic names in Mac definitions in lieu of the unrolled values
they represent.
- Delete trailing whitespace.
- Fix indentation.
No functional change intended.
MFC after: 1 week
(cherry picked from commit a8f3c3b5d4d9dac1dafe4094fe35b30ffdf26178)
chore: asmc: additional style(9) cleanup
Pick out non-gratuitous style(9) changes suggested by `clang-format` on
the driver. This helps eliminate minor stylistic issues with spaces,
braces, line lengths, etc, so future functional changes in the driver
will be easier to pick out.
Many of the other `clang-format` suggested changes were not taken because
they were considerably more gratuitous.
No functional change intended.
MFC after: 1 week
(cherry picked from commit d76bb14e0224e235209d8c07ec132d602b18648b)
Add ASMC_DEBUG make option
This allows folks to enable debug statements in asmc(4) using kernel
configs via the `options ASMC_DEBUG` directive.
While here, remove a duplicate `device vt_efifb` directive in `NOTES`
as it's already handled in the `GENERIC` config
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54511
(cherry picked from commit f224591746bdaf14ad5f63de4738a3146cc2f55f)
chore: asmc: additional style(9) cleanup
Pick out non-gratuitous style(9) changes suggested by `clang-format` on
the driver. This helps eliminate minor stylistic issues with spaces,
braces, line lengths, etc, so future functional changes in the driver
will be easier to pick out.
Many of the other `clang-format` suggested changes were not taken because
they were considerably more gratuitous.
No functional change intended.
MFC after: 1 week
(cherry picked from commit d76bb14e0224e235209d8c07ec132d602b18648b)
chore: asmc: minor code cleanup
- Use symbolic names in Mac definitions in lieu of the unrolled values
they represent.
- Delete trailing whitespace.
- Fix indentation.
No functional change intended.
MFC after: 1 week
(cherry picked from commit a8f3c3b5d4d9dac1dafe4094fe35b30ffdf26178)
Unbreak the build
Add the missing comma in the `device_printf` statement.
MFC after: 1 week
MFC with: 9c666de5b
Fixes: 9c666de5b ("Make message added for Darwin OSI quirk more terse")
(cherry picked from commit cc702c78f70f972cf2f8ea008752d96df1989988)
Make message added for Darwin OSI quirk more terse
The verbose message was way too verbose. Make it terse.
MFC after: 1 week
MFC with: 052a791b00 ("acpi: add Darwin OSI quirk for Apple Mac hardware")
Requested by: kib
(cherry picked from commit 9c666de5b339d3c8f9bf3963691e4310e7d159cb)
acpi: add Darwin OSI quirk for Apple Mac hardware
Mac firmware hides the Intel integrated GPU (iGPU) on dual GPU x86
systems, i.e., with AMD/NVIDIA dGPUs, when the Darwin OSI is not
installed via ACPI.
Prior to this change, FreeBSD always used the dGPU. This is fine in
practice, but consumed more power than when the iGPU is used,
resulting in reduced battery life.
Linux handles this in `drivers/acpi/osi.c` by detecting Apple
hardware via DMI, disabling all Windows OSI strings, and
by explicitly installing the Darwin OSI ACPI handler. This change
applies equivalent logic to the acpi(4) driver on FreeBSD.
This feature can be enabled/disabled using the
`hw.acpi.apple_darwin_osi` tunable. Setting this tunable to `0`
restores the previous behavior by explicitly disabling the added
support.
[5 lines not shown]
Unbreak the build
Add the missing comma in the `device_printf` statement.
MFC after: 1 week
MFC with: 9c666de5b
Fixes: 9c666de5b ("Make message added for Darwin OSI quirk more terse")
(cherry picked from commit cc702c78f70f972cf2f8ea008752d96df1989988)
acpi: add Darwin OSI quirk for Apple Mac hardware
Mac firmware hides the Intel integrated GPU (iGPU) on dual GPU x86
systems, i.e., with AMD/NVIDIA dGPUs, when the Darwin OSI is not
installed via ACPI.
Prior to this change, FreeBSD always used the dGPU. This is fine in
practice, but consumed more power than when the iGPU is used,
resulting in reduced battery life.
Linux handles this in `drivers/acpi/osi.c` by detecting Apple
hardware via DMI, disabling all Windows OSI strings, and
by explicitly installing the Darwin OSI ACPI handler. This change
applies equivalent logic to the acpi(4) driver on FreeBSD.
This feature can be enabled/disabled using the
`hw.acpi.apple_darwin_osi` tunable. Setting this tunable to `0`
restores the previous behavior by explicitly disabling the added
support.
[5 lines not shown]
Make message added for Darwin OSI quirk more terse
The verbose message was way too verbose. Make it terse.
MFC after: 1 week
MFC with: 052a791b00 ("acpi: add Darwin OSI quirk for Apple Mac hardware")
Requested by: kib
(cherry picked from commit 9c666de5b339d3c8f9bf3963691e4310e7d159cb)
Remove example tests when MK_EXAMPLES=no
This change cleans up example tests for atf, googletest, plain, and TAP
when MK_EXAMPLES=no. Not having this in results
`kyua test -k /usr/tests/share/examples/Kyuafile` being broken on a host
where the content in that directory tree is stale. I ran into that case
because at some point in time in the past I had specified
`MK_GOOGLETEST=no` one of my dev instances.
MFC after: 1 week
(cherry picked from commit cea2683bb691d6cbcfb7e342c497d018bba712c2)
Remove example tests when MK_EXAMPLES=no
This change cleans up example tests for atf, googletest, plain, and TAP
when MK_EXAMPLES=no. Not having this in results
`kyua test -k /usr/tests/share/examples/Kyuafile` being broken on a host
where the content in that directory tree is stale. I ran into that case
because at some point in time in the past I had specified
`MK_GOOGLETEST=no` one of my dev instances.
MFC after: 1 week
(cherry picked from commit cea2683bb691d6cbcfb7e342c497d018bba712c2)
openssl: add a simple smoke test for the legacy provider
This change adds a simple smoke test for the legacy provider to ensure
that the provider doesn't break in the future when performing updates.
This is not a functional or system test; the OpenSSL test suite does a
much better job at doing this than we can.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53045
(cherry picked from commit 3b6442370a17c57c4c290b9a8e1e8328da820705)
asmc: Add support for MacBookPro11,5
Add support for the MacBookPro11,5 (Mid 2015, 15-inch with AMD Radeon R9 M370X GPU)
to the Apple SMC driver.
Debug testing revealed this model lacks several SMC keys present on MacBookPro11,4
(IBLC, ICMC, IC2C), that model-specific sensor definitions.
Differential Revision: https://reviews.freebsd.org/D54665
Reviewed by: adrian
(cherry picked from commit c498eaa2f9090d7bdc6456181d8bf74869288bbb)
asmc: improve asmc_dumpall to read actual SMC key count
The asmc_dumpall debug function previously used a hardcoded loop limit
of 0x100 (256) keys with a "XXX magic number" comment.
This change improves asmc_dumpall to:
* Read the actual number of keys from the ASMC_NKEYS SMC key
* Print the key count being dumped for better debugging output
* Loop only up to the actual key count (e.g., 297 on Mac Mini 5,1)
This provides more accurate debug output and removes the magic number.
Tested on Mac Mini 5,1 (FreeBSD 16.0-CURRENT):
* Rebuild kernel with DEBUG enabled in asmc driver
* Boot with new kernel
* Verify dmesg shows "asmc_dumpall: dumping 297 keys" (or actual count)
* Verify all 297 keys are dumped
[5 lines not shown]
asmc: Add support for MacBookPro11,5
Add support for the MacBookPro11,5 (Mid 2015, 15-inch with AMD Radeon R9 M370X GPU)
to the Apple SMC driver.
Debug testing revealed this model lacks several SMC keys present on MacBookPro11,4
(IBLC, ICMC, IC2C), that model-specific sensor definitions.
Differential Revision: https://reviews.freebsd.org/D54665
Reviewed by: adrian
(cherry picked from commit c498eaa2f9090d7bdc6456181d8bf74869288bbb)
asmc: add per-fan manual mode control via sysctl
Add per-fan manual mode control via dev.asmc.0.fan.N.manual sysctl.
Apple SMCs support manual fan control via the FS! SMC key,
a 16-bit bitmask where each bit controls one fan (0=auto, 1=manual).
This change adds a new sysctl per fan:
dev.asmc.0.fan.N.manual (0=auto, 1=manual)
When set to manual mode (1), the fan runs at the speed set via
dev.asmc.0.fan.N.targetspeed instead of automatic thermal control. When
set to auto mode (0), the SMC controls fan speed automatically.
The FS! key was already defined in asmcvar.h but not accessible.
This exposes it for debugging, testing, and advanced fan control.
Implementation uses read-modify-write to allow independent control of
each fan without affecting others.
[6 lines not shown]
asmc: improve asmc_dumpall to read actual SMC key count
The asmc_dumpall debug function previously used a hardcoded loop limit
of 0x100 (256) keys with a "XXX magic number" comment.
This change improves asmc_dumpall to:
* Read the actual number of keys from the ASMC_NKEYS SMC key
* Print the key count being dumped for better debugging output
* Loop only up to the actual key count (e.g., 297 on Mac Mini 5,1)
This provides more accurate debug output and removes the magic number.
Tested on Mac Mini 5,1 (FreeBSD 16.0-CURRENT):
* Rebuild kernel with DEBUG enabled in asmc driver
* Boot with new kernel
* Verify dmesg shows "asmc_dumpall: dumping 297 keys" (or actual count)
* Verify all 297 keys are dumped
[5 lines not shown]
