linux-kernel - Re: [PATCH v2 20/22] interconnect: qcom: icc-rpm: Set bandwidth on both contexts

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: <ZITEacAtcaZRY6ib@gerhold.net>
Date:   Sat, 10 Jun 2023 20:43:53 +0200
From:   Stephan Gerhold <stephan@...hold.net>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Georgi Djakov <djakov@...nel.org>,
        Leo Yan <leo.yan@...aro.org>,
        Evan Green <evgreen@...omium.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 20/22] interconnect: qcom: icc-rpm: Set bandwidth on
 both contexts

On Sat, Jun 10, 2023 at 08:28:22PM +0200, Konrad Dybcio wrote:
> 
> 
> On 10.06.2023 20:00, Stephan Gerhold wrote:
> > On Fri, Jun 09, 2023 at 10:19:25PM +0200, Konrad Dybcio wrote:
> >> Up until now, for some reason we've only been setting bandwidth values
> >> on the active-only context. That pretty much meant that RPM could lift
> >> all votes when entering sleep mode. Or never sleep at all.
> >>
> >> That in turn could potentially break things like USB wakeup, as the
> >> connection between APSS and SNoC/PNoC would simply be dead.
> >>
> > 
> > Nitpick: Apparently an "active" vote is applied during both active+sleep
> > until the first "sleep" vote is sent. It's documented only for
> > regulators [1] but I would expect the same applies to the bandwidths.
> > This means actual breakage shouldn't have been possible.
> ..unless some part of the boot chain voted for the sleep set!
> 
> I'm not sure whether the regulator comment also holds for bw, but I
> also don't really have a great way to check it.. Would you want me to
> alter this commit message somehow?
> 

Hm. Well, on a second look you used "could" instead of "definitely does"
everywhere in your commit message. There is a indeed a slight chance
so feel free to just keep it as-is. :D

Thanks,
Stephan