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]
Date:   Fri, 14 Apr 2023 19:34:28 +0200
From:   Marijn Suijten <marijn.suijten@...ainline.org>
To:     Abhinav Kumar <quic_abhinavk@...cinc.com>
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 2023-04-14 08:48:43, Abhinav Kumar wrote:
> 
> On 4/14/2023 12:35 AM, Marijn Suijten wrote:
> > On 2023-04-12 10:33:15, Abhinav Kumar wrote:
> > [..]
> >>> 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.
> > 
> > Ack, that makes sense.  However, if I connect a DSC panel, then
> > disconnect it (now the register should be non-zero, but cfg->dsc will be
> > zero), and then replug a non-DSC panel multiple times, it'll get flushed
> > every time because we never clear CTL_DSC_FLUSH after that?
> > 
> 
> If we remove it after kernel starts, that issue is there even today 
> without that change because DSI is not a hot-pluggable display so a 
> teardown wont happen when you plug out the panel. How will cfg->dsc be 0 
> then? In that case, its not a valid test as there was no indication to 
> DRM that display was disconnected so we cannot tear it down.

The patch description itself describes hot-pluggable displays, which I
believe is the upcoming DSC support for DP?  You ask how cfg->dsc can
become zero, but this is **exactly** what the patch description
describes, and what this patch is removing the `if` for.  If we are not
allowed to discuss that scenario because it is not currently supported,
neither should we allow to apply this patch.

With that in mind, can you re-answer the question?

- Marijn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ