load_hisilicon (av100): remove_detect rmmods stale module names

[widgetii]

Summary

load_hisilicon on hi3516av100 has stale rmmod targets in remove_detect() whose names don't match what the firmware actually loads. The errors come out during sensor-detect / boot:

rmmod: can't unload module 'sensor_spi': No such file or directory
rmmod: can't unload module 'sensor_i2c': No such file or directory
rmmod: can't unload module 'hi3516a_isp': Resource temporarily unavailable
rmmod: can't unload module 'hi3516a_base': Resource temporarily unavailable
rmmod: can't unload module 'hi_media': No such file or directory
rmmod: can't unload module 'mmz': No such file or directory
rmmod: can't unload module 'sys_config': No such file or directory

No such file or directory here means the module isn't in /sys/module/<name> — not that the .ko file is missing. The firmware ships .kos with these exact filenames (sensor_spi.ko, sensor_i2c.ko, hi_media.ko, mmz.ko, sys_config.ko — verified in /lib/modules/4.9.37/hisilicon/), but their internal KBUILD_MODNAME is renamed (Strategy B objcopy / open_* wrappers per openhisilicon/CLAUDE.md), so /sys/module/sensor_spi doesn't exist. rmmod looks up by internal name and fails.

This was always there; it just got exposed by post-#2059 firmware where load_hisilicon no longer exits at the os_mem= guard before reaching remove_detect().

Where

general/package/hisilicon-osdrv-hi3516av100/files/script/load_hisilicon, the remove_detect() function (~line 80):

remove_detect() {
        rmmod -w sensor_spi
        rmmod -w sensor_i2c
        rmmod -w hi3516a_isp
        rmmod -w hi3516a_sys
        rmmod -w hi3516a_base
        rmmod -w hi_media
        rmmod -w mmz
        rmmod -w sys_config
}

Suggested fix

Audit what insert_detect() actually loads, run the firmware once and cat /proc/modules, and update remove_detect() to use those internal names (likely open_sensor_spi, open_sensor_i2c, open_isp, open_base, open_sys, open_osal etc., similar to what other families' remove_detect already does post-rename).

CI hardcoding to undo once fixed

OpenIPC/openhisilicon/.github/workflows/build.yml qemu-boot matrix has:

- machine: hi3516av100
  firmware: hi3516av100
  mem: 256M
  allow-failure: true                # <-- remove this line
  append: "console=ttyAMA0,115200 mem=32M root=/dev/ram0 rootfstype=squashfs"

After this issue is fixed and a new latest firmware release is published:

1. Drop the allow-failure: true line from the av100 matrix entry.
2. Optionally add min_modules: N to the same row to gate on the lsmod count assertion (pick N from a healthy boot's ===CI:HISI_MOD_COUNT===N=== marker — likely ~25-28 for av100 with all hi3516a_*.ko plus mmz/sensor_*/sys_config loaded).
3. Drop the explanatory comment block above the av100 row.

Removing allow-failure will make the row strict again, and any future regression of remove_detect (or the loaded module names drifting from remove_detect's targets) will fail CI immediately rather than be silently warned about.

Refs

• Discovered while landing ci: add hi3516ev300_neo qemu-boot + lsmod-count regression probe openhisilicon#86 (post-load_hisilicon: empty lsmod on V4+CMA after #2039 (mem= cmdline misread as OS-only memory) #2059 qemu-boot regression coverage).
• Pattern matches CV200: open_* module names break load_hisilicon's remove_detect/insert_ko sequence openhisilicon#62 — module-name drift in remove_detect.