linux-kernel - Re: [PATCH] arm64: dts: rockchip: add the power domain node for rk3399

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: <2164835.qn3FrgoRRc@phil>
Date:	Fri, 01 Jul 2016 00:50:06 +0200
From:	Heiko Stuebner <heiko@...ech.de>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Caesar Wang <wxt@...k-chips.com>,
	Xu Jianqun <jay.xu@...k-chips.com>,
	Brian Norris <briannorris@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Elaine Zhang <zhangqing@...k-chips.com>
Subject: Re: [PATCH] arm64: dts: rockchip: add the power domain node for rk3399

Am Donnerstag, 30. Juni 2016, 15:32:01 schrieb Doug Anderson:
> Hi,
> 
> On Thu, Jun 30, 2016 at 2:57 PM, Heiko Stuebner <heiko@...ech.de> wrote:
> >> It looks like there are also more power domains that you haven't
> >> listed here (like PD_GMAC, for instance, or PD_CORE_L).  Are you
> >> planning to add those in a followon patch?
> > 
> > that reminds me, nodes with a reg property should have the base address
> > in the node name as well. Using the constant works nicely, as can be
> > seen on> 
> > the rk3288 where we have for example:
> >         pd_vio@...288_PD_VIO
> 
> I was wondering about that.  The device tree bindings are similarly
> missing the reg from the example.
> 
> I'm curious: for sorting purposes, are you supposed to know the
> underlying integer and use that for sorting, or sort by the name of
> the #define?

requiring the underlying integer sounds very cumbersome, especially as the 
sorting is only a style-thing. So personally I'd take the constants name as 
sorting criteria, as everything else would be somewhat counter-intuitive.

Heiko