Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Devm-managed IRQ can fire while regulators are disabled during probe error path, causing an interrupt storm. -- --- Patch [3]: [PATCH 03/10] drm/bridge: lt9611: Remove redundant dev_err() --- commit 31b83af0309fdf55db58f4bc292c02026a269afc Author: Pan Chuang <[email protected]> drm/bridge: lt9611: Remove redundant dev_err() This commit removes a redundant dev_err() message on failure to request the devm-managed IRQ, as the core already logs detailed error messages on failure. > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c > b/drivers/gpu/drm/bridge/lontium-lt9611.c > index b6a368f712853..05950cbc0a90f 100644 > --- a/drivers/gpu/drm/bridge/lontium-lt9611.c > +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c [ ... ] > @@ -1156,10 +1156,8 @@ static int lt9611_probe(struct i2c_client *client) > ret = devm_request_threaded_irq(dev, client->irq, NULL, > lt9611_irq_thread_handler, > IRQF_ONESHOT, "lt9611", lt9611); > - if (ret) { > - dev_err(dev, "failed to request irq\n"); > + if (ret) > goto err_disable_regulators; [Severity: High] This isn't a bug introduced by this patch, but I noticed a potential interrupt storm in the error handling path for this IRQ request. If a subsequent initialization step fails (for example, if lt9611_attach_dsi() returns -EPROBE_DEFER), the probe function jumps to err_disable_regulators: err_disable_regulators: regulator_bulk_disable(ARRAY_SIZE(lt9611->supplies), lt9611->supplies); Because the IRQ is managed by devres (devm_request_threaded_irq()), it remains active until the probe function returns and the devres cleanup runs. If the IRQ fires during this window while the regulators are disabled, lt9611_irq_thread_handler() will attempt to communicate with the unpowered device via I2C to read and clear the interrupt flag: lt9611_irq_thread_handler() { ... regmap_read(lt9611->regmap, 0x820f, &irq_flag3); ... } Since the device is unpowered, the read will fail, the interrupt will not be cleared in hardware, and the handler will still return IRQ_HANDLED. Will this cause the interrupt controller to immediately re-trigger the handler, leading to a soft or hard CPU lockup? While lt9611_remove() correctly calls disable_irq() before disabling regulators, is a similar disable_irq() call needed in this probe error path before regulator_bulk_disable()? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
