Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm: missing state initialization fallback after successful SRO readout --
commit 82595be49b2239429ccad442f233b1b0663939a4 Author: Maxime Ripard <[email protected]> drm/mode-config: Read out hardware state in drm_mode_config_create_state This commit updates drm_mode_config_create_initial_state() to populate initial state from hardware using the atomic_sro_readout_state hook when available, falling back to creating a pristine state otherwise. > diff --git a/drivers/gpu/drm/drm_mode_config.c > b/drivers/gpu/drm/drm_mode_config.c > index 48a56f23dadbb..80d3fc511db5a 100644 > --- a/drivers/gpu/drm/drm_mode_config.c > +++ b/drivers/gpu/drm/drm_mode_config.c [ ... ] > +int drm_mode_config_create_initial_state(struct drm_device *dev) > +{ > + int ret; > + > + if (dev->mode_config.funcs->atomic_sro_readout_state) { > + ret = dev->mode_config.funcs->atomic_sro_readout_state(dev); > + if (!ret) > + return 0; [Severity: High] Does this early return bypass fallback state creation for objects not handled by the SRO readout? If atomic_sro_readout_state() succeeds and returns 0, the function returns immediately and skips the subsequent call to drm_mode_config_create_state(). Any registered KMS objects that aren't populated by the driver's SRO readout hook (such as drm_colorop objects or dormant planes) will be left with a NULL state pointer. Because the DRM atomic framework strictly requires a non-NULL state for all registered objects, won't this lead to a NULL pointer dereference when operations like drm_atomic_helper_colorop_duplicate_state() are called during the first atomic commit? > + } > + > + return drm_mode_config_create_state(dev); > +} > EXPORT_SYMBOL(drm_mode_config_create_initial_state); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=12
