src/sys/dev/acpica, branch releng/14.2 FreeBSD source tree ACPI: Add ACPI_Q_AEI_NOPULL quirk and use in EC2 2024-11-03T16:15:22+00:00 Colin Percival cperciva@FreeBSD.org 2024-10-22T14:47:30+00:00 28b881840df7cbf9c01ddec86f45a080619efaa7 AWS Graviton [1234] systems have a bug in their ACPI where they mark the PL061's GPIO pins as needing to be configured in PullUp mode (in fact the PL061 has no pullup/pulldown resistors); this flag needs to be removed in order for _AEI objects to be handled on these systems. Reviewed by: Ali Saidi Approved by: re (kib) MFC after: 1 week Sponsored by: Amazon Differential Revision: https://reviews.freebsd.org/D47239 (cherry picked from commit 2f3f867ac6dd7ff3769366b828b79c44b38828e1) (cherry picked from commit 5fa51c3653b14b364e26a4cce2733c7be6ee7721) 
AWS Graviton [1234] systems have a bug in their ACPI where they mark
the PL061's GPIO pins as needing to be configured in PullUp mode (in
fact the PL061 has no pullup/pulldown resistors); this flag needs to
be removed in order for _AEI objects to be handled on these systems.

Reviewed by:	Ali Saidi
Approved by:	re (kib)
MFC after:	1 week
Sponsored by:	Amazon
Differential Revision:	https://reviews.freebsd.org/D47239

(cherry picked from commit 2f3f867ac6dd7ff3769366b828b79c44b38828e1)
(cherry picked from commit 5fa51c3653b14b364e26a4cce2733c7be6ee7721)
ACPI: Implement power button on !x86 2024-11-03T16:15:12+00:00 Colin Percival cperciva@FreeBSD.org 2024-10-12T17:27:39+00:00 c90ebd3fa356406e152fff4475431c9fd66ea84e ACPI sleep states are only implemented on x86 systems, so having the ACPI power button attempt to enter "S5" (or other state as configured via the hw.acpi.power_button_state sysctl) is not useful. On non-x86 systems, implement the power button with a call to shutdown_nice(RB_POWEROFF) to shut down the system. Reviewed by: Andrew Tested on: Graviton 2 Approved by: re (kib) MFC after: 2 weeks Sponsored by: Amazon Differential Revision: https://reviews.freebsd.org/D47094 (cherry picked from commit f41ef9d80b3d272e08dd9e2ea3c1d8d3f2818066) (cherry picked from commit e177e64294556bdece642442d6691523a4294b67) 
ACPI sleep states are only implemented on x86 systems, so having the
ACPI power button attempt to enter "S5" (or other state as configured
via the hw.acpi.power_button_state sysctl) is not useful.

On non-x86 systems, implement the power button with a call to
    shutdown_nice(RB_POWEROFF)
to shut down the system.

Reviewed by:	Andrew
Tested on:	Graviton 2
Approved by:	re (kib)
MFC after:	2 weeks
Sponsored by:	Amazon
Differential Revision:	https://reviews.freebsd.org/D47094

(cherry picked from commit f41ef9d80b3d272e08dd9e2ea3c1d8d3f2818066)
(cherry picked from commit e177e64294556bdece642442d6691523a4294b67)
acpi_ged: Handle events directly 2024-10-28T23:02:24+00:00 Andrew Gallatin gallatin@FreeBSD.org 2023-10-12T15:15:06+00:00 ee373c1234d33d68e91fbe51f846e265cbce9e72 Handle ged interrupts directly from the interrupt handler, while the interrupt source is masked, so as to conform with the acpi spec, and avoid spurious interrupts and lockups on boot. When an acpi ged interrupt is encountered, the spec requires the os (as stated in 5.6.4: General Purpose Event Handling) to leave the interrupt source masked until it runs the EOI handler. This is not a good fit for our method of queuing the work (including the EOI ack of the interrupt), via the AcpiOsExecute() taskqueue mechanism. Note this fixes a bug where an arm64 server could lock up if it encountered a ged interrupt at boot. The lockup was due to running on a single core (due to arm64 not using EARLY_AP_STARTUP), and due to that core encountering a new interrupt each time the interrupt handler unmasked the interrupt source, and having the EOI queued on a taskqueue which never got a chance to run. This is also possible on any platform when using just a single processor. The symptom of this is a lockup at boot, with: "AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable" scrolling on console. Similarly, spurious interrupts would occur when running with multiple cores, because it was likely that the interrupt would fire again immediately, before the ged task could be run, and before an EOI could be sent to lower the interrupt line. I would typically see 3-5 copies of every ged event due to this issue. This adds a tunable, debug.acpi.ged_defer, which can be set to 1 to restore the old behavior. This was done because acpi is a complex system, and it may be theoretically possible something the ged handler does may sleep (though I cannot easily find anthing by inspection). MFC after: 1 month Reviewed by: andrew, jhb, imp Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D42158 (cherry picked from commit be91b4797e2c8f3440f6fe3aac7e246886f9ebca) 
Handle ged interrupts directly from the interrupt handler,
while the interrupt source is masked, so as to conform
with the acpi spec, and avoid spurious interrupts and
lockups on boot.

When an acpi ged interrupt is encountered, the spec requires
the os (as stated in 5.6.4: General Purpose Event Handling)
to leave the interrupt source masked until it runs the
EOI handler.  This is not a good fit for our method of
queuing the work (including the EOI ack of the interrupt),
via the AcpiOsExecute() taskqueue mechanism.

Note this fixes a bug where an arm64 server could lock up if
it encountered a ged interrupt at boot.  The lockup was
due to running on a single core (due to arm64 not using
EARLY_AP_STARTUP), and due to that core encountering a
new interrupt each time the interrupt handler unmasked
the interrupt source, and having the EOI queued on a taskqueue
which never got a chance to run. This is also possible
on any platform when using just a single processor.
The symptom of this is a lockup at boot, with:
"AcpiOsExecute: failed to enqueue task, consider
increasing the debug.acpi.max_tasks tunable" scrolling
on console.

Similarly, spurious interrupts would occur when running
with multiple cores, because it was likely that the
interrupt would fire again immediately, before the
ged task could be run, and before an EOI could be sent
to lower the interrupt line.  I would typically see
3-5 copies of every ged event due to this issue.

This adds a tunable, debug.acpi.ged_defer, which can be
set to 1 to restore the old behavior.  This was done
because acpi is a complex system, and it may be
theoretically possible something the ged handler does
may sleep (though I cannot easily find anthing by inspection).

MFC after: 1 month
Reviewed by: andrew, jhb, imp
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42158

(cherry picked from commit be91b4797e2c8f3440f6fe3aac7e246886f9ebca)
acpi: Narrow workaround for broken interrupt settings on x86 2024-07-22T19:54:14+00:00 John Baldwin jhb@FreeBSD.org 2024-07-15T19:13:08+00:00 4ba4cfaf9f2991fea0d438e915df8b681a47facf Commit 9a7bf07ccdc1 from 2016 introduced a workaround for some broken BIOSes that specified active-lo instead of active-hi polarity for ISA IRQs for UARTs. The workaround assumed that edge-sensitive ISA IRQs on x86 should always be active-hi. However, some recent AMD systems actually use active-lo edge-sensitive ISA IRQs (and not just for UARTs, but also for the keyboard and PS/2 mouse devices) and the override causes interrupts to be dropped resulting in boot time hangs, non-working keyboards, etc. Add a hw.acpi.override_isa_irq_polarity tunable (readable as a sysctl post-boot) to control this quirk. It can be set to 1 to force enable the override and 0 to disable it. The log of original message mentions an Intel motherboard as the sample case, so default the tunable to 1 on systems with an Intel CPU and 0 otherwise. Special thanks to Matthias Lanter <freebsd@lanter-it.ch> for tracking down boot time issues on recent AMD systems to mismatched interrupt polarity. PR: 270707 Reported by: aixdroix_OSS@protonmail.com, Michael Dexter Reported by: mfw_burn@pm.me, Hannes Hfauswedell <h2+fbsdports@fsfe.org> Reported by: Matthias Lanter <freebsd@lanter-it.ch> Reported by: William Bulley <web@umich.edu> Reviewed by: imp, emaste MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D45554 (cherry picked from commit 0a34d050ae8ea14feddd3d2a62fd2f612613b2c5) 
Commit 9a7bf07ccdc1 from 2016 introduced a workaround for some broken
BIOSes that specified active-lo instead of active-hi polarity for ISA
IRQs for UARTs.  The workaround assumed that edge-sensitive ISA IRQs
on x86 should always be active-hi.  However, some recent AMD systems
actually use active-lo edge-sensitive ISA IRQs (and not just for
UARTs, but also for the keyboard and PS/2 mouse devices) and the
override causes interrupts to be dropped resulting in boot time hangs,
non-working keyboards, etc.

Add a hw.acpi.override_isa_irq_polarity tunable (readable as a sysctl
post-boot) to control this quirk.  It can be set to 1 to force enable
the override and 0 to disable it.  The log of original message
mentions an Intel motherboard as the sample case, so default the
tunable to 1 on systems with an Intel CPU and 0 otherwise.

Special thanks to Matthias Lanter <freebsd@lanter-it.ch> for tracking
down boot time issues on recent AMD systems to mismatched interrupt
polarity.

PR:		270707
Reported by:	aixdroix_OSS@protonmail.com, Michael Dexter
Reported by:	mfw_burn@pm.me, Hannes Hfauswedell <h2+fbsdports@fsfe.org>
Reported by:	Matthias Lanter <freebsd@lanter-it.ch>
Reported by:	William Bulley <web@umich.edu>
Reviewed by:	imp, emaste
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D45554

(cherry picked from commit 0a34d050ae8ea14feddd3d2a62fd2f612613b2c5)
acpi: Use device_set_descf() 2024-06-09T13:37:55+00:00 Mark Johnston markj@FreeBSD.org 2024-02-04T23:51:27+00:00 54c4a726f56d035c0ba17c14f74da43aaa21d74a No functional change intended. MFC after: 1 week (cherry picked from commit bad36a49985c3cd7bfcb1b35ce3ae37f007843ce) 
No functional change intended.

MFC after:	1 week

(cherry picked from commit bad36a49985c3cd7bfcb1b35ce3ae37f007843ce)
acpi_battery: avoid divide-by-zero when no devices have capacity info 2024-04-19T03:16:52+00:00 Josef 'Jeff' Sipek jeffpc@josefsipek.net 2024-04-16T23:01:28+00:00 788987e034b1c73d779a3aa179f79f672bbdb366 On laptops with builtin batteries, disconnecting the battery may show up as a battery without any capacity information. (The theory is that one is disconnecting the cells but the electronics identifying the battery are still connected.) As a result, the loop over all batteries in acpi_battery_get_battinfo results in total_lfcap == 0. So, just check that total_lfcap is non-zero to avoid a division by zero (triggerable by sysctl hw.acpi.battery). Reported by: Stefano Marinelli Tested by: Stefano Marinelli Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D44818 (cherry picked from commit 2e850b832f5d2adb9b230d191277d67c00caaab9) 
On laptops with builtin batteries, disconnecting the battery may show up
as a battery without any capacity information. (The theory is that one
is disconnecting the cells but the electronics identifying the battery
are still connected.) As a result, the loop over all batteries in
acpi_battery_get_battinfo results in total_lfcap == 0.

So, just check that total_lfcap is non-zero to avoid a division by zero
(triggerable by sysctl hw.acpi.battery).

Reported by:	Stefano Marinelli
Tested by:	Stefano Marinelli
Reviewed by:	emaste
Differential Revision: https://reviews.freebsd.org/D44818

(cherry picked from commit 2e850b832f5d2adb9b230d191277d67c00caaab9)
acpi: Don't assume a resource is reserved in acpi_delete_resource 2024-04-08T17:55:58+00:00 John Baldwin jhb@FreeBSD.org 2024-02-14T22:07:32+00:00 cfb8cc9c5fa942ef51d3738851efd63ba0aeaccd This fixes a panic if a driver uses bus_set_resource to add a resource that fails to reserve and then deletes the resource via bus_delete_resource. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D43891 (cherry picked from commit e05436d577de98944b97b9cf510b29c4d2091b3f) 
This fixes a panic if a driver uses bus_set_resource to add a resource
that fails to reserve and then deletes the resource via
bus_delete_resource.

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

(cherry picked from commit e05436d577de98944b97b9cf510b29c4d2091b3f)
acpi: Allow child drivers to use bus_set_resource for more resources 2024-04-08T17:54:35+00:00 John Baldwin jhb@FreeBSD.org 2024-02-14T22:07:32+00:00 75a63c968af999918fd2d6ba98ba5d86c0ea6188 acpi_set_resource excludes certain types of resources for certain devices. The intention of this is to avoid adding resource entries for bogus resources enumerated via _CRS. However, this also prevents drivers from adding those resources explicitly if needed. To fix this, move the logic to exclude these resources into an ignore hook used when parsing _CRS to create the initial set of resources for each device. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D43892 (cherry picked from commit 055c1fe230ce5a2997c03a3cc2431baea1594566) 
acpi_set_resource excludes certain types of resources for certain
devices.  The intention of this is to avoid adding resource entries
for bogus resources enumerated via _CRS.  However, this also prevents
drivers from adding those resources explicitly if needed.  To fix
this, move the logic to exclude these resources into an ignore hook
used when parsing _CRS to create the initial set of resources for each
device.

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

(cherry picked from commit 055c1fe230ce5a2997c03a3cc2431baea1594566)
acpi: Use bus_generic_alloc_resource instead of duplicating it 2024-04-08T17:53:25+00:00 John Baldwin jhb@FreeBSD.org 2024-02-09T18:27:45+00:00 00dbe607b392c81ffec78f5e8123413cad606a7a No functional change, but it is cleaner to use the existing generic wrappers rather than KOBJ methods directly. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D43686 (cherry picked from commit 1fb5445206a5ef2351c32f8bc6beb67605593caa) 
No functional change, but it is cleaner to use the existing generic
wrappers rather than KOBJ methods directly.

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

(cherry picked from commit 1fb5445206a5ef2351c32f8bc6beb67605593caa)
acpi: Use kobj typedefs for new-bus method prototypes 2024-04-08T17:51:56+00:00 John Baldwin jhb@FreeBSD.org 2024-02-09T18:27:44+00:00 cbc47b31cc66c73104ac8420c8428f2fd8be8d59 Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D43685 (cherry picked from commit 0e72b8d36562cb7ecf610dbd7357af830820e4b4) 
Reviewed by:	imp
Differential Revision:	https://reviews.freebsd.org/D43685

(cherry picked from commit 0e72b8d36562cb7ecf610dbd7357af830820e4b4)