Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Missing completion reinitialization in AUX transfer exposes driver to spurious immediate returns -- commit a0eb2a01158c71ba22ad17e3ef567be4fe4e603f Author: Maxime Ripard <[email protected]> drm/bridge: dw-dp: Switch to atomic_create_state The commit replaces the deprecated atomic_reset callback and its helper with atomic_create_state and its corresponding helper in the Synopsys DW DP driver. > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c > b/drivers/gpu/drm/bridge/synopsys/dw-dp.c > index 21541be094c47..98437dc33d4db 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c [ ... ] This isn't a bug introduced by this patch, but I noticed a pre-existing issue while reviewing this file: drivers/gpu/drm/bridge/synopsys/dw-dp.c:dw_dp_aux_transfer() { ... if (msg->size > 0) value = FIELD_PREP(AUX_LEN_REQ, msg->size - 1); else value = FIELD_PREP(I2C_ADDR_ONLY, 1); value |= FIELD_PREP(AUX_CMD_TYPE, msg->request); value |= FIELD_PREP(AUX_ADDR, msg->address); regmap_write(dp->regmap, DW_DP_AUX_CMD, value); status = wait_for_completion_timeout(&dp->complete, timeout); ... } [Severity: High] Does this code need a call to reinit_completion() on dp->complete before triggering the hardware transfer with regmap_write()? If a previous transfer times out (leaving the completion count at 0) and the interrupt handler fires later, complete() will increment the completion counter to 1. The very next call to dw_dp_aux_transfer() would consume this leftover completion and immediately return success without actually waiting for the new transaction to finish. Could this cause the driver to read an incomplete hardware status or stale data, leading to unpredictable AUX failures and display initialization errors? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=33
