linux-kernel - Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

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

Date:   Thu, 2 Mar 2017 15:09:31 +0100
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Icenowy Zheng <icenowy@...c.xyz>
Cc:     Rob Herring <robh+dt@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
        linux-sunxi@...glegroups.com, devicetree@...r.kernel.org,
        Chen-Yu Tsai <wens@...e.org>
Subject: Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

On Wed, Mar 01, 2017 at 08:22:13PM +0800, Icenowy Zheng wrote:
> > I'm a bit worried by that to be honest. You claim to support the A31, 
> > yet jugdging by the current state of that code you never actually 
> > tested it on that SoC. 
> >
> > What makes you say that the PRCM clocks are the same for the H3 and 
> > A64? We have to be sure, otherwise we might not be able to get the DT 
> > binding right from the very beginning, and we might not be able to fix 
> > it later. 
> 
> In fact, if we worry about this, we shouldn't make r-ccu, as
> dedicated clocks are more easy to fix.
> 
> For newer SoCs' PRCM, we never have enough documents, and Allwinner
> have said that they cannot provide it. (I asked them for this.)
> 
> The best solution is to implement mature enough dedicated clocks
> before we convert to ccu.

What do you mean by dedicated clocks?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)