Take the HAL/DSMI command selectors and signatures from the driver headers (a5 probe + a2a3 host_regs)

[ChaoZheng109]

Summary

src/a5/platform/onboard/host/aicpu_topology_probe.cpp describes its driver calls entirely by hand — four command selectors written as literals, plus a hand-written halGetDeviceInfoByBuff function-pointer typedef. #2230 did the equivalent cleanup for a2a3; a5 was deliberately left out of that PR to keep it reviewable.

What can be taken from the headers

Two of the four selectors have real symbols today (CANN 9.0.0):

constant	line	driver symbol	can be derived?
kModuleSystem = 0	:39	MODULE_TYPE_SYSTEM (ascend_hal_base.h)	yes
kDsmiSocInfoMainCmd = 14	:48	DSMI_MAIN_CMD_SOC_INFO (dsmi_common_interface.h)	yes
kInfoCpuTopo = 59	:40	none	no
kDsmiSocInfoSubCmdCpuTopo = 2	:49	none	no

For the two that cannot: grep -rn CPU_TOPO over $ASCEND_HOME_PATH/<arch>-linux/include/driver/ and .../pkg_inc/driver/ returns nothing — ascend_hal_base.h declares no INFO_TYPE_CPU_TOPO, and DSMI_SOC_INFO_SUB_CMD ends at DSMI_SOC_INFO_SUB_CMD_MAX = 2. tools/cann-examples/query/query.cpp carries the same two literals and guards one with #ifndef. These stay as literals until the driver names them; they should say so at the point of use.

Also: the hand-written signature

// src/a5/platform/onboard/host/aicpu_topology_probe.cpp:80
using HalGetDeviceInfoByBuffFn =
    int (*)(uint64_t deviceId, int32_t moduleType, int32_t infoType, void *buf, int32_t *size);

The driver declares drvError_t halGetDeviceInfoByBuff(uint32_t devId, ...) (ascend_hal_base.h:1302) — first parameter is uint32_t, return type is drvError_t. Calling through an incompatible function pointer type is undefined behaviour; it survives on AArch64 only because the callee reads w0. #2230 fixed the a2a3 equivalent with decltype(&halGetDeviceInfo), which adds no link dependency because the operand is unevaluated.

src/a2a3/platform/onboard/host/host_regs.cpp:56 has the same hand-written halGetDeviceInfoByBuff typedef and is also untouched by #2230.

Constraint to respect

tests/ut/cpp compiles a5/.../aicpu_topology_probe.cpp straight into test_a5_aicpu_topology_fallback, which builds on GitHub-hosted runners with no CANN. So the file cannot simply include a driver header. #2230 handled this for a2a3 by splitting the arithmetic half into its own CANN-free translation unit; a5's split line is different and larger — the driver calls are confined to query_cpu_topo and the two dlsym loaders, while the unit test needs ~15 symbols spanning selection, classification and JSON parsing.

Scope note

Deriving a selector from the toolkit header pins it against the header, not against the driver .so that dlsym actually resolves at run time. The toolkit and driver packages are versioned independently, so this closes "a transcribed value goes stale relative to the header" and does not close "the header disagrees with the installed driver."

[ChaoZheng109]

2026-09-15: retitled. The old title was prefixed a5:, but the body also tracks src/a2a3/platform/onboard/host/host_regs.cpp:56, which carries the same hand-written halGetDeviceInfoByBuff typedef (int (*)(uint64_t, ...) against the driver's drvError_t (*)(uint32_t, ...)). That file already includes ascend_hal.h, so decltype(&halGetDeviceInfoByBuff) is a one-line change there — anyone triaging by the a5 prefix would have skipped it. Scope is unchanged; only the title was wrong.