linux-kernel - Re: [PATCH 0/3] firmware: qcom: scm: Improve clock handling

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]

Date:   Thu, 30 Aug 2018 18:17:41 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Andy Gross <andy.gross@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Sricharan R <sricharan@...eaurora.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        Craig Tatlor <ctatlor97@...il.com>
Subject: Re: [PATCH 0/3] firmware: qcom: scm: Improve clock handling

On Thu 30 Aug 18:07 PDT 2018, Stephen Boyd wrote:

> Quoting Bjorn Andersson (2018-08-29 16:15:02)
> > We're currently facing the issue that every new platform requires the addition
> > of a compatible to the DT binding as well as the driver.
> > 
> > The DT binding patch to allow us to use qcom,scm for all these new platforms
> > that doesn't require any clocks and the driver is reworked to make the qcom,scm
> > still pick up specified clocks in this case but won't require them.
> > 
> > This makes it possible to add new platforms by simply add the new compatible to
> > the list in the DT binding, but no changes needs to be done in the driver.
> > Which is what is done in patch 3.
> > 
> 
> I still think it may be even simpler to move to the "get all the clks"
> API and then stop caring completely. Any reason to not do that?
> 

I love working with drivers that tells me things like "hey you forgot to
add the 'core' clock", rather than having to spend hours bisecting which
register access it is that's causing that reboot and then try to drill
that down to a particular clock.

Apart from that, the "get-all-the-clocks" would work fine as well. Does
this API exist yet?

Regards,
Bjorn