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

Message-Id: <20190819182654.A950222CF6@mail.kernel.org>
Date:   Mon, 19 Aug 2019 11:26:53 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.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

Quoting Bjorn Andersson (2019-08-19 09:52:55)
> 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.
> 

Yes I think the XO (and the buffers) is the only thing that we really
seem to care about for the clk tree. Otherwise, the sole user is
interconnect code and thus handling it in the rpmh clk driver doesn't
really gain us anything. In fact, it just makes it worse because it ties
the clk tree up with things that could take a while to process on the
RPM side.