linux-kernel - Re: [PATCH 1/1] clk: qcom: smd: Add support for MSM8992/4 rpm clocks

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] [day] [month] [year] [list]

Message-ID: <20200711194746.GA388985@builder.lan>
Date:   Sat, 11 Jul 2020 12:47:46 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Konrad Dybcio <konradybcio@...il.com>, skrzynka@...radybcio.pl,
        Andy Gross <agross@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        linux-clk@...r.kernel.org, DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] clk: qcom: smd: Add support for MSM8992/4 rpm clocks

On Wed 24 Jun 15:32 PDT 2020, Stephen Boyd wrote:

> Quoting Konrad Dybcio (2020-06-24 08:09:18)
> > I should also note that for quite some time a hack [1]
> > has been needed on some platforms for the RPMCC to register.
> > 
> > This includes 8992/94, 8956/76 and possibly many more.
> > 
> > With that commit, RPMCC registers fine.
> > 
> 
> What happens if that patch isn't applied? Does the system crash? Because
> I'd rather not merge a patch in clk tree that causes the system to fail
> to boot.

The state machine code in the SMD implementation finds the RPM channel,
but it's in a state that indicates that the remote side is still
closing/cleaning up from when the bootloader had it open.

The result is that we never probe the RPM driver.

I merged a patch that would cause the logic here to be a little bit more
aggressive/optimistic, but that had to be reverted because it prevented
the modem from coming up cleanly after a crash. And I unfortunately
still don't have any hardware that manifest this problem that I can
debug this on myself.

But I think it's fine to merge the rpmcc patch (which I see you did).

Thanks,
Bjorn