ig4: unconditionally un-idle the controller core on resume
On controllers with the LPSS "additional registers" (Skylake and later,
IG4_HAS_ADDREGS), ig4iic_suspend() places the controller in the device
idle state (IG4_DEVICE_IDLE) and asserts core reset. While idle the
DesignWare core is power-gated: its register bank reads back as zero and
writes are dropped until the core is taken out of the idle state again.
ig4iic_set_config(), called from ig4iic_resume(), only performs that
un-idle handshake when it observes IG4_RESTORE_REQUIRED set in
DEVIDLE_CTRL. Some platforms (e.g. Intel Alder Lake-P) do not raise
that status across suspend-to-idle (S0ix). The core is then left gated:
set_config()'s register writes have no effect, it nevertheless returns
success, and every subsequent transfer fails with IIC_ETIMEOUT, leaving
child I2C-HID devices (touchpad, touchscreen) dead after resume.
Give ig4iic_set_config() a force_restore argument and pass it from
ig4iic_resume() so the un-idle handshake runs unconditionally for
IG4_HAS_ADDREGS controllers, regardless of the RESTORE_REQUIRED status.
[22 lines not shown]
pgpkeys: Add myself to the list
My pgp key has been in the repo for many years but apparently I wasn't
listed in the pgpkeys article.
PR: 296173
Reported by: elivoncoder
graphics/fractgen: Improve port
- Simplify option names: FRACTGEN_CLI => CLI and etc.
- Move CLI KDE QT to MULTI - at least on option must be enabled.
- Move examples from DATADIR to EXAMPLESDIR.
- Sort plist.
PR: 295702
Approved by: Thomas Dreibholz <thomas.dreibholz at gmail.com> (maintainer, timeout 2 weeks)
Sponsored by: UNIS Labs
da: Put the SYNC CACHE probing behind bootverbose
These have turned out to be too noisy, so put them behind bootverbose
Event: BSDCan 2026 (noticed during UFS demo)
Sponsored by: Netflix
MFC After: 2 weeks
periodic/security: Introduce $security_status_loginfail_ignore for 800.loginfail
Introduce a new variable "security_status_loginfail_ignore" to filter unwanted
login failure messages from the daily security checks.
Co-authored-by: Michael Osipov <michaelo at FreeBSD.org>
Co-authored-by: Joseph Mingrone <jrm at FreeBSD.org>
PR: 295191
Reviewed by: jrm
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D57671
