Re: [PATCH 09/10] drm/bridge: ti-sn65dsi83: Remove redundant dev_err_probe()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The background work `ctx->reset_work` is never explicitly canceled, which can lead to a Use-After-Free if it executes after `ctx` is freed.
--

--- Patch [9]: [PATCH 09/10] drm/bridge: ti-sn65dsi83: Remove redundant dev_err_probe() ---
commit ae3029f9f75aff0082e24f794cc2c0d8fb473908
Author: Pan Chuang <panchuang@vivo.com>

drm/bridge: ti-sn65dsi83: Remove redundant dev_err_probe()

Since commit 55b48e23f5c4, devm_request_threaded_irq() automatically logs
detailed error messages on failure. This patch removes the now-redundant
driver-specific dev_err_probe() call.

> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -1040,7 +1040,7 @@ static int sn65dsi83_probe(struct i2c_client *client)
>  		ret = devm_request_threaded_irq(ctx->dev, ctx->irq, NULL, sn65dsi83_irq,
>  						IRQF_ONESHOT, dev_name(ctx->dev), ctx);
>  		if (ret)
> -			return dev_err_probe(dev, ret, "failed to request irq\n");
> +			return ret;
>  	}
>  
>  	dev_set_drvdata(dev, ctx);

[Severity: High]
This is a pre-existing issue, but looking at the driver initialization and
teardown, is there a risk of a use-after-free with ctx->reset_work?

When the IRQ is successfully requested, the handler sn65dsi83_irq() becomes
active. If a hardware error triggers the IRQ handler, it calls
sn65dsi83_handle_errors() which schedules the reset work:

drivers/gpu/drm/bridge/ti-sn65dsi83.c:sn65dsi83_handle_errors() {
    ...
    schedule_work(&ctx->reset_work);
    ...
}

If the probe fails later (for example, when sn65dsi83_host_attach() fails),
the err_remove_bridge path is taken:

drivers/gpu/drm/bridge/ti-sn65dsi83.c:sn65dsi83_probe() {
err_remove_bridge:
    drm_bridge_remove(&ctx->bridge);
    return ret;
}

Since there is no explicit cancellation of the work here, and devres will
subsequently free the ctx structure upon probe failure, could a scheduled
reset work execute and dereference the freed ctx pointer?

The same pattern appears to exist in the normal driver removal path:

drivers/gpu/drm/bridge/ti-sn65dsi83.c:sn65dsi83_remove() {
    struct sn65dsi83 *ctx = i2c_get_clientdata(client);

    drm_bridge_unplug(&ctx->bridge);
}

Could this also leave a dangling work item that outlives the device context
if the device is unbound via sysfs while the background work is pending?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723131649.134127-1-panchuang@vivo.com?part=9