Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] accel/qda: !DRM_ACCEL_QDA in Kconfig allows building both drivers as modules --
commit 546c9c847d7dbca90dfe6d1ba0861765d71753de Author: Ekansh Gupta <[email protected]> accel/qda: Add initial QDA DRM accelerator driver This commit adds the initial DRM compute accelerator skeleton driver for Qualcomm Hexagon DSPs (qda), binding to the same RPMsg device tree compatibles as the legacy fastrpc driver. It also adds a Kconfig dependency on QCOM_FASTRPC intended to make the two drivers mutually exclusive. > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index c40e89cc57243..14b7bbaadcaa0 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -269,6 +269,7 @@ config QCOM_FASTRPC > tristate "Qualcomm FastRPC" > depends on ARCH_QCOM || COMPILE_TEST > depends on RPMSG > + depends on !DRM_ACCEL_QDA [Severity: Medium] As reported by Sashiko on v1 [1], since DRM_ACCEL_QDA in drivers/accel/qda/Kconfig and QCOM_FASTRPC in drivers/misc/Kconfig are both tristate symbols, does "depends on !DRM_ACCEL_QDA" still allow both drivers to be built together as modules? In Kconfig tristate logic (EXPR_NOT in scripts/kconfig/expr.h), when DRM_ACCEL_QDA=m, !DRM_ACCEL_QDA evaluates to m rather than n. That only prevents QCOM_FASTRPC=y when DRM_ACCEL_QDA=m, while still allowing QCOM_FASTRPC=m and DRM_ACCEL_QDA=m at the same time. Both modules then export the same OF device table entries in qda_rpmsg_of_match and race to bind to the same RPMsg devices. Should this dependency instead be written as: depends on DRM_ACCEL_QDA=n so that QCOM_FASTRPC is disabled whenever DRM_ACCEL_QDA is enabled as either built-in or a module? [1] https://lore.kernel.org/r/[email protected] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
