| 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
| ||
|
Message-ID: <CAHLCerM83weBBvwurU45d9_M0Wg49WjDFTRJ6KL8vj7cavz03g@mail.gmail.com>
Date: Fri, 10 May 2019 23:58:40 +0530
From: Amit Kucheria <amit.kucheria@...aro.org>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Niklas Cassel <niklas.cassel@...aro.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Andy Gross <agross@...nel.org>,
David Brown <david.brown@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@...aro.org>,
Lina Iyer <lina.iyer@...aro.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
DTML <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: qcom: qcs404: Add PSCI cpuidle support
On Fri, May 10, 2019 at 2:54 PM Sudeep Holla <sudeep.holla@....com> wrote:
>
> On Thu, May 09, 2019 at 11:19:23PM +0530, Amit Kucheria wrote:
> > (Adding Lorenzo and Sudeep)
> >
> > On Wed, May 8, 2019 at 8:26 PM Niklas Cassel <niklas.cassel@...aro.org> wrote:
> > >
> > > On Wed, May 08, 2019 at 02:48:19AM +0530, Amit Kucheria wrote:
> > > > On Tue, May 7, 2019 at 1:01 AM Niklas Cassel <niklas.cassel@...aro.org> wrote:
> > > > >
> > > > > Add device bindings for CPUs to suspend using PSCI as the enable-method.
> > > > >
> > > > > Signed-off-by: Niklas Cassel <niklas.cassel@...aro.org>
> > > > > ---
> > > > > arch/arm64/boot/dts/qcom/qcs404.dtsi | 15 +++++++++++++++
> > > > > 1 file changed, 15 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > > > index ffedf9640af7..f9db9f3ee10c 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > > > +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > > > @@ -31,6 +31,7 @@
> > > > > reg = <0x100>;
> > > > > enable-method = "psci";
> > > > > next-level-cache = <&L2_0>;
> > > > > + cpu-idle-states = <&CPU_PC>;
> > > > > };
> > > > >
> > > > > CPU1: cpu@101 {
> > > > > @@ -39,6 +40,7 @@
> > > > > reg = <0x101>;
> > > > > enable-method = "psci";
> > > > > next-level-cache = <&L2_0>;
> > > > > + cpu-idle-states = <&CPU_PC>;
> > > > > };
> > > > >
> > > > > CPU2: cpu@102 {
> > > > > @@ -47,6 +49,7 @@
> > > > > reg = <0x102>;
> > > > > enable-method = "psci";
> > > > > next-level-cache = <&L2_0>;
> > > > > + cpu-idle-states = <&CPU_PC>;
> > > > > };
> > > > >
> > > > > CPU3: cpu@103 {
> > > > > @@ -55,12 +58,24 @@
> > > > > reg = <0x103>;
> > > > > enable-method = "psci";
> > > > > next-level-cache = <&L2_0>;
> > > > > + cpu-idle-states = <&CPU_PC>;
> > > > > };
> > > > >
> > > > > L2_0: l2-cache {
> > > > > compatible = "cache";
> > > > > cache-level = <2>;
> > > > > };
> > > > > +
> > > > > + idle-states {
> > > >
> > > > entry-method="psci" property goes here. I have a patch fixing it for 410c ;-)
> > > >
> > > > I don't think the psci_cpuidle_ops will even get called without this.
> > >
> > > Hello Amit,
> > >
> > > I added debug prints in psci_cpu_suspend_enter() and arm_cpuidle_suspend()
> > > when verifying this patch, and psci_cpu_suspend_enter() is indeed called,
> > > with the correct psci suspend parameter.
> > >
> > > The output from:
> > > grep "" /sys/bus/cpu/devices/cpu0/cpuidle/state?/*
> > > also looks sane.
> > >
> > > However, if 'entry-method="psci"' is required according to the DT binding,
> > > perhaps you can send a 2/2 series that fixes both this patch and msm8916 ?
> >
> > Last time I discussed this with Lorenzo and Sudeep (on IRC), I pointed
> > out that entry-method="psci" isn't checked for in code anywhere. Let's
> > get their view on this for posterity.
> >
>
> Yes entry-method="psci" is required as per DT binding but not checked
> in code on arm64. We have CPU ops with idle enabled only for "psci", so
> there's not need to check.
I don't see it being checked on arm32 either.
> Once we have DT schema validation, this will be caught, so it's better
> to fix it.
>
> > What does entry-method="psci" in the idle-states node achieve that
> > enable-method="psci" in the cpu node doesn't achieve? (Note: enable-
> > vs. entry-).
> >
>
> From DT binding perspective, we can have different CPU enable-method
> and CPU idle entry-method. However on arm64, it's restricted to PSCI
> only. I need to check what happens on arm32 though, as the driver
> invocation happens via CPUIDLE_METHOD_OF_DECLARE.
>
> > The enable-method property is the one that sets up the
> > psci_cpuidle_ops callbacks through the CPUIDLE_METHOD_OF_DECLARE
> > macro.
> >
>
> Indeed.
>
> > IOW, if we deprecated the entry-method property, everything would
> > still work, wouldn't it?
>
> Why do you want to deprecated just because Linux kernel doesn't want to
> use it. That's not a valid reason IMO.
Fair enough. Just want to make sure that it isn't some vestigial
property that was never used. Do you know if another OS is actually
using it?
> > Do we expect to support PSCI platforms that might have a different
> > entry-method for idle states?
>
> Not on ARM64, but same DT bindings can be used for idle-states on
> say RISC-V and have some value other than "psci".
Both enable-method and entry-method properties are currently only used
(and documented) for ARM platforms. Hence this discussion about
deprecation of one of them.
> > Should I whip up a patch removing entry-method? Since we don't check
> > for it today, it won't break the old DTs either.
> >
>
> Nope, I don't think so. But if it's causing issues, we can look into it.
> I don't want to restrict the use of the bindings for ARM/ARM64 or psci only.
Only a couple of minor issues:
1. There is a trickle of DTs that need fixing up every now and then
because they don't use entry-method in their idle-states node. Schema
validation ought to fix that.
2. A property that isn't ready by any code is a bit confusing. Perhaps
we can mention something to the effect in the documentation?
Regards,
Amit
Powered by blists - more mailing lists