linux-kernel - [PATCH 1/5] dt-bindings: arm: idle-states: Use "e.g." and "i.e." consistently

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: <20190830150302.20551-2-geert+renesas@glider.be>
Date:   Fri, 30 Aug 2019 17:02:58 +0200
From:   Geert Uytterhoeven <geert+renesas@...der.be>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Amit Kucheria <amit.kucheria@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Cc:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        Nicolas Pitre <nico@...aro.org>,
        Sebastian Capella <sebcape@...il.com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Geert Uytterhoeven <geert+renesas@...der.be>
Subject: [PATCH 1/5] dt-bindings: arm: idle-states: Use "e.g." and "i.e." consistently

Replace abbreviations "eg" and "ie" by "e.g." resp. "i.e." for
consistency.

Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
---
 .../devicetree/bindings/arm/idle-states.txt      | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
index 2d325bed37e53c1c..610b16c28d99c3ef 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -28,7 +28,7 @@ PM implementation to put the processor in different idle states (which include
 states listed above; "off" state is not an idle state since it does not have
 wake-up capabilities, hence it is not considered in this document).
 
-Idle state parameters (eg entry latency) are platform specific and need to be
+Idle state parameters (e.g. entry latency) are platform specific and need to be
 characterized with bindings that provide the required information to OS PM
 code so that it can build the required tables and use them at runtime.
 
@@ -90,20 +90,20 @@ These timing parameters can be used by an OS in different circumstances.
 
 An idle CPU requires the expected min-residency time to select the most
 appropriate idle state based on the expected expiry time of the next IRQ
-(ie wake-up) that causes the CPU to return to the EXEC phase.
+(i.e. wake-up) that causes the CPU to return to the EXEC phase.
 
 An operating system scheduler may need to compute the shortest wake-up delay
 for CPUs in the system by detecting how long will it take to get a CPU out
-of an idle state, eg:
+of an idle state, e.g.:
 
 wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
 
 In other words, the scheduler can make its scheduling decision by selecting
-(eg waking-up) the CPU with the shortest wake-up latency.
+(e.g. waking-up) the CPU with the shortest wake-up latency.
 The wake-up latency must take into account the entry latency if that period
 has not expired. The abortable nature of the PREP period can be ignored
 if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
-the worst case since it depends on the CPU operating conditions, ie caches
+the worst case since it depends on the CPU operating conditions, i.e. caches
 state).
 
 An OS has to reliably probe the wakeup-latency since some devices can enforce
@@ -183,15 +183,15 @@ and IDLE2:
 		Graph 2: idle states min-residency example
 
 In graph 2 above, that takes into account idle states entry/exit energy
-costs, it is clear that if the idle state residency time (ie time till next
+costs, it is clear that if the idle state residency time (i.e. time till next
 wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
 choice energywise.
 
 This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
 than IDLE2.
 
-However, the lower power consumption (ie shallower energy curve slope) of idle
-state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
+However, the lower power consumption (i.e. shallower energy curve slope) of
+idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
 efficient.
 
 The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
-- 
2.17.1