[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <173983182587.1719712.14378723556060583905.b4-ty@quicinc.com>
Date: Mon, 17 Feb 2025 14:38:23 -0800
From: Abhinav Kumar <quic_abhinavk@...cinc.com>
To: Rob Clark <robdclark@...il.com>,
Dmitry Baryshkov
<dmitry.baryshkov@...aro.org>,
Sean Paul <sean@...rly.run>, David Airlie
<airlied@...il.com>,
Simona Vetter <simona@...ll.ch>, Vinod Koul
<vkoul@...nel.org>,
Marijn Suijten <marijn.suijten@...ainline.org>
CC: Abhinav Kumar <quic_abhinavk@...cinc.com>,
<~postmarketos/upstreaming@...ts.sr.ht>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>,
Konrad Dybcio
<konrad.dybcio@....qualcomm.com>,
Martin Botka <martin.botka@...ainline.org>,
Jami Kettunen <jami.kettunen@...ainline.org>,
<linux-arm-msm@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
<freedreno@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>
Subject: Re: (subset) [PATCH] drm/msm/dpu: Don't leak bits_per_component into random DSC_ENC fields
On Tue, 11 Feb 2025 00:19:32 +0100, Marijn Suijten wrote:
> What used to be the input_10_bits boolean - feeding into the lowest
> bit of DSC_ENC - on MSM downstream turned into an accidental OR with
> the full bits_per_component number when it was ported to the upstream
> kernel.
>
> On typical bpc=8 setups we don't notice this because line_buf_depth is
> always an odd value (it contains bpc+1) and will also set the 4th bit
> after left-shifting by 3 (hence this |= bits_per_component is a no-op).
>
> [...]
Applied to msm-fixes, thanks!
[1/1] drm/msm/dpu: Don't leak bits_per_component into random DSC_ENC fields
https://gitlab.freedesktop.org/drm/msm/-/commit/144429831f44
Best regards,
--
Abhinav Kumar <quic_abhinavk@...cinc.com>
Powered by blists - more mailing lists