linux-kernel - Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update bindings

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: <20170726004830.GI2146@codeaurora.org>
Date:   Tue, 25 Jul 2017 17:48:30 -0700
From:   Stephen Boyd <sboyd@...eaurora.org>
To:     Jerome Brunet <jbrunet@...libre.com>
Cc:     Neil Armstrong <narmstrong@...libre.com>,
        Rob Herring <robh@...nel.org>, linux-clk@...r.kernel.org,
        linux-amlogic@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update
 bindings

On 07/24, Jerome Brunet wrote:
> On Mon, 2017-07-24 at 13:47 +0200, Neil Armstrong wrote:
> > 
> > Hi Rob, Stephen,
> > 
> > Thanks for your feedback, but on these Amlogic platforms, the AO register bank
> > is
> > filled with interleaved registers used for various purposes.
> > 
> > For instance, the first 1k of registers are :
> > 
> > 0-c RTI_STATUS
> > c-14 RTI_PWR_CNTL
> > 14-1c PIN_MUX
> > 1c RTI_STATUS
> > 24-30 GPIO
> > 30 JTAG_CONFIG
> > 34 WD
> > 38-40 CPU_CTRL
> > 40 RTI_GEN_CTRL
> > 44 CPU_CTRL
> > 4c-58 TIMER
> > 58 OSCIN
> > 60 AHB2DDR
> > ...
> > 
> > 
> > And so on, and the clock related registers are split among this space.
> > 
> > For sure, this could be declared as an system controller node, but this would
> > imply completely
> > re-designing the actual clock driver and drop the actual bindings.
> > (and with re-writting the clock gate code to use regmap registers access)

I'm not suggesting a sycon node or binding usage here. There's an
"always on" hw block here that could be implemented as an MFD
driver that binds and creates a clk subdevice and whatever else
is sitting in here. Those subdevices could be informed of the
register base by knowing their parent driver is an MFD with a
certain driver data structure inside and then get at an __iomem
pointer through the parent's driver data. Or they could use a
regmap approach and rewrite a bunch of code. Or there could be
just a clk driver that binds to this node for now until a later
time that other features are needed.

> 
> Maybe it is time to investigate having the regmap clock from qcom available to
> every other platform ?

I think we have regmap clk duplicated a couple times in the
drivers/clk/ directory now. Not sure how this is related, except
for that there looks to be a desire to use a syscon binding here
and that forces regmap on drivers?

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