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  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

Powered by blists - more mailing lists