linux-kernel - Re: [PATCH] drm/msm/dpu: always program dsc active bits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e78e576a-2a04-e7ca-f6c4-701d508541ad@quicinc.com>
Date:   Wed, 12 Apr 2023 10:33:15 -0700
From:   Abhinav Kumar <quic_abhinavk@...cinc.com>
To:     Marijn Suijten <marijn.suijten@...ainline.org>
CC:     Kuogee Hsieh <quic_khsieh@...cinc.com>, <robdclark@...il.com>,
        <sean@...rly.run>, <swboyd@...omium.org>, <dianders@...omium.org>,
        <vkoul@...nel.org>, <daniel@...ll.ch>, <airlied@...il.com>,
        <agross@...nel.org>, <dmitry.baryshkov@...aro.org>,
        <andersson@...nel.org>, <quic_sbillaka@...cinc.com>,
        <freedreno@...ts.freedesktop.org>,
        <dri-devel@...ts.freedesktop.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/msm/dpu: always program dsc active bits



On 4/12/2023 12:24 AM, Marijn Suijten wrote:
> On 2023-04-11 16:45:34, Abhinav Kumar wrote:
> [..]
>>> Does this flush all DSCs programmed in CTL_DSC_FLUSH as set above?  That
>>> is currently still in `if (cfg->dsc)` and never overwritten if all DSCs
>>> are disabled, should it be taken out of the `if` to make sure no DSCs
>>> are inadvertently flushed, or otherwise cache the "previous mask" to
>>> make sure we flush exactly the right DSC blocks?
>>>
>>
>> Yes, DSC flush is hierarchical. This is the main DSC flush which will
>> enforce the flush of the DSC's we are trying to flush in the
>> CTL_DSC_FLUSH register.
> 
> That's what I was thinking, thanks for confirming.
> 
>> So if DSC was active, the CTL_FLUSH will only enforce the flush of the
>> DSC's programmed in CTL_DSC_FLUSH
>>
>> If DSC is not active, we still need to flush that as well (that was the
>> missing bit).
>>
>> No need to cache previous mask. That programming should be accurate in
>> cfg->dsc already.
> 
> This kind of implicit dependency warrants a comment at the very least.
> 

Sure.

> What happens if a device boots without DSC panel connected?  Will
> CTL_DSC_FLUSH be zero and not (unnecessarily, I assume) flush any of the
> DSC blocks?  Or could this flush uninitialized state to the block?
> 

If we bootup without DSC panel connected, the kernel's cfg->dsc will be 
0 and default register value of CTL_DSC_FLUSH will be 0 so it wont flush 
any DSC blocks. Sure, as I wrote in the other response, we can move this 
to reset_intf_cfg later when the other pieces are fixed. And leave a 
FIXME here.

> - Marijn