Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] drm/bridge: typo in drm_private_obj_is_bridge NULL guard --
commit 4aa8371c67584717cdc9bfc67e2f423ff8e526fe Author: Maxime Ripard <[email protected]> drm/bridge: Add drm_private_obj_is_bridge() This commit introduces drm_private_obj_is_bridge() to identify if a private object is backed by a bridge. This is necessary because bridges require special readout ordering during encoder chain handling. > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > index 447fe6d333b3b..9d5529765f5fb 100644 > --- a/drivers/gpu/drm/drm_bridge.c > +++ b/drivers/gpu/drm/drm_bridge.c > @@ -582,6 +582,21 @@ static const struct drm_private_state_funcs > drm_bridge_priv_state_funcs = { [ ... ] > +/** > + * drm_private_obj_is_bridge - check if a private object backs a bridge > + * @obj: private object to check > + * > + * RETURNS: > + * > + * True if @obj is the &drm_private_obj embedded in a &struct drm_bridge, > + * false otherwise. > + */ > +bool drm_private_obj_is_bridge(struct drm_private_obj *obj) > +{ > + return obj->funcs && obj->funcs == &drm_bridge_priv_state_funcs; [Severity: Low] Is there a typo in the null guard here? If the intent is to protect against a null obj pointer, checking obj->funcs first will cause a null pointer dereference. If obj is instead guaranteed to be non-null, the left side of the && is redundant dead code, because comparing a potentially null obj->funcs pointer to a valid static address safely evaluates to false. Should this instead be return obj && obj->funcs == ... or just the right side if obj is guaranteed to be non-null? > +} > +EXPORT_SYMBOL(drm_private_obj_is_bridge); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
