@@ -11,7 +11,7 @@ Introduction
1111============
1212
1313This framework is designed to abstract complex power-up sequences that are
14- shared between multiple logical devices in the linux kernel.
14+ shared between multiple logical devices in the Linux kernel.
1515
1616The intention is to allow consumers to obtain a power sequencing handle
1717exposed by the power sequence provider and delegate the actual requesting and
@@ -25,7 +25,7 @@ The power sequencing API uses a number of terms specific to the subsystem:
2525
2626Unit
2727
28- A unit is a discreet chunk of a power sequence. For instance one unit may
28+ A unit is a discrete chunk of a power sequence. For instance one unit may
2929 enable a set of regulators, another may enable a specific GPIO. Units can
3030 define dependencies in the form of other units that must be enabled before
3131 it itself can be.
@@ -62,7 +62,7 @@ Provider interface
6262The provider API is admittedly not nearly as straightforward as the one for
6363consumers but it makes up for it in flexibility.
6464
65- Each provider can logically split the power-up sequence into descrete chunks
65+ Each provider can logically split the power-up sequence into discrete chunks
6666(units) and define their dependencies. They can then expose named targets that
6767consumers may use as the final point in the sequence that they wish to reach.
6868
@@ -72,7 +72,7 @@ register with the pwrseq subsystem by calling pwrseq_device_register().
7272Dynamic consumer matching
7373-------------------------
7474
75- The main difference between pwrseq and other linux kernel providers is the
75+ The main difference between pwrseq and other Linux kernel providers is the
7676mechanism for dynamic matching of consumers and providers. Every power sequence
7777provider driver must implement the `match() ` callback and pass it to the pwrseq
7878core when registering with the subsystems.
0 commit comments