[audreyt]

A refusal by the xART guard sets diag/xart_guard_refusals and turns diag/matching to blocked. The KUnit suites build guards over in-memory files and make them refuse on purpose, so on a kernel built with the tests the module's diagnostics read blocked although the live guard had refused nothing. A readiness check that trusts diag/matching would then stop a working Mac. Reported by @MuBai-He on #200 (J713: 13 refusals and blocked after the suites, Touch ID ready and matching working).

Change. Guard gets a report flag. Guard::open(), the guard the driver uses, sets it; Guard::with_file(), which the suites use, leaves it off. Both refusal sites go through one report_refusal(). The live guard behaves as before. diag::refusals() is added for the suites only (CONFIG_APPLE_SEP_KUNIT_TEST).

Test. A new case, a_guard_over_a_test_file_does_not_report_to_the_diagnostics, makes a guard over an in-memory file refuse twice and checks the diagnostics' counter did not move.

Checked (arm64 defconfig plus Rust, APPLE_SEP=y and APPLE_SEP_KUNIT_TEST=y built in, booted under QEMU/KVM on an arm64 host):

• With the fix (f1366ff2a): apple_sep_xart_guard 29 of 29 pass, no not ok anywhere.
• Test without the fix (4e0c8c7b4, a throwaway branch): the new case fails (ASSERTION FAILED at drivers/soc/apple/xart_guard.rs:664), apple_sep_xart_guard 28 pass and 1 fail; the other suites are the same.

Not checked. No hardware run: KUnit cannot exercise Guard::open(), so nothing here proves the live guard still reports. That path is two lines (open() sets the flag, check() calls report_refusal()). The J713 sysfs counters on a kernel built with the tests were not re-read after the change.

[audreyt]

Ready for review at f1366ff. This is the standalone fix for the KUnit diagnostic side effect reported in #200, not a J715 enablement change.

The arm64 QEMU/KVM regression check fails without the fix (28 pass, 1 fail in apple_sep_xart_guard) and passes with it (29 pass, 0 fail); the other SEP suites pass in both runs. Hardware reporting through Guard::open() has not been re-tested, as stated in the description.

@scottjones, could you review this independently of #200's remaining fresh-install qualification? It prevents test-induced diag/matching=blocked on kernels built with the SEP suites.

[scottjones]

We checked this against current integration/aurora, and it does what it says.

The driver builds its guard in one place, xart_store.rs:433, through Guard::open(), which now sets report. Both refusal sites in check() go through report_refusal(), so a real refusal still reaches diag/xart_guard_refusals and diag/matching. Outside open(), only the KUnit suites use with_file(). Release kernels are built without CONFIG_KUNIT, so nothing changes for them; the fix matters for kernels built with the tests, like the J713 one in #200.

The new case fails without the change by construction: a with_file() guard that refuses bumps the same counter the test reads. That matches your 28/1 run.

One heads-up: #262 conflicts with this in xart_guard.rs. It keeps the direct diag::xart_guard_refused() calls in check() and adds a third in refuse_unsaved(). Whichever of the two lands second should route all three through report_refusal(); #262's own refusal tests would otherwise leave counts in diag again.