mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
synced 2024-12-29 17:22:07 +00:00
doc: fix quite a few typos within Documentation
Correct spelling typo in Documentations Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This commit is contained in:
parent
20879696b7
commit
4e79162a52
@ -92,7 +92,7 @@ Description: The /dev/kmsg character device node provides userspace access
|
||||
The flags field carries '-' by default. A 'c' indicates a
|
||||
fragment of a line. All following fragments are flagged with
|
||||
'+'. Note, that these hints about continuation lines are not
|
||||
neccessarily correct, and the stream could be interleaved with
|
||||
necessarily correct, and the stream could be interleaved with
|
||||
unrelated messages, but merging the lines in the output
|
||||
usually produces better human readable results. A similar
|
||||
logic is used internally when messages are printed to the
|
||||
|
@ -164,7 +164,7 @@ Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Description:
|
||||
The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
|
||||
contains the total time the device has been preventing
|
||||
opportunistic transitions to sleep states from occuring.
|
||||
opportunistic transitions to sleep states from occurring.
|
||||
This attribute is read-only. If the device is not enabled to
|
||||
wake up the system from sleep states, this attribute is not
|
||||
present.
|
||||
|
@ -5,7 +5,7 @@ Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This folder includes the attributes related with PPI (Physical
|
||||
Presence Interface). Only if TPM is supported by BIOS, this
|
||||
folder makes sence. The folder path can be got by command
|
||||
folder makes sense. The folder path can be got by command
|
||||
'find /sys/ -name 'pcrs''. For the detail information of PPI,
|
||||
please refer to the PPI specification from
|
||||
http://www.trustedcomputinggroup.org/
|
||||
|
@ -376,7 +376,7 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases:
|
||||
leaving the cpu domain and flushing caches at fault time. Note that all the
|
||||
dma_buf files share the same anon inode, hence the exporter needs to replace
|
||||
the dma_buf file stored in vma->vm_file with it's own if pte shootdown is
|
||||
requred. This is because the kernel uses the underlying inode's address_space
|
||||
required. This is because the kernel uses the underlying inode's address_space
|
||||
for vma tracking (and hence pte tracking at shootdown time with
|
||||
unmap_mapping_range).
|
||||
|
||||
@ -388,7 +388,7 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases:
|
||||
Exporters that shoot down mappings (for any reasons) shall not do any
|
||||
synchronization at fault time with outstanding device operations.
|
||||
Synchronization is an orthogonal issue to sharing the backing storage of a
|
||||
buffer and hence should not be handled by dma-buf itself. This is explictly
|
||||
buffer and hence should not be handled by dma-buf itself. This is explicitly
|
||||
mentioned here because many people seem to want something like this, but if
|
||||
different exporters handle this differently, buffer sharing can fail in
|
||||
interesting ways depending upong the exporter (if userspace starts depending
|
||||
|
@ -1,7 +1,7 @@
|
||||
Notifier error injection
|
||||
========================
|
||||
|
||||
Notifier error injection provides the ability to inject artifical errors to
|
||||
Notifier error injection provides the ability to inject artificial errors to
|
||||
specified notifier chain callbacks. It is useful to test the error handling of
|
||||
notifier call chain failures which is rarely executed. There are kernel
|
||||
modules that can be used to test the following notifiers.
|
||||
@ -14,7 +14,7 @@ modules that can be used to test the following notifiers.
|
||||
CPU notifier error injection module
|
||||
-----------------------------------
|
||||
This feature can be used to test the error handling of the CPU notifiers by
|
||||
injecting artifical errors to CPU notifier chain callbacks.
|
||||
injecting artificial errors to CPU notifier chain callbacks.
|
||||
|
||||
If the notifier call chain should be failed with some events notified, write
|
||||
the error code to debugfs interface
|
||||
|
@ -108,7 +108,7 @@ the request was handled successfully.
|
||||
UHID_FEATURE_ANSWER:
|
||||
If you receive a UHID_FEATURE request you must answer with this request. You
|
||||
must copy the "id" field from the request into the answer. Set the "err" field
|
||||
to 0 if no error occured or to EIO if an I/O error occurred.
|
||||
to 0 if no error occurred or to EIO if an I/O error occurred.
|
||||
If "err" is 0 then you should fill the buffer of the answer with the results
|
||||
of the feature request and set "size" correspondingly.
|
||||
|
||||
|
@ -133,7 +133,7 @@ number of contacts (f1 and f0 in the table below).
|
||||
|
||||
This packet only appears after a position packet with the mt bit set, and
|
||||
usually only appears when there are two or more contacts (although
|
||||
occassionally it's seen with only a single contact).
|
||||
occasionally it's seen with only a single contact).
|
||||
|
||||
The final v3 packet type is the trackstick packet.
|
||||
|
||||
|
@ -470,7 +470,7 @@ build.
|
||||
|
||||
Sometimes, an external module uses exported symbols from
|
||||
another external module. kbuild needs to have full knowledge of
|
||||
all symbols to avoid spitting out warnings about undefined
|
||||
all symbols to avoid spliitting out warnings about undefined
|
||||
symbols. Three solutions exist for this situation.
|
||||
|
||||
NOTE: The method with a top-level kbuild file is recommended
|
||||
|
@ -214,7 +214,7 @@ static ssize_t mei_send_msg(struct mei *me, const unsigned char *buffer,
|
||||
}
|
||||
|
||||
/***************************************************************************
|
||||
* Intel Advanced Management Technolgy ME Client
|
||||
* Intel Advanced Management Technology ME Client
|
||||
***************************************************************************/
|
||||
|
||||
#define AMT_MAJOR_VERSION 1
|
||||
@ -256,7 +256,7 @@ struct amt_code_versions {
|
||||
} __attribute__((packed));
|
||||
|
||||
/***************************************************************************
|
||||
* Intel Advanced Management Technolgy Host Interface
|
||||
* Intel Advanced Management Technology Host Interface
|
||||
***************************************************************************/
|
||||
|
||||
struct amt_host_if_msg_header {
|
||||
|
@ -43,7 +43,7 @@ Very nice card if you only have satellite TV but several tuners connected
|
||||
to the card via composite.
|
||||
|
||||
Many thanks to Matrix-Vision for giving us 2 cards for free which made
|
||||
Bt848a/Bt849 single crytal operation support possible!!!
|
||||
Bt848a/Bt849 single crystal operation support possible!!!
|
||||
|
||||
|
||||
|
||||
|
@ -193,7 +193,7 @@ faster.
|
||||
or maybe swap-over-nbd/NFS)?
|
||||
|
||||
No. First, the existing swap subsystem doesn't allow for any kind of
|
||||
swap hierarchy. Perhaps it could be rewritten to accomodate a hierarchy,
|
||||
swap hierarchy. Perhaps it could be rewritten to accommodate a hierarchy,
|
||||
but this would require fairly drastic changes. Even if it were
|
||||
rewritten, the existing swap subsystem uses the block I/O layer which
|
||||
assumes a swap device is fixed size and any page in it is linearly
|
||||
|
Loading…
Reference in New Issue
Block a user