linux-kernel - Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

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: <8683375.pL9J7LxuT0@diego>
Date:   Tue, 10 Jan 2017 20:46:12 +0100
From:   Heiko Stübner <heiko@...ech.de>
To:     Doug Anderson <dianders@...gle.com>
Cc:     Xing Zheng <zhengxing@...k-chips.com>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Caesar Wang <wxt@...k-chips.com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Brian Norris <briannorris@...omium.org>,
        Jianqun Xu <jay.xu@...k-chips.com>,
        Elaine Zhang <zhangqing@...k-chips.com>,
        David Wu <david.wu@...k-chips.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> Hi,
> 
> On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@...k-chips.com> 
wrote:
> > The structure rockchip_clk_provider needs to refer the GRF regmap
> > in somewhere, if the CRU node has not "rockchip,grf" property,
> > calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> > regmap, and the MUXGRF type clock will be not supported.
> > 
> > Therefore, we need to add them.
> > 
> > Signed-off-by: Xing Zheng <zhengxing@...k-chips.com>
> > ---
> > 
> > Changes in v4:
> > - separte the binding patch
> > 
> > Changes in v3:
> > - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
> > 
> > Changes in v2:
> > - referring pmugrf for PMUGRU
> > - fix the typo "invaild" in COMMIT message
> > 
> >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> This seems fine to me, so:
> 
> Reviewed-by: Douglas Anderson <dianders@...omium.org>
> 
> ...but I will say that before you actually add any real "MUXGRF"
> clocks on rk3399 you _might_ need to rework the code to make things
> truly "optional".  If it turns out that any existing clocks that
> already exist today already go through one of these muxes in the GRF
> and we've always been assuming one setting of the mux, we'll need to
> make sure we keep assuming that setting of the mux even if the "grf"
> isn't specified.

I guess I see that a bit more relaxed :-) .

I.e. the GRF being optional is a remnant of syscons not being available when 
the clocks get set up- so were coming in later or not at all. For the rk3288 I 
converted, there we never really had the case of the GRF missing.

And the GRF mux for the vcodec now present is not being used by anything yet 
(neither driver nor binding), so no old devicetree can break.


> As I understand it, your motivation for this patch is to eventually be
> able to model the EDP reference clock which can either be xin24 or
> "edp osc".  Presumably the eDP "reference clock" isn't related to any
> of the pre-existing eDP clocks so that one should be safe.

Same here, so far we don't even have edp or even any other graphical output on 
the rk3399, so again there is no old devicetree that could break when the grf 
is not specified.


So, for me that looks good.


Heiko