Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Missing Cleanup on Error Path -- commit 1dbc8ff3ee3e816eec72de6095402106b128c956 Author: Maxime Ripard <[email protected]> drm/bridge: ti-tfp410: Switch to atomic_create_state This commit switches from the deprecated atomic_reset callback to the atomic_create_state callback. > diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c > b/drivers/gpu/drm/bridge/ti-tfp410.c > index bf4ab4eaf2697..6f06f7b4e9926 100644 > --- a/drivers/gpu/drm/bridge/ti-tfp410.c > +++ b/drivers/gpu/drm/bridge/ti-tfp410.c > @@ -245,7 +245,7 @@ static const struct drm_bridge_funcs tfp410_bridge_funcs > = { > .enable = tfp410_enable, > .disable = tfp410_disable, > .mode_valid = tfp410_mode_valid, > - .atomic_reset = drm_atomic_helper_bridge_reset, > + .atomic_create_state = drm_atomic_helper_bridge_create_state, > .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state, > .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state, > .atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts, [Severity: High] This is a pre-existing issue, but when drm_connector_init_with_ddc() fails in tfp410_attach(), it returns without cancelling dvi->hpd_work or calling drm_bridge_hpd_disable() on dvi->bridge.next_bridge: drivers/gpu/drm/bridge/ti-tfp410.c:tfp410_attach() { if (dvi->bridge.next_bridge->ops & DRM_BRIDGE_OP_HPD) { INIT_DELAYED_WORK(&dvi->hpd_work, tfp410_hpd_work_func); drm_bridge_hpd_enable(dvi->bridge.next_bridge, tfp410_hpd_callback, dvi); } drm_connector_helper_add(&dvi->connector, &tfp410_con_helper_funcs); ret = drm_connector_init_with_ddc(bridge->dev, &dvi->connector, &tfp410_con_funcs, dvi->bridge.next_bridge->type, dvi->bridge.next_bridge->ddc); if (ret) { dev_err(dvi->dev, "drm_connector_init_with_ddc() failed: %d\n", ret); return ret; } ... } Because the DRM core does not call .detach() on a failed .attach(), the HPD callback remains registered on the downstream bridge and the delayed work is never cancelled. If the device is subsequently unbound, dvi will be freed by devm. A subsequent HPD event from the downstream bridge would execute tfp410_hpd_callback() with the freed dvi pointer. Could this lead to a use-after-free on dvi? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=46
