Hi Kobayashi-san, On Thu, Apr 16, 2015 at 7:35 PM, Keita Kobayashi <keita.kobayashi.ym@xxxxxxxxxxx> wrote: > This patch add the ARM CPUs Device Tree binding to document a new > enable method of Renesas cpuidle. > > Signed-off-by: Keita Kobayashi <keita.kobayashi.ym@xxxxxxxxxxx> > --- > Documentation/devicetree/bindings/arm/cpus.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt > index 8b9e0a9..663ee11 100644 > --- a/Documentation/devicetree/bindings/arm/cpus.txt > +++ b/Documentation/devicetree/bindings/arm/cpus.txt > @@ -196,6 +196,7 @@ nodes to be present and contain the properties described below. > "qcom,gcc-msm8660" > "qcom,kpss-acc-v1" > "qcom,kpss-acc-v2" > + "renesas,rcar-idle" > "rockchip,rk3066-smp" > > - cpu-release-addr I don't mind this portion so much and I can see other vendors are using this format. And with risk of upsetting the DT police I have to mention my doubts about why we need this particular piece of binding. The proposed string by this patch does not seem to describe any hardware but it is aligned to other existing stings referring to software such as "spin-table" and "psci". From a C code implementation point of view we would get enough information to make a good decision by just checking SoC compatible string. At the same time, this seems to be the standard way of doing things and standard is good. So if we should turn this into something that describes actual hardware, how about pointing out the APMU hardware that is actually managing the Core Standby mode that this CPUIdle implementation is invoking? May I suggest using "renesas,rcar-apmu"? Or perhaps to be safe we should do per-SoC string like in other cases like "renesas,r8a7791-apmu"? Or is there some way we can make this work without adding a new binding? Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
