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: <CAD=FV=XA6nYCkpET9MQ4jbZBeM2fM8KF-pPAz=KdxOF0JxEzQw@mail.gmail.com>
Date: Fri, 15 Dec 2023 13:30:52 -0800
From: Doug Anderson <dianders@...omium.org>
To: Mukesh Ojha <quic_mojha@...cinc.com>
Cc: agross@...nel.org, andersson@...nel.org, konrad.dybcio@...aro.org, 
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Atul Dhudase <quic_adhudase@...cinc.com>
Subject: Re: [PATCH v2] soc: qcom: llcc: Fix dis_cap_alloc and retain_on_pc configuration

Hi,

On Wed, Dec 6, 2023 at 7:33 AM Mukesh Ojha <quic_mojha@...cinc.com> wrote:
>
> From: Atul Dhudase <quic_adhudase@...cinc.com>
>
> Commit c14e64b46944 ("soc: qcom: llcc: Support chipsets that can
>  write to llcc") add the support for chipset where capacity based
> allocation and retention through power collapse can be programmed
> based on content of SCT table mentioned in the llcc driver where
> the target like sdm845 where the entire programming related to it
> is controlled in firmware. However, the commit introduces a bug
> where capacity/retention register get overwritten each time it
> gets programmed for each slice and that results in misconfiguration
> of the register based on SCT table and that is not expected
> behaviour instead it should be read modify write to retain the
> configuration of other slices.
>
> This issue is totally caught from code review and programming test
> and not through any power/perf numbers so, it is not known what
> impact this could make if we don't have this change however,
> this feature are for these targets and they should have been
> programmed accordingly as per their configuration mentioned in
> SCT table like others bits information.
>
> This change brings one difference where it keeps capacity/retention
> bits of the slices that are not mentioned in SCT table in unknown
> state where as earlier it was initialized to zero.
>
> Fixes: c14e64b46944 ("soc: qcom: llcc: Support chipsets that can write to llcc")
> Signed-off-by: Atul Dhudase <quic_adhudase@...cinc.com>
> Signed-off-by: Mukesh Ojha <quic_mojha@...cinc.com>
> ---
> Changes in v2: https://lore.kernel.org/lkml/20231103105712.1159213-1-quic_adhudase@quicinc.com/
>  - Rewritten the commit text based on feedback in v1
>  - Aligned the lines in the code.
>
>  drivers/soc/qcom/llcc-qcom.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

The commit message is much more clear now, though I wish we actually
had more real details about what was in the other bits in the register
that aren't being cleared now and also if this has any effect on
power/performance. In any case, this still seems worthwhile to me to
land.

Reviewed-by: Douglas Anderson <dianders@...omium.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ