Documentation: driver-api: correct spelling
Correct spelling problems for Documentation/driver-api/ as reported by codespell. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-media@vger.kernel.org Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: nvdimm@lists.linux.dev Cc: Vinod Koul <vkoul@kernel.org> Cc: dmaengine@vger.kernel.org Cc: linux-raid@vger.kernel.org Cc: linux-usb@vger.kernel.org Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Song Liu <song@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20230129231053.20863-3-rdunlap@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
parent
dbeb56fe80
commit
7852fe3a09
|
@ -264,7 +264,7 @@ through memory management dependencies which userspace is unaware of, which
|
||||||
randomly hangs workloads until the timeout kicks in. Workloads, which from
|
randomly hangs workloads until the timeout kicks in. Workloads, which from
|
||||||
userspace's perspective, do not contain a deadlock. In such a mixed fencing
|
userspace's perspective, do not contain a deadlock. In such a mixed fencing
|
||||||
architecture there is no single entity with knowledge of all dependencies.
|
architecture there is no single entity with knowledge of all dependencies.
|
||||||
Thefore preventing such deadlocks from within the kernel is not possible.
|
Therefore preventing such deadlocks from within the kernel is not possible.
|
||||||
|
|
||||||
The only solution to avoid dependencies loops is by not allowing indefinite
|
The only solution to avoid dependencies loops is by not allowing indefinite
|
||||||
fences in the kernel. This means:
|
fences in the kernel. This means:
|
||||||
|
|
|
@ -175,7 +175,7 @@ The details of these operations are:
|
||||||
driver can ask for the pointer, maximum size and the currently used size of
|
driver can ask for the pointer, maximum size and the currently used size of
|
||||||
the metadata and can directly update or read it.
|
the metadata and can directly update or read it.
|
||||||
|
|
||||||
Becasue the DMA driver manages the memory area containing the metadata,
|
Because the DMA driver manages the memory area containing the metadata,
|
||||||
clients must make sure that they do not try to access or get the pointer
|
clients must make sure that they do not try to access or get the pointer
|
||||||
after their transfer completion callback has run for the descriptor.
|
after their transfer completion callback has run for the descriptor.
|
||||||
If no completion callback has been defined for the transfer, then the
|
If no completion callback has been defined for the transfer, then the
|
||||||
|
|
|
@ -89,7 +89,7 @@ The following command returns the state of the test. ::
|
||||||
|
|
||||||
% cat /sys/module/dmatest/parameters/run
|
% cat /sys/module/dmatest/parameters/run
|
||||||
|
|
||||||
To wait for test completion userpace can poll 'run' until it is false, or use
|
To wait for test completion userspace can poll 'run' until it is false, or use
|
||||||
the wait parameter. Specifying 'wait=1' when loading the module causes module
|
the wait parameter. Specifying 'wait=1' when loading the module causes module
|
||||||
initialization to pause until a test run has completed, while reading
|
initialization to pause until a test run has completed, while reading
|
||||||
/sys/module/dmatest/parameters/wait waits for any running test to complete
|
/sys/module/dmatest/parameters/wait waits for any running test to complete
|
||||||
|
|
|
@ -4,7 +4,7 @@ High Speed Synchronous Serial Interface (HSI)
|
||||||
Introduction
|
Introduction
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol,
|
High Speed Synchronous Interface (HSI) is a full duplex, low latency protocol,
|
||||||
that is optimized for die-level interconnect between an Application Processor
|
that is optimized for die-level interconnect between an Application Processor
|
||||||
and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and
|
and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and
|
||||||
implemented by multiple vendors since then.
|
implemented by multiple vendors since then.
|
||||||
|
@ -52,7 +52,7 @@ hsi-char Device
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
Each port automatically registers a generic client driver called hsi_char,
|
Each port automatically registers a generic client driver called hsi_char,
|
||||||
which provides a charecter device for userspace representing the HSI port.
|
which provides a character device for userspace representing the HSI port.
|
||||||
It can be used to communicate via HSI from userspace. Userspace may
|
It can be used to communicate via HSI from userspace. Userspace may
|
||||||
configure the hsi_char device using the following ioctl commands:
|
configure the hsi_char device using the following ioctl commands:
|
||||||
|
|
||||||
|
|
|
@ -44,7 +44,7 @@ This _wc variant returns a write-combining map to the page and may only be
|
||||||
used with mappings created by io_mapping_create_wc()
|
used with mappings created by io_mapping_create_wc()
|
||||||
|
|
||||||
Temporary mappings are only valid in the context of the caller. The mapping
|
Temporary mappings are only valid in the context of the caller. The mapping
|
||||||
is not guaranteed to be globaly visible.
|
is not guaranteed to be globally visible.
|
||||||
|
|
||||||
io_mapping_map_local_wc() has a side effect on X86 32bit as it disables
|
io_mapping_map_local_wc() has a side effect on X86 32bit as it disables
|
||||||
migration to make the mapping code work. No caller can rely on this side
|
migration to make the mapping code work. No caller can rely on this side
|
||||||
|
@ -78,7 +78,7 @@ variant, although this may be significantly slower::
|
||||||
unsigned long offset)
|
unsigned long offset)
|
||||||
|
|
||||||
This works like io_mapping_map_atomic/local_wc() except it has no side
|
This works like io_mapping_map_atomic/local_wc() except it has no side
|
||||||
effects and the pointer is globaly visible.
|
effects and the pointer is globally visible.
|
||||||
|
|
||||||
The mappings are released with::
|
The mappings are released with::
|
||||||
|
|
||||||
|
|
|
@ -65,7 +65,7 @@ There are three groups of locks for managing the device:
|
||||||
2.3 new-device management
|
2.3 new-device management
|
||||||
-------------------------
|
-------------------------
|
||||||
|
|
||||||
A single lock: "no-new-dev" is used to co-ordinate the addition of
|
A single lock: "no-new-dev" is used to coordinate the addition of
|
||||||
new devices - this must be synchronized across the array.
|
new devices - this must be synchronized across the array.
|
||||||
Normally all nodes hold a concurrent-read lock on this device.
|
Normally all nodes hold a concurrent-read lock on this device.
|
||||||
|
|
||||||
|
|
|
@ -81,7 +81,7 @@ The write-through and write-back cache use the same disk format. The cache disk
|
||||||
is organized as a simple write log. The log consists of 'meta data' and 'data'
|
is organized as a simple write log. The log consists of 'meta data' and 'data'
|
||||||
pairs. The meta data describes the data. It also includes checksum and sequence
|
pairs. The meta data describes the data. It also includes checksum and sequence
|
||||||
ID for recovery identification. Data can be IO data and parity data. Data is
|
ID for recovery identification. Data can be IO data and parity data. Data is
|
||||||
checksumed too. The checksum is stored in the meta data ahead of the data. The
|
checksummed too. The checksum is stored in the meta data ahead of the data. The
|
||||||
checksum is an optimization because MD can write meta and data freely without
|
checksum is an optimization because MD can write meta and data freely without
|
||||||
worry about the order. MD superblock has a field pointed to the valid meta data
|
worry about the order. MD superblock has a field pointed to the valid meta data
|
||||||
of log head.
|
of log head.
|
||||||
|
|
|
@ -28,7 +28,7 @@ Currently, it consists of:
|
||||||
takes parameters at initialization that will dictate how the simulation
|
takes parameters at initialization that will dictate how the simulation
|
||||||
behaves.
|
behaves.
|
||||||
|
|
||||||
- Code reponsible for encoding a valid MPEG Transport Stream, which is then
|
- Code responsible for encoding a valid MPEG Transport Stream, which is then
|
||||||
passed to the bridge driver. This fake stream contains some hardcoded content.
|
passed to the bridge driver. This fake stream contains some hardcoded content.
|
||||||
For now, we have a single, audio-only channel containing a single MPEG
|
For now, we have a single, audio-only channel containing a single MPEG
|
||||||
Elementary Stream, which in turn contains a SMPTE 302m encoded sine-wave.
|
Elementary Stream, which in turn contains a SMPTE 302m encoded sine-wave.
|
||||||
|
|
|
@ -24,7 +24,7 @@ unless this is fixed in the HW platform.
|
||||||
|
|
||||||
The demux kABI only controls front-ends regarding to their connections with
|
The demux kABI only controls front-ends regarding to their connections with
|
||||||
demuxes; the kABI used to set the other front-end parameters, such as
|
demuxes; the kABI used to set the other front-end parameters, such as
|
||||||
tuning, are devined via the Digital TV Frontend kABI.
|
tuning, are defined via the Digital TV Frontend kABI.
|
||||||
|
|
||||||
The functions that implement the abstract interface demux should be defined
|
The functions that implement the abstract interface demux should be defined
|
||||||
static or module private and registered to the Demux core for external
|
static or module private and registered to the Demux core for external
|
||||||
|
|
|
@ -321,7 +321,7 @@ response to video node operations. This hides the complexity of the underlying
|
||||||
hardware from applications. For complex devices, finer-grained control of the
|
hardware from applications. For complex devices, finer-grained control of the
|
||||||
device than what the video nodes offer may be required. In those cases, bridge
|
device than what the video nodes offer may be required. In those cases, bridge
|
||||||
drivers that implement :ref:`the media controller API <media_controller>` may
|
drivers that implement :ref:`the media controller API <media_controller>` may
|
||||||
opt for making the subdevice operations directly accessible from userpace.
|
opt for making the subdevice operations directly accessible from userspace.
|
||||||
|
|
||||||
Device nodes named ``v4l-subdev``\ *X* can be created in ``/dev`` to access
|
Device nodes named ``v4l-subdev``\ *X* can be created in ``/dev`` to access
|
||||||
sub-devices directly. If a sub-device supports direct userspace configuration
|
sub-devices directly. If a sub-device supports direct userspace configuration
|
||||||
|
@ -574,7 +574,7 @@ issues with subdevice drivers that let the V4L2 core manage the active state,
|
||||||
as they expect to receive the appropriate state as a parameter. To help the
|
as they expect to receive the appropriate state as a parameter. To help the
|
||||||
conversion of subdevice drivers to a managed active state without having to
|
conversion of subdevice drivers to a managed active state without having to
|
||||||
convert all callers at the same time, an additional wrapper layer has been
|
convert all callers at the same time, an additional wrapper layer has been
|
||||||
added to v4l2_subdev_call(), which handles the NULL case by geting and locking
|
added to v4l2_subdev_call(), which handles the NULL case by getting and locking
|
||||||
the callee's active state with :c:func:`v4l2_subdev_lock_and_get_active_state()`,
|
the callee's active state with :c:func:`v4l2_subdev_lock_and_get_active_state()`,
|
||||||
and unlocking the state after the call.
|
and unlocking the state after the call.
|
||||||
|
|
||||||
|
|
|
@ -3,7 +3,7 @@
|
||||||
MEI NFC
|
MEI NFC
|
||||||
-------
|
-------
|
||||||
|
|
||||||
Some Intel 8 and 9 Serieses chipsets supports NFC devices connected behind
|
Some Intel 8 and 9 Series chipsets support NFC devices connected behind
|
||||||
the Intel Management Engine controller.
|
the Intel Management Engine controller.
|
||||||
MEI client bus exposes the NFC chips as NFC phy devices and enables
|
MEI client bus exposes the NFC chips as NFC phy devices and enables
|
||||||
binding with Microread and NXP PN544 NFC device driver from the Linux NFC
|
binding with Microread and NXP PN544 NFC device driver from the Linux NFC
|
||||||
|
|
|
@ -150,7 +150,7 @@ LLC
|
||||||
|
|
||||||
Communication between the CPU and the chip often requires some link layer
|
Communication between the CPU and the chip often requires some link layer
|
||||||
protocol. Those are isolated as modules managed by the HCI layer. There are
|
protocol. Those are isolated as modules managed by the HCI layer. There are
|
||||||
currently two modules : nop (raw transfert) and shdlc.
|
currently two modules : nop (raw transfer) and shdlc.
|
||||||
A new llc must implement the following functions::
|
A new llc must implement the following functions::
|
||||||
|
|
||||||
struct nfc_llc_ops {
|
struct nfc_llc_ops {
|
||||||
|
|
|
@ -82,7 +82,7 @@ LABEL:
|
||||||
Metadata stored on a DIMM device that partitions and identifies
|
Metadata stored on a DIMM device that partitions and identifies
|
||||||
(persistently names) capacity allocated to different PMEM namespaces. It
|
(persistently names) capacity allocated to different PMEM namespaces. It
|
||||||
also indicates whether an address abstraction like a BTT is applied to
|
also indicates whether an address abstraction like a BTT is applied to
|
||||||
the namepsace. Note that traditional partition tables, GPT/MBR, are
|
the namespace. Note that traditional partition tables, GPT/MBR, are
|
||||||
layered on top of a PMEM namespace, or an address abstraction like BTT
|
layered on top of a PMEM namespace, or an address abstraction like BTT
|
||||||
if present, but partition support is deprecated going forward.
|
if present, but partition support is deprecated going forward.
|
||||||
|
|
||||||
|
|
|
@ -83,7 +83,7 @@ passed in.
|
||||||
6. Freeze
|
6. Freeze
|
||||||
---------
|
---------
|
||||||
The freeze operation does not require any keys. The security config can be
|
The freeze operation does not require any keys. The security config can be
|
||||||
frozen by a user with root privelege.
|
frozen by a user with root privilege.
|
||||||
|
|
||||||
7. Disable
|
7. Disable
|
||||||
----------
|
----------
|
||||||
|
|
|
@ -882,7 +882,7 @@ hardware and shall be put into different subsystems:
|
||||||
|
|
||||||
Depending on the exact HW register design, some functions exposed by the
|
Depending on the exact HW register design, some functions exposed by the
|
||||||
GPIO subsystem may call into the pinctrl subsystem in order to
|
GPIO subsystem may call into the pinctrl subsystem in order to
|
||||||
co-ordinate register settings across HW modules. In particular, this may
|
coordinate register settings across HW modules. In particular, this may
|
||||||
be needed for HW with separate GPIO and pin controller HW modules, where
|
be needed for HW with separate GPIO and pin controller HW modules, where
|
||||||
e.g. GPIO direction is determined by a register in the pin controller HW
|
e.g. GPIO direction is determined by a register in the pin controller HW
|
||||||
module rather than the GPIO HW module.
|
module rather than the GPIO HW module.
|
||||||
|
|
|
@ -20,7 +20,7 @@ Overview of the ``pldmfw`` library
|
||||||
|
|
||||||
The ``pldmfw`` library is intended to be used by device drivers for
|
The ``pldmfw`` library is intended to be used by device drivers for
|
||||||
implementing device flash update based on firmware files following the PLDM
|
implementing device flash update based on firmware files following the PLDM
|
||||||
firwmare file format.
|
firmware file format.
|
||||||
|
|
||||||
It is implemented using an ops table that allows device drivers to provide
|
It is implemented using an ops table that allows device drivers to provide
|
||||||
the underlying device specific functionality.
|
the underlying device specific functionality.
|
||||||
|
|
|
@ -24,7 +24,7 @@ console support.
|
||||||
Console Support
|
Console Support
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
The serial core provides a few helper functions. This includes identifing
|
The serial core provides a few helper functions. This includes identifying
|
||||||
the correct port structure (via uart_get_console()) and decoding command line
|
the correct port structure (via uart_get_console()) and decoding command line
|
||||||
arguments (uart_parse_options()).
|
arguments (uart_parse_options()).
|
||||||
|
|
||||||
|
|
|
@ -76,7 +76,7 @@ after the frame structure and before the payload. The payload is followed by
|
||||||
its own CRC (over all payload bytes). If the payload is not present (i.e.
|
its own CRC (over all payload bytes). If the payload is not present (i.e.
|
||||||
the frame has ``LEN=0``), the CRC of the payload is still present and will
|
the frame has ``LEN=0``), the CRC of the payload is still present and will
|
||||||
evaluate to ``0xffff``. The |LEN| field does not include any of the CRCs, it
|
evaluate to ``0xffff``. The |LEN| field does not include any of the CRCs, it
|
||||||
equals the number of bytes inbetween the CRC of the frame and the CRC of the
|
equals the number of bytes between the CRC of the frame and the CRC of the
|
||||||
payload.
|
payload.
|
||||||
|
|
||||||
Additionally, the following fixed two-byte sequences are used:
|
Additionally, the following fixed two-byte sequences are used:
|
||||||
|
|
|
@ -85,7 +85,7 @@ migrated, unless the CPU is taken offline. In this case, threads
|
||||||
belong to the offlined CPUs will be terminated immediately.
|
belong to the offlined CPUs will be terminated immediately.
|
||||||
|
|
||||||
Running as SCHED_FIFO and relatively high priority, also allows such
|
Running as SCHED_FIFO and relatively high priority, also allows such
|
||||||
scheme to work for both preemptable and non-preemptable kernels.
|
scheme to work for both preemptible and non-preemptible kernels.
|
||||||
Alignment of idle time around jiffies ensures scalability for HZ
|
Alignment of idle time around jiffies ensures scalability for HZ
|
||||||
values. This effect can be better visualized using a Perf timechart.
|
values. This effect can be better visualized using a Perf timechart.
|
||||||
The following diagram shows the behavior of kernel thread
|
The following diagram shows the behavior of kernel thread
|
||||||
|
|
|
@ -18,7 +18,7 @@ controller which can be configured in one of 4 ways:
|
||||||
4. Hub configuration
|
4. Hub configuration
|
||||||
|
|
||||||
Linux currently supports several versions of this controller. In all
|
Linux currently supports several versions of this controller. In all
|
||||||
likelyhood, the version in your SoC is already supported. At the time
|
likelihood, the version in your SoC is already supported. At the time
|
||||||
of this writing, known tested versions range from 2.02a to 3.10a. As a
|
of this writing, known tested versions range from 2.02a to 3.10a. As a
|
||||||
rule of thumb, anything above 2.02a should work reliably well.
|
rule of thumb, anything above 2.02a should work reliably well.
|
||||||
|
|
||||||
|
|
|
@ -48,7 +48,7 @@ kernel boot parameter::
|
||||||
"earlyprintk=xdbc"
|
"earlyprintk=xdbc"
|
||||||
|
|
||||||
If there are multiple xHCI controllers in your system, you can
|
If there are multiple xHCI controllers in your system, you can
|
||||||
append a host contoller index to this kernel parameter. This
|
append a host controller index to this kernel parameter. This
|
||||||
index starts from 0.
|
index starts from 0.
|
||||||
|
|
||||||
Current design doesn't support DbC runtime suspend/resume. As
|
Current design doesn't support DbC runtime suspend/resume. As
|
||||||
|
|
Loading…
Reference in New Issue