Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] amdxdna: aie4_hwctx_config unconditionally returns success for unsupported types --
commit 2fb62e44c1bbca14b0a25248c16851b8cb0c7aa6 Author: David Zhang <[email protected]> accel/amdxdna: Add stub hwctx_config for AIE4 XRT issues DRM_AMDXDNA_CONFIG_HWCTX during hardware context initialization. If hwctx_config is NULL, the ioctl returns -EOPNOTSUPP, causing userspace validation tests like GEMM to fail. Add a stub aie4_hwctx_config() returning 0 and wire it to aie4_vf_ops and aie4_classic_ops. > diff --git a/drivers/accel/amdxdna/aie4_pci.c > b/drivers/accel/amdxdna/aie4_pci.c > index 007b14be5245f..62ee7dfc7bd37 100644 > --- a/drivers/accel/amdxdna/aie4_pci.c > +++ b/drivers/accel/amdxdna/aie4_pci.c > @@ -1369,12 +1369,19 @@ const struct amdxdna_dev_ops aie4_pf_ops = { > .runtime_suspend = aie4_pf_runtime_suspend, > }; > > +static int aie4_hwctx_config(struct amdxdna_hwctx *hwctx, u32 type, u64 > value, > + void *buf, u32 size) > +{ > + return 0; > +} [Severity: Medium] Does returning 0 unconditionally here falsely report success for unsupported hardware context configuration commands? If a userspace library like XRT calls the AMDXDNA_CONFIG_HWCTX ioctl with an unsupported type (such as DRM_AMDXDNA_HWCTX_ASSIGN_DBG_BUF), returning 0 could cause userspace to assume the operation was successful. Could this cause userspace to read uninitialized or garbage data from the buffer since it relies on standard kernel error codes like -EOPNOTSUPP or -EINVAL to detect hardware capabilities? > + > const struct amdxdna_dev_ops aie4_vf_ops = { > .init = aie4_vf_init, > .fini = aie4_vf_fini, > .debugfs_init = aie4_debugfs_init, > .hwctx_init = aie4_hwctx_init, > .hwctx_fini = aie4_hwctx_fini, > + .hwctx_config = aie4_hwctx_config, > .cmd_submit = aie4_cmd_submit, > .cmd_wait = aie4_cmd_wait, > .get_aie_info = aie4_get_info, -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=19
