mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-12-28 16:56:26 +00:00
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
|
||||
userspace's perspective, do not contain a deadlock. In such a mixed fencing
|
||||
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
|
||||
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
|
||||
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
|
||||
after their transfer completion callback has run for the descriptor.
|
||||
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
|
||||
|
||||
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
|
||||
initialization to pause until a test run has completed, while reading
|
||||
/sys/module/dmatest/parameters/wait waits for any running test to complete
|
||||
|
@ -4,7 +4,7 @@ High Speed Synchronous Serial Interface (HSI)
|
||||
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
|
||||
and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and
|
||||
implemented by multiple vendors since then.
|
||||
@ -52,7 +52,7 @@ hsi-char Device
|
||||
------------------
|
||||
|
||||
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
|
||||
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()
|
||||
|
||||
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
|
||||
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)
|
||||
|
||||
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::
|
||||
|
||||
|
@ -65,7 +65,7 @@ There are three groups of locks for managing the device:
|
||||
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.
|
||||
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'
|
||||
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
|
||||
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
|
||||
worry about the order. MD superblock has a field pointed to the valid meta data
|
||||
of log head.
|
||||
|
@ -28,7 +28,7 @@ Currently, it consists of:
|
||||
takes parameters at initialization that will dictate how the simulation
|
||||
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.
|
||||
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.
|
||||
|
@ -24,7 +24,7 @@ unless this is fixed in the HW platform.
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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()`,
|
||||
and unlocking the state after the call.
|
||||
|
||||
|
@ -3,7 +3,7 @@
|
||||
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.
|
||||
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
|
||||
|
@ -150,7 +150,7 @@ LLC
|
||||
|
||||
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
|
||||
currently two modules : nop (raw transfert) and shdlc.
|
||||
currently two modules : nop (raw transfer) and shdlc.
|
||||
A new llc must implement the following functions::
|
||||
|
||||
struct nfc_llc_ops {
|
||||
|
@ -82,7 +82,7 @@ LABEL:
|
||||
Metadata stored on a DIMM device that partitions and identifies
|
||||
(persistently names) capacity allocated to different PMEM namespaces. It
|
||||
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
|
||||
if present, but partition support is deprecated going forward.
|
||||
|
||||
|
@ -83,7 +83,7 @@ passed in.
|
||||
6. Freeze
|
||||
---------
|
||||
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
|
||||
----------
|
||||
|
@ -882,7 +882,7 @@ hardware and shall be put into different subsystems:
|
||||
|
||||
Depending on the exact HW register design, some functions exposed by the
|
||||
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
|
||||
e.g. GPIO direction is determined by a register in the pin controller HW
|
||||
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
|
||||
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
|
||||
the underlying device specific functionality.
|
||||
|
@ -24,7 +24,7 @@ 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
|
||||
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.
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
values. This effect can be better visualized using a Perf timechart.
|
||||
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
|
||||
|
||||
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
|
||||
rule of thumb, anything above 2.02a should work reliably well.
|
||||
|
||||
|
@ -48,7 +48,7 @@ kernel boot parameter::
|
||||
"earlyprintk=xdbc"
|
||||
|
||||
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.
|
||||
|
||||
Current design doesn't support DbC runtime suspend/resume. As
|
||||
|
Loading…
Reference in New Issue
Block a user