linux-kernel - Re: [PATCH v2] drivers: qcom: Add BCM vote macro to header

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: <20190819165255.GA26807@tuxbook-pro>
Date:   Mon, 19 Aug 2019 09:52:55 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Jordan Crouse <jcrouse@...eaurora.org>,
        freedreno@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
        Michael Turquette <mturquette@...libre.com>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Andy Gross <agross@...nel.org>,
        Georgi Djakov <georgi.djakov@...aro.org>,
        linux-clk@...r.kernel.org, Taniya Das <tdas@...eaurora.org>
Subject: Re: [PATCH v2] drivers: qcom: Add BCM vote macro to header

On Wed 07 Aug 16:42 PDT 2019, Stephen Boyd wrote:

> Quoting Jordan Crouse (2019-08-05 13:33:46)
> > The macro to generate a Bus Controller Manager (BCM) TCS command is used
> > by the interconnect driver but might also be interesting to other
> > drivers that need to construct TCS commands for sub processors so move
> > it out of the sdm845 specific file and into the header.
> > 
> > Signed-off-by: Jordan Crouse <jcrouse@...eaurora.org>
> > ---
> 
> Acked-by: Stephen Boyd <sboyd@...nel.org>
> 
> Unless this is supposed to be applied by me?
> 
> BTW, I wonder why we need an rpm clk driver much at all nowadays, except
> maybe for the XO clk state. The big user, from what I can tell, is the
> interconnect driver and we don't use any of the features of the clk
> framework besides the API to set a frequency. Maybe it would be better
> to just push push the bus frequency logic into interconnect code, then
> XO clk is the only thing we need to keep, and it can be a simple on/off
> thing.
> 

There's been a number of cases where we'll need to enable the buffered
XOs, but perhaps these are handled by other subsystems these days(?)

If so the one case that remains would be the operation of explicitly
holding CXO enabled during operations such as booting the remoteprocs.

Regards,
Bjorn