All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Doug Anderson <dianders@chromium.org>
Cc: Caesar Wang <wxt@rock-chips.com>,
	Xu Jianqun <jay.xu@rock-chips.com>,
	Brian Norris <briannorris@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Elaine Zhang <zhangqing@rock-chips.com>
Subject: Re: [PATCH] arm64: dts: rockchip: add the power domain node for rk3399
Date: Fri, 01 Jul 2016 00:50:06 +0200	[thread overview]
Message-ID: <2164835.qn3FrgoRRc@phil> (raw)
In-Reply-To: <CAD=FV=Uaqp5MyERwBRd1yHLYS3T2mOm-FrMtXUjzjWhCEggG+Q@mail.gmail.com>

Am Donnerstag, 30. Juni 2016, 15:32:01 schrieb Doug Anderson:
> Hi,
> 
> On Thu, Jun 30, 2016 at 2:57 PM, Heiko Stuebner <heiko@sntech.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@RK3288_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

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
To: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	Brian Norris
	<briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Xu Jianqun <jay.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Subject: Re: [PATCH] arm64: dts: rockchip: add the power domain node for rk3399
Date: Fri, 01 Jul 2016 00:50:06 +0200	[thread overview]
Message-ID: <2164835.qn3FrgoRRc@phil> (raw)
In-Reply-To: <CAD=FV=Uaqp5MyERwBRd1yHLYS3T2mOm-FrMtXUjzjWhCEggG+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Am Donnerstag, 30. Juni 2016, 15:32:01 schrieb Doug Anderson:
> Hi,
> 
> On Thu, Jun 30, 2016 at 2:57 PM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> 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@RK3288_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

WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stuebner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: dts: rockchip: add the power domain node for rk3399
Date: Fri, 01 Jul 2016 00:50:06 +0200	[thread overview]
Message-ID: <2164835.qn3FrgoRRc@phil> (raw)
In-Reply-To: <CAD=FV=Uaqp5MyERwBRd1yHLYS3T2mOm-FrMtXUjzjWhCEggG+Q@mail.gmail.com>

Am Donnerstag, 30. Juni 2016, 15:32:01 schrieb Doug Anderson:
> Hi,
> 
> On Thu, Jun 30, 2016 at 2:57 PM, Heiko Stuebner <heiko@sntech.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 at RK3288_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

  reply	other threads:[~2016-06-30 22:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30  1:56 [PATCH] arm64: dts: rockchip: add the power domain node for rk3399 Caesar Wang
2016-06-30  1:56 ` Caesar Wang
2016-06-30  1:56 ` Caesar Wang
2016-06-30 21:49 ` Doug Anderson
2016-06-30 21:49   ` Doug Anderson
2016-06-30 21:49   ` Doug Anderson
2016-06-30 21:57   ` Heiko Stuebner
2016-06-30 21:57     ` Heiko Stuebner
2016-06-30 21:57     ` Heiko Stuebner
2016-06-30 22:32     ` Doug Anderson
2016-06-30 22:32       ` Doug Anderson
2016-06-30 22:32       ` Doug Anderson
2016-06-30 22:50       ` Heiko Stuebner [this message]
2016-06-30 22:50         ` Heiko Stuebner
2016-06-30 22:50         ` Heiko Stuebner
2016-07-01  2:11     ` Caesar Wang
2016-07-01  2:11       ` Caesar Wang
2016-07-01  2:11       ` Caesar Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2164835.qn3FrgoRRc@phil \
    --to=heiko@sntech.de \
    --cc=briannorris@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=jay.xu@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=wxt@rock-chips.com \
    --cc=zhangqing@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.