Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [Medium] The panel initialization sequence uses a byte-swapped magic number 
(`0xff07`) to set display brightness, exploiting the little-endian behavior of 
`mipi_dsi_dcs_set_display_brightness_multi` to send a big-endian sequence.
--

--- Patch [4]: [PATCH 4/4] drm/panel: visionox-vtdr6130: Add Retroid Pocket 6 
panel ---
commit 2ba31f55071d4cfd213a7bfcbe0e2720a74312ac
Author: Aaron Kling <[email protected]>

drm/panel: visionox-vtdr6130: Add Retroid Pocket 6 panel

This commit adds support for the 1080x1920 panel used in the Retroid
Pocket 6 handheld console.

> diff --git a/drivers/gpu/drm/panel/panel-visionox-vtdr6130.c 
> b/drivers/gpu/drm/panel/panel-visionox-vtdr6130.c
> index 805c9846c2a0b..5c826f95ec478 100644
> --- a/drivers/gpu/drm/panel/panel-visionox-vtdr6130.c
> +++ b/drivers/gpu/drm/panel/panel-visionox-vtdr6130.c

[ ... ]

> +static int retroidpocket_rp6_on(struct visionox_vtdr6130 *ctx)
> +{
> +     struct mipi_dsi_device *dsi = ctx->dsi;
> +     struct mipi_dsi_multi_context dsi_ctx = { .dsi = dsi };
> +     struct drm_dsc_picture_parameter_set pps;
> +
> +     dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> +     mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0x03, 0x01);
> +     mipi_dsi_dcs_set_tear_on_multi(&dsi_ctx, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> +     mipi_dsi_dcs_write_seq_multi(&dsi_ctx,
> +                                  MIPI_DCS_WRITE_CONTROL_DISPLAY, 0x20);
> +     mipi_dsi_dcs_set_display_brightness_multi(&dsi_ctx, 0xff07);

[Severity: Medium]
Is this intentionally passing a byte-swapped magic number (0xff07) to
compensate for mipi_dsi_dcs_set_display_brightness_multi() sending the
brightness value LSB-first?

The DCS specification requires the brightness parameter to be MSB-first. By
passing 0xff07, it appears this code intentionally sends 0x07 followed by
0xff so the panel receives 0x07ff (2047) MSB-first.

If the core helper is ever corrected to comply with the DCS specification,
this sequence will send 0xff followed by 0x07, which the panel will interpret
as 0xff07 (65287), drastically exceeding the intended brightness.

Should this instead send the raw bytes explicitly using
mipi_dsi_dcs_write_seq_multi(&dsi_ctx, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
0x07, 0xff) to avoid depending on the helper's current endianness behavior?

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=4

Reply via email to