aop_als: ambient light sensor appears to keep reporting during s2idle, and modprobe -r aop_als oopses in aop recv_message

[omeganter]

Hi, and thank you for all the work on Asahi. I'm writing up two things I ran into with the AOP sensor drivers while measuring s2idle battery drain on my machine. I'm only reporting what I observed; I may well be misreading parts of it.

Hardware / kernel: MacBookPro18,3 (M1 Pro, j314s), linux-asahi 7.1.13.asahi3 (Arch Linux ARM), m1n1 1.6.1, OS firmware 13.5.

1. The ambient light sensor seems to keep reporting during s2idle

I snapshotted /proc/interrupts when logind sent PrepareForSleep true and false, around a 16 h 51 min lid-closed s2idle. The largest counts across the sleep:

    218827  293408000.mbox-recv      (AOP)
    214083  IPI1 Function call interrupts
    135501  arch_timer
       320  290408000.mbox-recv
       304  nvme-apple
       144  38bc08000.mbox-recv

That's about 3.6 AOP messages per second for the whole sleep.

Awake, the AOP mailbox ran at 5.95/s with aop_als loaded. With aop_als blacklisted at boot it ran at about 1.1/s. Nothing in userspace reads the sensor on this system (no iio-sensor-proxy).

From reading the source, it looks like enable_als() sets ALS property 0 to 200000 (a 200 ms interval?) at probe. I couldn't find suspend/resume callbacks in aop_als, aop_las or aop, but I may have missed something.

For context, and so this isn't overstated: blacklisting aop_als didn't noticeably change the overall s2idle drain on this machine (it stayed around 2 W, numbers in #262).

2. modprobe -r aop_als led to an oops

While testing the above, I unloaded aop_als with modprobe -r. Within seconds the kernel oopsed in aop's recv_message:

Unable to handle kernel paging request at virtual address ffff80007aaf4348
FSC = 0x07: level 3 translation fault
Internal error: Oops: 0000000096000007 [#1]  SMP
Modules linked in: ... snd_soc_aop aop_las ... aop ... [last unloaded: aop_als]
CPU: 1 UID: 0 PID: 801785 Comm: kworker/u36:1 Tainted: G S  7.1.13-3-1-ARCH #1 PREEMPT(full)
Hardware name: Apple Inc. MacBookPro18,3/J314s, BIOS 2026.07 07/01/2026
Workqueue: rtkit-293c00000.aop apple_rtkit_rx_work
pc : _RNvXso_CsdB43V58tik5_3aopNtB5_7AopDataNtNtNtNtCsgQONdTYyCoH_6kernel3soc5apple5rtkit10Operations12recv_message+0x7f8/0x10cc [aop]
Call trace:
 _RNvXso_CsdB43V58tik5_3aopNtB5_7AopDataNtNtNtNtCsgQONdTYyCoH_6kernel3soc5apple5rtkit10Operations12recv_message+0x7f8/0x10cc [aop] (P)
 apple_rtkit_rx_work+0x114/0xa20
 process_one_work+0x160/0x4e0
 worker_thread+0x184/0x2e0
 kthread+0x118/0x134
 ret_from_fork+0x10/0x20

Afterwards the AOP mailbox went almost silent (0.05/s), and modprobe aop_als didn't bind again until I rebooted. My guess is that the listener registered through add_fakehid_listener() outlives the module, but that's only a guess from reading the code.

Steps: with aop_als loaded, run modprobe -r aop_als and wait a few seconds.

I'm happy to collect more data or test anything that would help. Thanks again for your time.