Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues: - [High] Missing drm_panel_remove() on the mipi_dsi_attach() error path in probe causes a Use-After-Free. - [High] Panel reset is erroneously asserted before sending DSI sleep commands in the unprepare sequence. -- commit 591497f012912dfaa02eb5ec6c5c1e0d8e61f126 Author: Paul Sajna <[email protected]> Revert "dt-bindings: display: panel: panel-simple: Add lg,sw49410 compatible" This reverts commit a74c2e55ab66519ffa2069ac9ae83cd937bff4c4. The panel isn't actually panel-simple-compatible. > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 3e41ed0ef5d51..1abdc8698a865 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -200,8 +200,6 @@ properties: > - lemaker,bl035-rgb-002 > # LG 7" (800x480 pixels) TFT LCD panel > - lg,lb070wv8 > - # LG 6.1" (1440x3120) IPS LCD panel > - - lg,sw49410 [Severity: High] This isn't a bug introduced by this patch, but while looking at the sw49410 panel driver code, I noticed a missing drm_panel_remove() on the mipi_dsi_attach() error path in probe which causes a use-after-free: drivers/gpu/drm/panel/panel-lg-sw49410.c:sw49410_panel_probe() { drm_panel_add(&ctx->panel); /* This panel only supports DSC; unconditionally enable it */ dsi->dsc = &ctx->dsc; ... return mipi_dsi_attach(dsi); } If mipi_dsi_attach() fails, the function returns an error without calling drm_panel_remove(). Because ctx was allocated with devm_drm_panel_alloc(), the kernel devres mechanism will free ctx upon probe failure. This leaves a dangling pointer in the global panel_list. Any subsequent operations iterating over panel_list (such as another driver calling drm_panel_get()) will dereference the freed memory, causing a use-after-free kernel panic. Could we add a call to drm_panel_remove() to the error path here? [Severity: High] This is a pre-existing issue, but the panel reset is erroneously asserted before sending DSI sleep commands in the unprepare sequence: drivers/gpu/drm/panel/panel-lg-sw49410.c:sw49410_panel_unprepare() { gpiod_set_value(ctx->reset_gpio, 1); struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi }; mipi_dsi_dcs_set_display_off_multi(&dsi_ctx); mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx); } The reset GPIO is asserted (gpiod_set_value(ctx->reset_gpio, 1)) before executing the MIPI DCS sleep commands. Attempting to send MIPI DCS commands to a panel that is held in hardware reset will cause the DSI host to fail to communicate, resulting in severe command timeouts and error logs. The unprepare sequence is functionally broken because the panel cannot gracefully enter sleep mode. Should the panel reset be delayed until after the DSI sleep commands are sent? > # Logic Technologies LT161010-2NHC 7" WVGA TFT Cap Touch Module > - logictechno,lt161010-2nhc -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
