linux-kernel - Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT

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:   Thu, 10 Nov 2016 15:30:01 -0800
From:   'Stephen Boyd' <sboyd@...eaurora.org>
To:     Sricharan <sricharan@...eaurora.org>
Cc:     'Rajendra Nayak' <rnayak@...eaurora.org>, mturquette@...libre.com,
        linux-clk@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, stanimir.varbanov@...aro.org
Subject: Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus
 core0/1 clks

On 11/09, Sricharan wrote:
> 
> So the above is the sequence which is actually carried out on the
> firmware side. The same can be done in host as well.
> The clocks stuck issue indeed is not there with this.

Great! We've finally connected on what the actual problem is.

> But with the above sequence we need to add a step to do inverse
> of STEP3 above (ie write the registers to de-assert hw_signal),
> to keep the subdomains in off, till firmware uses it. So the
> above sequence helps to avoid masking the halt check, although
> the host really does not wants to use these clocks, except
> setting it up for the firmware.
> 

Right, but knowing that the clocks failed to turn on in the first
place is much safer than silently ignoring the failure.
Otherwise, we could hand over control to the firmware, and the
firmware would fail to operate the hardware, and we're stuck with
debugging the firmware now. That sounds quite painful to figure
out.

If we properly toggle the video hw bits in coordination with
firmware and turn on/off the clocks with the GDSC ON, then
debugging is made simpler. The point is, we don't want to lose
robustness by silencing halt checks. The semantics of
clk_enable() means the clock is running, and that won't be true
here unless we ensure the GDSC is enabled.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project