doc: fix some typos in documentations
PATCH 1/1 doc: fix some typos in documentations
Fix some typos in five documentations, no functional change.
Signed-off-by Xishi Qiu <[email protected]>
--- Documentation/md.txt | 2 +- Documentation/rfkill.txt | 2 +- Documentation/rt-mutex-design.txt | 2 +- Documentation/static-keys.txt | 4 ++-- Documentation/sysfs-rules.txt | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-)
Documentation/md.txt +1 -1
@@ -533,7 +533,7 @@ also have found. The count in 'mismatch_cnt' is the number of sectors that were re-written, or (for 'check') would have been 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. bitmap_set_bits
Documentation/rfkill.txt +1 -1
@@ -71,7 +71,7 @@ To create an rfkill driver, driver's Kconfig needs to have depends on RFKILL || !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 which compile to almost nothing.
Documentation/rt-mutex-design.txt +1 -1
@@ -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 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 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
Documentation/static-keys.txt +2 -2
@@ -116,7 +116,7 @@ The branch(es) can then be switched via: static_key_slow_dec(&key); 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 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
@@ -236,7 +236,7 @@ label case adds: 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 -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 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
Documentation/sysfs-rules.txt +1 -1
@@ -47,7 +47,7 @@ versions of the sysfs interface. at device creation and removal - the unique key to the device at that point in time - the kernel's path to the device directory without the leading - /sys, and always starting with with a slash + /sys, and always starting with a slash - all elements of a devpath must be real directories. Symlinks pointing to /sys/devices must always be resolved to their real target and the target path must be used to access the device.
Signature · 1 line
1.7.1
Documentation/rfkill.txt To create an rfkill driver, driver's Kconfig needs to have · line 76
Quoted 6 lines · Xishi Qiu
to ensure the driver cannot be built-in when rfkill is modular. The !RFKILL
Documentation/rfkill.txt +1
-1-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 which compile to almost nothing.
It looks like this was intended to say "in which" instead of the "which which" you remove, rather than just "which".
johannes
Quoted 11 lines · Johannes Berg
Documentation/rfkill.txt To create an rfkill driver, driver's Kconfig needs to have · line 76
Quoted 6 lines · Xishi Qiu
to ensure the driver cannot be built-in when rfkill is modular. The !RFKILL
Documentation/rfkill.txt +1
-1-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 which compile to almost nothing.It looks like this was intended to say "in which" instead of the "which which" you remove, rather than just "which".
Quoted 2 lines
johannes
Yes, "in which" seems to be better.
Thanks,
Xishi Qiu