Repository navigation
Merge integration/aurora 11943fb9 into aurora-wip (wip sync 4) - #1195
Merged
Merged
Conversation
Add a capability-gated Type-C contaminant state with unknown, none and liquid values. Notify sysfs and emit a port change uevent only when the state changes. Enable the SN201202x LDCM event, validate and decode its complete status snapshot in serialized work, and refresh it after controller reset and system resume. Keep this patch read-only so status reporting can be qualified independently from controller-side mitigation. Assisted-by: LLM Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com>
Acknowledge liquid and indeterminate LDCM states by enabling the controller's mitigation before publishing them. Remove mitigation only after a clean snapshot, then re-read the detector before reporting dry. Keep the local Type-C role and data path disconnected while the state is liquid or unknown. On status or command failure, publish unknown, retain the safe local state and retry without a bounded failure window. Apply the same ordering to suspend-time events and controller reset recovery. Assisted-by: LLM Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com>
The SN201202x SPMI driver is a separate module and calls tps6598x_block_read() and tps6598x_exec_cmd_tmo() for the LDCM status. With CONFIG_TYPEC_TPS6598X=m modpost fails on both undefined symbols. Assisted-by: LLM Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com>
Newer ANS firmware moves the linear submission queue doorbells (+0x24908/+0x24910) into the NVMMU block and ends the "nvme" register block at 0x10000, before them. T6040 selects that layout by compatible. T8142 can run either layout, depending on the ANS firmware of the macOS stub it boots. The J813 device tree describes a 0x30000 "nvme" block with the doorbells in it. A J704 booting the macOS 27.0 stub has them in the NVMMU instead, and its ADT gives the "nvme" block as 0x10000 (ans reg[9]). With the compatible alone the driver would write the doorbells past the end of that mapping. Take the layout from the device tree as well: when the "nvme" window does not reach the doorbells, they are in the NVMMU block, and the firmware has already enabled them, as on T6040. Device trees whose "nvme" window covers the doorbells, including the current J813 one, keep the existing behaviour. Tested on a MacBook Pro (14-inch, M5) J704 booting the macOS 27.0 stub: the root filesystem on the internal SSD is used daily. Signed-off-by: Dmitriy <noc@pimk.in> Assisted-by: LLM
Linux only took back-to-back Touch ID touches with a gap: after every touch the next capture waited a fixed 1.8 s from the end of the last one (MATCH_SETTLE_MS), and an enrolment waited 1.8 s between every placement (ENROL_REPOSITION_MS). A finger journal shows touches inside one sudo prompt 2.5-3 s apart, 1.8 s of it this pause. A trace of a macOS 26.6.2 Touch ID prompt on the same MacBook Neo (three wrong touches; sensor SPI traffic and SBIO calls with microsecond timestamps) shows what macOS does instead: - After the frames of a touch are taken it sends PAUSE_CAPTURE (0x80 0x41) rather than idling the sensor. The sensor stops imaging but keeps watching the finger and falls to idle (state 0) the moment the finger is lifted; macOS arms the next capture (START_CAPTURE) 1-2 ms later. Touches were 1.35-1.37 s apart: the finger lifted 0.3-0.4 s after each result and was back 0.5-0.7 s after the lift. - One START_CAPTURE yields a frame every ~80 ms while the finger stays down; the no-match tail relays the frames taken while MATCH_RESULT ran (13 ms for the whole tail). - The no-match reaches LocalAuthentication 0.36 s after the finger lands. SAVE_LOCKOUT and the background result follow it (after MATCH_CANCEL when the prompt ends) while the finger is lifted. Do the same: - End every verify and enrolment touch with PAUSE_CAPTURE and arm the next capture when the sensor reports the finger lifted (idle or armed), interrupt-driven with a 20 ms backstop. Frames imaged before the pause took effect are read and dropped. While the finger stays down the poll reports the new SEP_BIO_GUIDANCE_LIFT. The fixed 1.8 s waits are gone. - Take the no-match tail's frames from the running capture first, and start it again only when the sensor stopped imaging. - Report a no-match as soon as the touch is finished, then save the lockout record (once per result, after MATCH_CANCEL when the prompt ends, as macOS does; it was saved twice), collect the background result and persist. The next verify waits for this work before its capture, as before. A match is still reported only after its template update is persisted. The per-prompt match operation, the no-match tail and the host retry limit from the lockout fix are unchanged. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
An enrolment touch gives one frame. In a macOS 26.6.2 enrolment trace on the MacBook Neo, PAUSE_CAPTURE (0x80 0x41) follows the frame by about 200 ms, while the enclave is still processing it. The sensor reports the lift with the enclave's answer still pending, and the next capture is armed 3 ms after the lift. Touches were about 1 s apart. Pause right after the frame is read instead of after the enclave's answer, and pause in the loop only if the frame could not be read. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Picks up the tools/aurora-sep source-check fix (c60537c) and the current release branch, so CI runs against today's base. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Read the lift from the sensor's finger detector, not from its state alone. In the macOS trace the status flags byte (status[11]) reads 0x0c while the sensor is armed or idle with no finger, 0x0e once a finger is on, and 0x8e with a frame ready. At the lift interrupt macOS reads state 0 with flags 0x0c. A paused sensor whose state is idle but whose detector still sees the finger must not count as lifted, or the next capture would take the resting finger. Log the first status and the lifting status, so the finger test shows what the sensor reports while paused. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Touch ID gave no reason when a capture did not count. A verify that ended with the retry status (no finger in time, an unreadable frame, partial contact) carried whatever guidance the capture last had, so userspace could only say "scan again". An enrolment capture that did not count was never reported at all: the poll's retry status, which libfprint's aurora driver already maps to a retry, was never set. Name the cause in the poll's guidance alongside the retry: PLACE when no finger came in time, LIFT_AND_MOVE for a frame that could not be read, and the new SEP_BIO_GUIDANCE_CENTER (5) for partial contact. SEP_BIO_GUIDANCE_TOO_FAST (6) and SEP_BIO_GUIDANCE_CLEAN (7) are reserved for the image-assessment feedback (the finger moved; dirt or moisture), which the matching code can report later. A running enrolment's poll now carries the retry status once per capture that did not count, with its cause. Older readers ignore the guidance of a failed verify and already handle the enrolment retry. Decode the sensor status in Status::parse and name the lift test Status::finger_off(). Add KUnit cases that replay the GET_STATUS replies the sensor gave macOS in our own trace (an LA prompt with three misses and an enrolment): every status decodes to the finger-on/finger-off verdict macOS reached, and a lift detector over the three-touch sequence fires exactly at macOS's three FingerOFF events and never on a frame. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
… once Split the enrolment poll into what it reports (enrol_poll_report) and marking its one-shot reports seen (mark_enrol_seen), which now happens only once the poll reached userspace. A KUnit case drives a session: an uncounted capture is reported once with its cause, the next poll carries none, a later stage is reported without a retry, and a stale worker cannot report into a newer enrolment. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
… macOS does macOS has two Touch ID retry limits. LocalAuthentication ends a Touch ID prompt after three failed matches and offers the password, but the enclave stays unlocked and the next prompt offers Touch ID again. The enclave itself locks the user's biometry after five completed no-matches (lock state bit 0x40), and only a password clears that. Captured on macOS 26.6.2: an LA prompt with three misses kept lock state 0x228 throughout, while a lock screen with five misses moved it to 0x45. The driver had one limit, three failed matches in a row across prompts, and it locked Touch ID until a password. A person who missed three times in sudo could not use Touch ID at the next prompt, unlike on macOS. Apply both limits. The third miss in a prompt ends that prompt's match operation (MATCH_CANCEL), as LocalAuthentication does, without locking Touch ID. The fifth miss since the last match or password re-arm locks it on the host and records the lock, as before. macOS also keeps the match operation open across a touch that gave no usable frame (it cleans the image up and takes the next frame). The driver ended the prompt instead, cancelled the operation, closed the unlock evaluation and power-cycled the sensor, so the next touch paid for a full bring-up and a new evaluation. A retry straight from the capture (no finger in time, partial contact, a damaged frame) now keeps the prompt, its operation and the registered sensor. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
macOS starts every Touch ID enrolment with BEGIN_ENROL (0x03) and then, before the first capture, OPERATION_DEVICE_LIST (0x7d): the same request that opens a match operation, here for the enrolment. The driver sent only BEGIN_ENROL, so its enrolments ran without the device list macOS sets up for them. Captured on macOS 26.6.2 during a System Settings enrolment. Send it after BEGIN_ENROL and require a well-formed list with at least one device; otherwise cancel the enrolment before any capture. Require at least one device when a match operation opens too. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
…ttempts across a restart The enclave announces a user's biometric lock state as a 16-bit word. macOS 26.6.2 names its bits: 0x02 password lockout, 0x04 biometry lockout, 0x08 unlock token, 0x10 before first unlock, 0x20 password validated, 0x40 identification lockout, 0x80 catacomb corrupted. The driver read only 0x40, so a password lockout, a biometry lockout without 0x40 or a state before the first password unlock still asked for a finger the enclave would refuse, and a damaged catacomb looked like a failed match. Treat 0x02, 0x04, 0x10 and 0x40 as a lockout that needs the password, in the verify gate and in the re-arm check; refuse a verify on 0x80 as an enclave failure, not a non-matching finger; and log every state with its bit names. Name the enclave's other notices: tag 0x02 is a user's new enrolled identity count, tag 0x04 says the device list changed. Neither needs an answer; they were logged as unhandled. On macOS a restart does not clear failed attempts: the enclave saves its count after every result and reloads it. The driver forgot its count at every restart (its LOAD_LOCKOUT is not accepted yet), so a restart reset the attempts. Keep the count in the host lockout record, next to the lock, and restore it at start-up. Records from older kernels read as zero failed attempts. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
…acombs At every start the driver hands the enclave its saved lockout record (LOAD_LOCKOUT, 0x71) after the catacombs, and every start the enclave refused it with 0x8002, so the enclave forgot its failed attempts. The enclave checks the record against the restored catacombs, and the record on disk was always older than them: the driver saves it right after a match result, then a template update saves the user and master catacombs, a newer generation. macOS treats 0x8002 from LOAD_LOCKOUT as a refused record, not as an empty one, and loads the record only after all catacombs, as here. Save the lockout record again whenever a catacomb transaction ends (the master is always saved last), so the record on disk matches the catacombs on disk. Say in the log that a 0x8002 is a refusal; the host record keeps the failed-attempt count in that case. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
When the enclave's image assessment (0x07) rejects an image, the driver reported every case as partial contact. The 238-byte assessment says more: macOS 26.6.2 reads a feedback word (bad image, damaged blocks, sensor noise, finger moved), a finger-problem class (wet finger) and a dirt-on-sensor byte, and turns them into its own messages (finger moved, clean the sensor). Decode those fields. A rejected verify or enrol image now reports the matching retry cause (SEP_BIO_GUIDANCE_TOO_FAST for a moved finger, SEP_BIO_GUIDANCE_CLEAN for dirt or a wet finger, LIFT_AND_MOVE for a bad image, CENTER otherwise) and logs the reason. The outcome is unchanged: another touch is asked for. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
On macOS a password typed in a Touch ID prompt verifies the user's key bag in the enclave, and that clears the failed-attempt count: after a missed prompt and a password, the next prompt again has five attempts before Touch ID locks. The driver's re-arm did nothing unless Touch ID was already locked, so misses before a password still counted afterwards, and two more misses in the next prompt could lock Touch ID. When the re-arm comes while Touch ID is not locked, clear the host's failed-attempt count and its record. The full enclave re-arm stays for a real lockout. The re-arm helper calls this after a verified password; it needs to do so when failed attempts are pending as well as when Touch ID is locked. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
A password typed after a missed Touch ID prompt cleared only the host's failed-attempt count. The enclave keeps its own count of completed no-matches and locks Touch ID at five; a password clears that count on macOS, where the key bag verification it triggers resets it. Here the enclave's count stood, so three misses, a password and two more misses locked Touch ID while the host reported two of five. When failed attempts are pending, run the enclave side of a re-arm as well: the key bag verification, a new match credential and the lockout record save, the same steps that end a real lockout. Do not wait for the sensor lock to do it. A verify holds that lock for its whole wait for a touch, and a lock screen takes the password while one waits; the re-arm call, and with it the password authentication, would stall until the capture timed out. Clear the host's count at once and, when the lock is taken, owe the enclave's clear to the start of the next authentication. A match clears both counts and drops what is owed. The re-arm helper must call the re-arm whenever failed attempts are pending, and calling it after every password should cost nothing. Say so in the lockout state's former reserved word: SEP_BIO_LOCKOUT_FLAG_EVERY_ PASSWORD tells it that this driver's re-arm never waits for a capture while Touch ID is not locked. An older driver's re-arm does wait, so the helper keeps to locked-only calls there. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Reuse the merged generic hardware contracts. Add the board identities and native error/event register and interrupt counts without changing the established generation-specific cases. These additions describe hardware resources and do not authorize driver takeover. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Describe J704 and J815 identities and CPU/interrupt/serial resources in a common SoC include. Add disabled DART, PIODMA, error-monitoring, telemetry and secure-transport inventories where the complete merged interface is resolved. Preserve the qualified J813 profile and leave ownership, APIF splits and downstream wiring for separate work. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Add J804 and J833ct identities on a shared hardware-only SoC inventory, with board-specific DART, PIODMA, error/event and secure-proxy resources. Keep all new devices disabled, retain the established J873g profile and avoid inheriting its board policy. Firmware services and diagnostic endpoints are waived; acoustic configuration is supplied separately. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
…urces Keep shared error/event status banks disabled and describe the native three-interrupt secure mailbox interface. The live J873g status-window count differs from the official board templates, so retain each board native list instead of copying one across boards. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Describe the J813 event status windows without granting ownership of their shared apertures. Keep the common H18 mailbox and native error-window contract extensions identical across the family series. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Place the new T8152 entries after the established board entry so that the T8142 and T8152 description series merge together without competing insertions. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
On the J616s the dock port's USB3 PHY failed to come back after suspend-to-idle with liquid detection enabled (2 of 2 cycles; never without it). Every system sleep published "unknown" and every LDCM event did too, so a cable revalidation that ran before the detector was read again saw no plug and tore the partner down. The suspend prepare and resume also sent an LDCM command each time, even when nothing had changed. Keep the last result until the controller reports a new one: - read the detector synchronously in the interrupt and in .complete, before the cable state is applied, instead of publishing "unknown" and reading it later - treat a measurement in progress as "no new result" when an earlier result exists: no mitigation change, no publish, no wake from sleep - send the LDCM command only for a mitigation change, or when the controller state is unknown after a reset or a failed command - invalidate the state only when the controller was actually reset (its power state or event mask had to be restored) - revalidate the cable from the retry worker only when the published state changed Failed reads still publish "unknown" with mitigation enabled, and a liquid result is still reported only after the mitigation ACK. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Picks up the current release branch so the test kernel and CI run against today's base. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Power method 2 with a host-driven AFE reset releases the line for a power-on and sends HasChanged immediately. The sequence validated on the J716s (MacBook Pro 16-inch, M5 Pro, MTP firmware 6320.86.1; "Touch MT ready" on 3 of 3 boots, with the reset on SMC gp1c, active low) waits 50 ms after the release before HasChanged, as this driver already does for a firmware-managed reset. Do the same for the host-driven line. Log a failure to drive the line as an error. Each assert and release is logged at debug level only, so dynamic debug can trace the line without adding a message to the boot log on every power transition. Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com> Assisted-by: LLM Claude
drm/apple: m4: adopt the J604 internal panel (preferred 120 Hz mode)
…ualified firmware The internal display DARTs at 0x30a300000 (disp0) and 0x30a340000 (DCP firmware) carry the running DCP's mappings. On the M4 firmware path the probe leaves them untouched until userspace opts in. On any other firmware it takes them as ordinary DARTs and resets them unless iBoot locked them, which cuts the DCP off from its own firmware. No tree reaches that today: the Airs are on the firmware path with any firmware, and the other M4 trees keep both DARTs disabled. The J604 tree is about to enable dcp_dart as the Airs do, and a J604 can boot an OS firmware other than 26.6.2, where nothing hands its display over. Refuse both DARTs on every M4 Mac off the qualified firmware, as their disabled nodes did. The Airs, and every M4 Mac on 26.6.2, are unchanged. Signed-off-by: Diljit Singh <hey@djdev.me>
dcp_m4_boot_framebuffer_check() accepts a boot framebuffer of the full panel height or 64 rows less, the Airs' notch. A boot loader hiding the notch cuts the framebuffer to 16:10, which on the J604's 3024x1964 panel is 3024x1890, 74 rows less. The J604 profile therefore refused its own boot framebuffer unless the loader kept the notch rows. Give each profile its notch rows (64 on the J713 and J715, 74 on the J604) and check against them. The Airs are unchanged. Signed-off-by: Diljit Singh <hey@djdev.me>
The J713/J715 file enables the internal DCP, its mailbox and firmware DART, names the PIODMA node with the disp0_piodma alias, and asks the boot loader to validate the inherited PIODMA and scanout streams (apple,j713-native-piodma and apple,j713-native-scanout). The loader then enables disp0_dart, piodma and the display subsystem. None of this is the Airs' own. The J604's 26.6.2 ADT has disp0, dcp, dart-dcp and dart-disp0 at the J713's addresses, with the same interrupts, power gates, stream IDs and remap tables, and the boot loader hands the DCP over on every M4 Mac with an internal panel on 26.6.2. Move it to t8132-laptop.dtsi, so the J604 gets it too. Each board still gives its panel's size: the J604's 3024x1964 panel at the ADT's 254.6 ppi is 302 x 196 mm. On 26.6.2 the M4 PMGR policy gives ps_disp_cpu to the firmware, so the DCP and its mailbox can probe. On other firmware that domain stays disabled and they do not, and the DART driver leaves dcp_dart alone. The J713, J715, J623, J624 and J773g dtbs are byte-identical. The J604 dtb gains the alias, status "okay" on dcp, dcp_mbox and dcp_dart, the two request properties and the panel size. Signed-off-by: Diljit Singh <hey@djdev.me>
arm64: dts: apple: t8132-j604: enable the internal DCP
Signed-off-by: Ryan <81541646+RyanTheTide@users.noreply.github.com>
arm() writes the one-boot allowance, fsyncs it, and then relabels it
with restorecon, ignoring its exit status (check=False). On a
distribution without SELinux, such as Arch Linux ARM (the Arch package
ships this tool), there is no restorecon, so subprocess.run() raises
FileNotFoundError and the tool dies with a traceback after the
allowance is already in place. The reboot then works, but the user is
told the tool failed and never sees "Reboot to finish."
Relabel only when restorecon exists. The Fedora spec also guards its
own restorecon calls, with selinuxenabled.
tests/test_policy_change.py arms an allowance with no restorecon on
PATH. It fails before this change and passes after it.
Tested on a J616s (T6040, Arch Linux ARM). The allowance the old tool
armed before its crash was used on the next boot ("allowed one rewrite
of kind-4 record ..."), and Touch ID came back.
Fixes: ff7f73d ("tools/aurora-sep: keep Touch ID across a boot policy change, and never hold the boot for it")
Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com>
Assisted-by: LLM
The lift-gated re-arm, the retry limits, the lock states and the password re-arm read nothing from the platform profile, and the lift detector was only tested with statuses from the J700's 0x3356 sensor. The M1, M1 Pro/Max, M2, M2 Pro/Max and M3 Macs carry the 0x3352 part. Add two KUnit cases: - apple_sep_sensor_status: for every Mesa revision the driver knows, idle, armed, finger-on, frame-ready and needs-patch statuses decode to the same finger-on/finger-off verdict, and the idle status reads the revision back. - apple_sep_profile: every Mac with a built-in sensor (J313, J316s, J316c, J414s, J414c, J413, J415, J613, J615, J614s, J616s, J616c, J713, J700) selects a profile whose sensor is one of those revisions, so the shared path decodes it. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
…word-clears-count
tools/aurora-sep: policy-change: don't crash where restorecon is missing
usb: typec: report and mitigate SN201202x liquid detection
The SEP source checks build the driver with APPLE_SEP_KUNIT_TEST but never run the tests, so a failing suite does not show up on a pull request. apple_sep_host_store has been failing on integration/aurora since the 7.3 merge, and every Touch ID series since has reported the same four failures as "pre-existing". Add the kunitconfig the lanes already use for the apple_sep suites and a job that runs them on arm64 QEMU with the layout-corrected bindgen. Assisted-by: LLM Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com>
A creation of the host-state store that is interrupted before its superblock is written leaves an empty or all-zero file shorter than the store. Commit c73c18c ("soc: apple: sep: Initialise an empty host-state store file again") made from_file() initialise such a file again, since it holds no state, and refuse only files with other contents. That relies on a short file reaching the Damage::Size path, where describe() tells blank files from damaged ones. The 7.3 merge into aurora-wip brought back the early size guard from the older refuse-everything version, and commit 1c10889 ("merge: adapt the retained store guard and DWC3 fixture to 7.3") kept it. The guard refuses every file shorter than the store before describe() runs, so a blank short file is refused again: Touch ID stays off on every boot until someone deletes /var/lib/aurora-sep-host-state.bin by hand. This is what the four failing apple_sep_host_store tests check. Drop the guard. A short file is still read only through describe(), and one with any non-zero byte is still refused without being written to, as the tests for truncated stores and non-blank short files check. Fixes: 1c10889 ("merge: adapt the retained store guard and DWC3 fixture to 7.3") Assisted-by: LLM Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com>
Every start on the M2 (fleet30 + this series) logged a new boot warning: "LOAD_LOCKOUT refused the saved lockout record (0x8002 ...)". The enclave refuses a record older than the restored catacombs, and the host record already carries the failed-attempt count in that case, so nothing is lost and nothing needs the user's attention. Before this series the same answer was taken without a warning. Log it once at info level, next to the restore outcome, so the boot log stays free of warnings. Why the enclave refuses the record at start is tracked separately. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
…-files soc: apple: sep: Initialise blank host-state store files again, and run the SEP KUnit suites in CI
soc: apple: sep: arm the next Touch ID capture when the finger lifts
…licy soc: apple: sep: Touch ID retry limits, lock states and enrolment operation as on macOS
…-clears-count soc: apple: sep: let a password clear Touch ID's failed attempts
soc: apple: rtkit: wait up to 10 s for a handshake reply
HID: dockchannel-hid: settle 50 ms after releasing the AFE reset
…l-fan-keys hwmon: (macsmc) keep a fan whose optional keys are missing
nvme: apple: find the linear SQ doorbells from the nvme window
Contributor
Author
|
Gate on the buildbox, merge 55cde2c, fleet config:
GitHub CI is green too (source, rust-build, kunit, host-tests, dt-checks). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings aurora-wip up to integration/aurora 11943fb with a merge commit (55cde2c), no force push. The merge is clean: aurora-wip keeps its 33 own commits, and 112 integration commits come in. Those include:
Gate (buildbox)
Results are posted below before merge.
🤖 Generated with Claude Code