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:28:04 +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 v2] drm/msm/dpu: always program dsc active bits

On 2023-04-14 08:41:37, Abhinav Kumar wrote:
> 
> On 4/14/2023 12:48 AM, Marijn Suijten wrote:
> > Capitalize DSC in the title, as discussed in v1.
> > 
> > On 2023-04-13 08:56:41, Kuogee Hsieh wrote:
> >> In current code, the DSC active bits are written only if cfg->dsc is set.
> >> However, for displays which are hot-pluggable, there can be a use-case
> >> of disconnecting a DSC supported sink and connecting a non-DSC sink.
> >>
> >> For those cases we need to clear DSC active bits during tear down.
> >>
> >> Changes in V2:
> >> 1) correct commit text as suggested
> >> 2) correct Fixes commit id
> >> 3) add FIXME comment
> >>
> >> Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
> >> Signed-off-by: Kuogee Hsieh <quic_khsieh@...cinc.com>
> >> Reviewed-by: Marijn Suijten <marijn.suijten@...ainline.org>
> > 
> > By default git send-email should pick this up in the CC line...  but I
> > had to download this patch from lore once again.
> > 
> 
> Yes, I think what happened here is, he didnt git am the prev rev and 
> make changes on top of that so git send-email didnt pick up. We should 
> fix that process.

The mail was sent so it must have gone through git send-email, unless a
different mail client was used to send the .patch file.  I think you are
confusing this with git am (which doesn't need to be used if editing a
commit on a local branch) and subsequently git format-patch, which takes
a commit from a git repository and turns it into a .patch file: neither
of these "converts" r-b's (and other tags) to cc, that's happening in
git send-email (see `--suppress-cc` documentation in `man
git-send-email`).

I can recommend b4: it has lots of useful features including
automatically picking up reviews and processing revisions.  It even
requires a changelog to be edited ;).  However, finding the right flags
and trusting it'll "do as ordered" is a bit daunting at first.

> >> ---
> >>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8 ++++----
> >>   1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> index bbdc95c..1651cd7 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> @@ -541,10 +541,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
> >>   	if (cfg->merge_3d)
> >>   		DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
> >>   			      BIT(cfg->merge_3d - MERGE_3D_0));
> >> -	if (cfg->dsc) {
> >> -		DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
> >> -		DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
> >> -	}
> >> +
> >> +	/* FIXME: fix reset_intf_cfg to handle teardown of dsc */
> > 
> > There's more wrong than just moving (not "fix"ing) this bit of code into
> > reset_intf_cfg.  And this will have to be re-wrapped in `if (cfg->dsc)`
> > again by reverting this patch.  Perhaps that can be explained, or link
> > to Abhinav's explanation to make it clear to readers what this FIXME
> > actually means?  Let's wait for Abhinav and Dmitry to confirm the
> > desired communication here.
> > 
> > https://lore.kernel.org/linux-arm-msm/ec045d6b-4ffd-0f8c-4011-8db45edc6978@quicinc.com/
> > 
> 
> Yes, I am fine with linking this explanation in the commit text and 
> mentioning that till thats fixed, we need to go with this solution. The 
> FIXME itself is fine, I will work on it and I remember this context well.

Looks like it was removed entirely in v3, in favour of only describing
it in the patch body.  The wording seems a bit off but that's fine by me
if you're picking this up soon anyway.

- Marijn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ