Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Dependency inversion unconditionally loads USB Type-C subsystem on all DP-capable systems --
commit 18e75df5599eb3c3479dc1002547dcf5f6a1593b Author: Chaoyi Chen <[email protected]> drm/display: Add soft depend for aux-hpd-typec-dp-bridge module This commit adds a soft dependency in the drm_display_helper module for the aux-hpd-typec-dp-bridge module. This ensures the bridge module is loaded early, as it serves as a generic Type-C DisplayPort HPD bridge that isn't directly required by any other module. > diff --git a/drivers/gpu/drm/display/drm_display_helper_mod.c > b/drivers/gpu/drm/display/drm_display_helper_mod.c > index d8a6e62287736..f0152d6b0b2d7 100644 > --- a/drivers/gpu/drm/display/drm_display_helper_mod.c > +++ b/drivers/gpu/drm/display/drm_display_helper_mod.c > @@ -18,5 +18,6 @@ static void __exit drm_display_helper_module_exit(void) > drm_dp_aux_dev_exit(); > } > > +MODULE_SOFTDEP("pre: aux-hpd-typec-dp-bridge"); [Severity: Medium] Does adding a soft dependency on aux-hpd-typec-dp-bridge to the core drm_display_helper module create an architectural dependency inversion? The leaf bridge driver (aux-hpd-typec-dp-bridge) has a hard dependency on the typec core subsystem because it registers a bus notifier on typec_bus. As a result, when a system loads a DRM driver that utilizes generic display helpers (such as amdgpu, i915, or nouveau), won't this unconditionally pull the entire USB Type-C subsystem into memory? This seems like it might waste memory resources on systems without Type-C hardware by automatically loading aux-hpd-typec-dp-bridge.ko (and consequently typec.ko) upon loading any standard DRM driver. Is there a better way to handle this without burdening all generic display helper users? > module_init(drm_display_helper_module_init); > module_exit(drm_display_helper_module_exit); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
