linux-kernel - Re: [PATCH v2] clk: qcom: Add MSM8916 Global Clock Controller support

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: <54FA266A.2020502@codeaurora.org>
Date:	Fri, 06 Mar 2015 14:12:58 -0800
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Georgi Djakov <georgi.djakov@...aro.org>
CC:	mturquette@...aro.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v2] clk: qcom: Add MSM8916 Global Clock Controller support

On 03/05/15 11:58, Stephen Boyd wrote:
>
> I guess this is ok, but it makes me uneasy. We don't do any bimc
> PLL voting downstream because this PLL is completely under the
> control of the RPM. For all we know, the RPM hasn't configured
> the PLL to be in FSM voting mode so this may not even work.
> Furthermore, if we have clk_pll_ops then we'll go and try to
> turn off the PLL when the last software entity on the kernel side
> is done using it. Unfortunately, this PLL may be used by
> something else that the RPM is managing and so turning it off is
> going to break things.
>
> We mostly need this here to get the right rate for the bus clocks
> (which are usually constantly changing rate anyway so modeling it
> in the kernel is ok but not perfect). The best solution is
> probably to add some read-only PLL ops (clk_pll_ro_ops?) that we
> can put on the bimc_pll and drop the voting thing completely. The
> read-only ops would just detect the rate of the PLL and not
> support anything else.

Ah I looked back at the code and I think it may work out to leave the
PLL voting as is. If the RPM has configured it for voting, then our PLL
ops will bail out early in the enable/disable path. And voting isn't
going to hurt anything so that part should be alright. I hope that the
RPM is actually putting it in voting mode though and not leaving it
under their direct control. That shouldn't be happening but it'd be
worth a check.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/