Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues: - [High] Setting `prepare_prev_first` reverses the bridge enable/disable order, causing the DSI host to drive data lanes high (LP-11) before the panel is powered on, which violates hardware power sequences. Pre-existing issues: - [High] The panel is published to the system via `drm_panel_add()` before critical internal state is initialized. -- commit a792999b217c12abcec671639b930a3ece58774e Author: Dmitry Baryshkov <[email protected]> drm/panel: jadard-jd9365da-h3: set prepare_prev_first Sending DSI commands from the prepare() callback requires DSI link to be up at that point. Set the .prepare_prev_first flag to let these panels work with the DSI hosts which don't power on the link in their .mode_set callback. Link: https://patch.msgid.link/[email protected] > diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c > b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c > index 5c2530598ddb9..9e5287829b952 100644 > --- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c > +++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c > @@ -1157,6 +1157,8 @@ static int jadard_dsi_probe(struct mipi_dsi_device *dsi) > if (ret) > return ret; > > + jadard->panel.prepare_prev_first = true; > + [Severity: High] Does setting this flag reverse the expected hardware power sequences? When the display is enabled, the DRM bridge core will respect this flag by calling the host's pre_enable before the panel's prepare. This forces the host PHY to power up and drive the DSI lanes to LP-11. Then jadard_prepare() enables the vccio and vdd regulators. This sequence is reversed during disable, with jadard_unprepare() disabling regulators while the host is still driving LP-11. Could driving I/O pins on unpowered silicon cause hardware latch-up and potential permanent damage to the panel? > drm_panel_add(&jadard->panel); [Severity: High] This is a pre-existing issue, but does calling drm_panel_add() here publish the panel before critical internal state is initialized? drm_panel_add() makes the panel visible globally. A concurrent thread (e.g., a display controller driver probe in another workqueue or returning from EPROBE_DEFER) can immediately acquire the panel and call its callbacks. If a callback like jadard_get_modes() is invoked, it unconditionally dereferences jadard->desc. Since jadard->desc is initialized in the lines following this drm_panel_add() call, could this lead to a NULL pointer dereference and kernel panic? > > mipi_dsi_set_drvdata(dsi, jadard); > jadard->dsi = dsi; > jadard->desc = desc; -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
