[PATCH v2 16/20] drm/msm/dp: Disable PSR for YUV420 streams

sashiko-bot at kernel.org sashiko-bot at kernel.org
Thu Oct 8 20:34:09 PDT 2026


Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/msm: endianness bug on DP_PSR_EN_CFG write using u32 pointer
--

commit d1403cc5c58c4528368941f08f1ea1ec332d1a49
Author: Xilin Wu <sophon at radxa.com>

drm/msm/dp: Disable PSR for YUV420 streams

This commit disables self-refresh for YUV420 streams because their
colorimetry VSC packets cannot share the automatic PSR packet generator.
It computes eligibility after common atomic checks and restores PSR
configuration accordingly.

> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 783cafb223748..82ef8e4055431 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
[ ... ]
> @@ -1923,15 +1923,20 @@ void msm_dp_ctrl_config_psr(struct msm_dp_ctrl *msm_dp_ctrl,
[ ... ]
> -	cfg = DP_PSR_ENABLE;
> +	cfg = enable ? DP_PSR_ENABLE : 0;
>  	drm_dp_dpcd_write(ctrl->aux, DP_PSR_EN_CFG, &cfg, 1);

[Severity: Medium]
Could this silently write 0 and fail to enable PSR on big-endian platforms?

The variable cfg is defined as a u32 at the beginning of
msm_dp_ctrl_config_psr(). When its address is passed to drm_dp_dpcd_write()
with a size of 1 byte, little-endian systems will correctly read the least
significant byte containing the enable bit. 

However, on big-endian systems, taking the address of a u32 and reading 1
byte will read the most significant byte instead (which is 0x00).

Would using a u8 variable or drm_dp_dpcd_writeb() avoid this structural
mismatch and ensure the correct byte is written regardless of architecture
endianness?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009-msm-dp-hdr10-v2-0-1835d4966da3@radxa.com?part=16



More information about the linux-amlogic mailing list