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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 17 Feb 2017 10:28:00 +0000 From: Sudeep Holla <sudeep.holla@....com> To: devicetree@...r.kernel.org, orson.zhai@...eadtrum.com, open list <linux-kernel@...r.kernel.org>, linux-arm <linux-arm-kernel@...ts.infradead.org>, Chunyan Zhang <chunyan.zhang@...eadtrum.com> Cc: Rob Herring <robh+dt@...nel.org>, Mark Rutland <mark.rutland@....com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, Arnd Bergmann <arnd@...db.de>, Sudeep Holla <sudeep.holla@....com> Subject: Re: [PATCH 1/5] arm64: dts: Add basic DT to support Spreadtrum's SP9860G On 17/02/17 07:28, Chunyan Zhang wrote: > Hi Sudeep, > > On 二, 2月 14, 2017 at 04:44:53下午 +0000, Sudeep Holla wrote: >> On Tue, Feb 14, 2017 at 9:19 AM, Chunyan Zhang >> <chunyan.zhang@...eadtrum.com> wrote: [..] >> >>> + idle-states{ >>> + entry-method = "arm,psci"; >>> + >>> + CORE_PD: core_pd { >>> + compatible = "arm,idle-state"; >>> + entry-latency-us = <1000>; >>> + exit-latency-us = <700>; >>> + min-residency-us = <2500>; >>> + local-timer-stop; >>> + arm,psci-suspend-param = <0x00010002>; >>> + }; >>> + >>> + CLUSTER_PD: cluster_pd { >>> + compatible = "arm,idle-state"; >>> + entry-latency-us = <1000>; >>> + exit-latency-us = <1000>; >>> + min-residency-us = <3000>; >>> + local-timer-stop; >>> + arm,psci-suspend-param = <0x01010003>; >>> + }; >>> + >>> + DEEP_SLEEP: deep_sleep { >>> + compatible = "arm,idle-state"; >>> + wakeup-latency-us = <0xffffffff>; >> >> A value > 4294 seconds(i.e >1 hour) seems suspicious. >> Are you working around the firmware issue with high latency value so >> that it's never entered ? Why not remove advertising the state from DT. >> > > Haved checked with related colleagues, this node 'deep_sleep' was not for working > around any firmware issue, but was a trick utilization of idle subsystem, and that Really ? Any latency greater few milliseconds are sounds useless. I still don't understand what you mean by "trick utilization of idle subsystem". > was definitely not elegant, the author indeed intendly didn't want CPU entered this > state, I will remove this node therefore. It's quick and dirty "HACK* to retain and advertise the state but ensure it's never entered and obstruct the boot. It's not a trick to exploit any idle subsystem utilization. > >> Can you get me the dump of: >> grep "" /sys/devices/system/cpu/cpu*/cpuidle/state*/{time,usage} >> > > FYI: https://www.irccloud.com/pastebin/XyEMLzfq/ > As expected, state3(deep_sleep) is never entered. -- Regards, Sudeep
Powered by blists - more mailing lists