mirror of
https://github.com/followmsi/android_kernel_google_msm.git
synced 2024-11-06 23:17:41 +00:00
doc: fix some typos in documentations
Fix some typos in five documentations, no functional change. Signed-off-by: Xishi Qiu <qiuxishi@huawei.com> Acked-by: Rob Landley <rob@landley.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This commit is contained in:
parent
48807e1710
commit
c79a8d85d7
4 changed files with 5 additions and 5 deletions
|
@ -533,7 +533,7 @@ also have
|
||||||
found. The count in 'mismatch_cnt' is the number of sectors
|
found. The count in 'mismatch_cnt' is the number of sectors
|
||||||
that were re-written, or (for 'check') would have been
|
that were re-written, or (for 'check') would have been
|
||||||
re-written. As most raid levels work in units of pages rather
|
re-written. As most raid levels work in units of pages rather
|
||||||
than sectors, this my be larger than the number of actual errors
|
than sectors, this may be larger than the number of actual errors
|
||||||
by a factor of the number of sectors in a page.
|
by a factor of the number of sectors in a page.
|
||||||
|
|
||||||
bitmap_set_bits
|
bitmap_set_bits
|
||||||
|
|
|
@ -71,7 +71,7 @@ To create an rfkill driver, driver's Kconfig needs to have
|
||||||
depends on RFKILL || !RFKILL
|
depends on RFKILL || !RFKILL
|
||||||
|
|
||||||
to ensure the driver cannot be built-in when rfkill is modular. The !RFKILL
|
to ensure the driver cannot be built-in when rfkill is modular. The !RFKILL
|
||||||
case allows the driver to be built when rfkill is not configured, which which
|
case allows the driver to be built when rfkill is not configured, which
|
||||||
case all rfkill API can still be used but will be provided by static inlines
|
case all rfkill API can still be used but will be provided by static inlines
|
||||||
which compile to almost nothing.
|
which compile to almost nothing.
|
||||||
|
|
||||||
|
|
|
@ -30,7 +30,7 @@ is something called unbounded priority inversion. That is when the high
|
||||||
priority process is prevented from running by a lower priority process for
|
priority process is prevented from running by a lower priority process for
|
||||||
an undetermined amount of time.
|
an undetermined amount of time.
|
||||||
|
|
||||||
The classic example of unbounded priority inversion is were you have three
|
The classic example of unbounded priority inversion is where you have three
|
||||||
processes, let's call them processes A, B, and C, where A is the highest
|
processes, let's call them processes A, B, and C, where A is the highest
|
||||||
priority process, C is the lowest, and B is in between. A tries to grab a lock
|
priority process, C is the lowest, and B is in between. A tries to grab a lock
|
||||||
that C owns and must wait and lets C run to release the lock. But in the
|
that C owns and must wait and lets C run to release the lock. But in the
|
||||||
|
|
|
@ -116,7 +116,7 @@ The branch(es) can then be switched via:
|
||||||
static_key_slow_dec(&key);
|
static_key_slow_dec(&key);
|
||||||
|
|
||||||
Thus, 'static_key_slow_inc()' means 'make the branch true', and
|
Thus, 'static_key_slow_inc()' means 'make the branch true', and
|
||||||
'static_key_slow_dec()' means 'make the the branch false' with appropriate
|
'static_key_slow_dec()' means 'make the branch false' with appropriate
|
||||||
reference counting. For example, if the key is initialized true, a
|
reference counting. For example, if the key is initialized true, a
|
||||||
static_key_slow_dec(), will switch the branch to false. And a subsequent
|
static_key_slow_dec(), will switch the branch to false. And a subsequent
|
||||||
static_key_slow_inc(), will change the branch back to true. Likewise, if the
|
static_key_slow_inc(), will change the branch back to true. Likewise, if the
|
||||||
|
@ -236,7 +236,7 @@ label case adds:
|
||||||
|
|
||||||
If we then include the padding bytes, the jump label code saves, 16 total bytes
|
If we then include the padding bytes, the jump label code saves, 16 total bytes
|
||||||
of instruction memory for this small function. In this case the non-jump label
|
of instruction memory for this small function. In this case the non-jump label
|
||||||
function is 80 bytes long. Thus, we have have saved 20% of the instruction
|
function is 80 bytes long. Thus, we have saved 20% of the instruction
|
||||||
footprint. We can in fact improve this even further, since the 5-byte no-op
|
footprint. We can in fact improve this even further, since the 5-byte no-op
|
||||||
really can be a 2-byte no-op since we can reach the branch with a 2-byte jmp.
|
really can be a 2-byte no-op since we can reach the branch with a 2-byte jmp.
|
||||||
However, we have not yet implemented optimal no-op sizes (they are currently
|
However, we have not yet implemented optimal no-op sizes (they are currently
|
||||||
|
|
Loading…
Reference in a new issue