docs: get rid of :c:type explicit declarations for structs

The :c:type:`foo` only works properly with structs before
Sphinx 3.x.

On Sphinx 3.x, structs should now be declared using the
.. c:struct, and referenced via :c:struct tag.

As we now have the automarkup.py macro, that automatically
convert:
	struct foo

into cross-references, let's get rid of that, solving
several warnings when building docs with Sphinx 3.x.

Reviewed-by: André Almeida <andrealmeid@collabora.com> # blk-mq.rst
Reviewed-by: Takashi Iwai <tiwai@suse.de> # sound
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This commit is contained in:
Mauro Carvalho Chehab 2020-09-25 12:01:25 +02:00
parent abc59fd4a5
commit 9303c9d5e9
29 changed files with 86 additions and 86 deletions

View File

@ -63,10 +63,10 @@ Software staging queues
~~~~~~~~~~~~~~~~~~~~~~~
The block IO subsystem adds requests in the software staging queues
(represented by struct :c:type:`blk_mq_ctx`) in case that they weren't sent
(represented by struct blk_mq_ctx) in case that they weren't sent
directly to the driver. A request is one or more BIOs. They arrived at the
block layer through the data structure struct :c:type:`bio`. The block layer
will then build a new structure from it, the struct :c:type:`request` that will
block layer through the data structure struct bio. The block layer
will then build a new structure from it, the struct request that will
be used to communicate with the device driver. Each queue has its own lock and
the number of queues is defined by a per-CPU or per-node basis.
@ -102,7 +102,7 @@ hardware queue will be drained in sequence according to their mapping.
Hardware dispatch queues
~~~~~~~~~~~~~~~~~~~~~~~~
The hardware queue (represented by struct :c:type:`blk_mq_hw_ctx`) is a struct
The hardware queue (represented by struct blk_mq_hw_ctx) is a struct
used by device drivers to map the device submission queues (or device DMA ring
buffer), and are the last step of the block layer submission code before the
low level device driver taking ownership of the request. To run this queue, the

View File

@ -52,7 +52,7 @@ Constraints and notes
Design
======
We add a :c:type:`struct bio_crypt_ctx` to :c:type:`struct bio` that can
We add a struct bio_crypt_ctx to struct bio that can
represent an encryption context, because we need to be able to pass this
encryption context from the upper layers (like the fs layer) to the
device driver to act upon.
@ -85,7 +85,7 @@ blk-mq changes, other block layer changes and blk-crypto-fallback
=================================================================
We add a pointer to a ``bi_crypt_context`` and ``keyslot`` to
:c:type:`struct request`. These will be referred to as the ``crypto fields``
struct request. These will be referred to as the ``crypto fields``
for the request. This ``keyslot`` is the keyslot into which the
``bi_crypt_context`` has been programmed in the KSM of the ``request_queue``
that this request is being sent to.
@ -118,7 +118,7 @@ of the algorithm being used adheres to spec and functions correctly).
If a ``request queue``'s inline encryption hardware claimed to support the
encryption context specified with a bio, then it will not be handled by the
``blk-crypto-fallback``. We will eventually reach a point in blk-mq when a
:c:type:`struct request` needs to be allocated for that bio. At that point,
struct request needs to be allocated for that bio. At that point,
blk-mq tries to program the encryption context into the ``request_queue``'s
keyslot_manager, and obtain a keyslot, which it stores in its newly added
``keyslot`` field. This keyslot is released when the request is completed.
@ -188,7 +188,7 @@ keyslots supported by the hardware.
The device driver also needs to tell the KSM how to actually manipulate the
IE hardware in the device to do things like programming the crypto key into
the IE hardware into a particular keyslot. All this is achieved through the
:c:type:`struct blk_ksm_ll_ops` field in the KSM that the device driver
struct blk_ksm_ll_ops field in the KSM that the device driver
must fill up after initing the ``blk_keyslot_manager``.
The KSM also handles runtime power management for the device when applicable

View File

@ -4,8 +4,8 @@ FPGA Bridge
API to implement a new FPGA bridge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* struct :c:type:`fpga_bridge` — The FPGA Bridge structure
* struct :c:type:`fpga_bridge_ops` — Low level Bridge driver ops
* struct fpga_bridge — The FPGA Bridge structure
* struct fpga_bridge_ops — Low level Bridge driver ops
* devm_fpga_bridge_create() — Allocate and init a bridge struct
* fpga_bridge_register() — Register a bridge
* fpga_bridge_unregister() — Unregister a bridge

View File

@ -102,8 +102,8 @@ API for implementing a new FPGA Manager driver
----------------------------------------------
* ``fpga_mgr_states`` — Values for :c:member:`fpga_manager->state`.
* struct :c:type:`fpga_manager` — the FPGA manager struct
* struct :c:type:`fpga_manager_ops` — Low level FPGA manager driver ops
* struct fpga_manager — the FPGA manager struct
* struct fpga_manager_ops — Low level FPGA manager driver ops
* devm_fpga_mgr_create() — Allocate and init a manager struct
* fpga_mgr_register() — Register an FPGA manager
* fpga_mgr_unregister() — Unregister an FPGA manager

View File

@ -45,7 +45,7 @@ An example of usage can be seen in the probe function of [#f2]_.
API to add a new FPGA region
----------------------------
* struct :c:type:`fpga_region` — The FPGA region struct
* struct fpga_region — The FPGA region struct
* devm_fpga_region_create() — Allocate and init a region struct
* fpga_region_register() — Register an FPGA region
* fpga_region_unregister() — Unregister an FPGA region

View File

@ -2,7 +2,7 @@
Buffers
=======
* struct :c:type:`iio_buffer` — general buffer structure
* struct iio_buffer — general buffer structure
* :c:func:`iio_validate_scan_mask_onehot` — Validates that exactly one channel
is selected
* :c:func:`iio_buffer_get` — Grab a reference to the buffer

View File

@ -10,7 +10,7 @@ applications manipulating sensors. The implementation can be found under
Industrial I/O Devices
----------------------
* struct :c:type:`iio_dev` - industrial I/O device
* struct iio_dev - industrial I/O device
* iio_device_alloc() - allocate an :c:type:`iio_dev` from a driver
* iio_device_free() - free an :c:type:`iio_dev` from a driver
* iio_device_register() - register a device with the IIO subsystem
@ -66,7 +66,7 @@ Common attributes are:
IIO device channels
===================
struct :c:type:`iio_chan_spec` - specification of a single channel
struct iio_chan_spec - specification of a single channel
An IIO device channel is a representation of a data channel. An IIO device can
have one or multiple channels. For example:
@ -77,7 +77,7 @@ have one or multiple channels. For example:
* an accelerometer can have up to 3 channels representing acceleration on X, Y
and Z axes.
An IIO channel is described by the struct :c:type:`iio_chan_spec`.
An IIO channel is described by the struct iio_chan_spec.
A thermometer driver for the temperature sensor in the example above would
have to describe its channel as follows::

View File

@ -8,7 +8,7 @@ software buffer for data. The implementation can be found under
:file:`drivers/iio/buffer/hw-consumer.c`
* struct :c:type:`iio_hw_consumer` — Hardware consumer structure
* struct iio_hw_consumer — Hardware consumer structure
* :c:func:`iio_hw_consumer_alloc` — Allocate IIO hardware consumer
* :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer
* :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer

View File

@ -10,7 +10,7 @@ IIO triggered buffer setup
* :c:func:`iio_triggered_buffer_setup` — Setup triggered buffer and pollfunc
* :c:func:`iio_triggered_buffer_cleanup` — Free resources allocated by
:c:func:`iio_triggered_buffer_setup`
* struct :c:type:`iio_buffer_setup_ops` — buffer setup related callbacks
* struct iio_buffer_setup_ops — buffer setup related callbacks
A typical triggered buffer setup looks like this::

View File

@ -2,7 +2,7 @@
Triggers
========
* struct :c:type:`iio_trigger` — industrial I/O trigger device
* struct iio_trigger — industrial I/O trigger device
* :c:func:`devm_iio_trigger_alloc` — Resource-managed iio_trigger_alloc
* :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register
iio_trigger_unregister
@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver::
IIO trigger ops
===============
* struct :c:type:`iio_trigger_ops` — operations structure for an iio_trigger.
* struct iio_trigger_ops — operations structure for an iio_trigger.
Notice that a trigger has a set of operations attached:

View File

@ -125,7 +125,7 @@ responsible for tuning the device. It supports multiple algorithms to
detect a channel, as defined at enum :c:func:`dvbfe_algo`.
The algorithm to be used is obtained via ``.get_frontend_algo``. If the driver
doesn't fill its field at struct :c:type:`dvb_frontend_ops`, it will default to
doesn't fill its field at struct dvb_frontend_ops, it will default to
``DVBFE_ALGO_SW``, meaning that the dvb-core will do a zigzag when tuning,
e. g. it will try first to use the specified center frequency ``f``,
then, it will do ``f`` + |delta|, ``f`` - |delta|, ``f`` + 2 x |delta|,
@ -140,7 +140,7 @@ define a ``.get_frontend_algo`` function that would return ``DVBFE_ALGO_HW``.
a third type (``DVBFE_ALGO_CUSTOM``), in order to allow the driver to
define its own hardware-assisted algorithm. Very few hardware need to
use it nowadays. Using ``DVBFE_ALGO_CUSTOM`` require to provide other
function callbacks at struct :c:type:`dvb_frontend_ops`.
function callbacks at struct dvb_frontend_ops.
Attaching frontend driver to the bridge driver
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

View File

@ -36,7 +36,7 @@ pad to a sink pad.
Media device
^^^^^^^^^^^^
A media device is represented by a struct :c:type:`media_device`
A media device is represented by a struct media_device
instance, defined in ``include/media/media-device.h``.
Allocation of the structure is handled by the media device driver, usually by
embedding the :c:type:`media_device` instance in a larger driver-specific
@ -49,7 +49,7 @@ and unregistered by calling :c:func:`media_device_unregister()`.
Entities
^^^^^^^^
Entities are represented by a struct :c:type:`media_entity`
Entities are represented by a struct media_entity
instance, defined in ``include/media/media-entity.h``. The structure is usually
embedded into a higher-level structure, such as
:c:type:`v4l2_subdev` or :c:type:`video_device`
@ -67,10 +67,10 @@ Interfaces
^^^^^^^^^^
Interfaces are represented by a
struct :c:type:`media_interface` instance, defined in
struct media_interface instance, defined in
``include/media/media-entity.h``. Currently, only one type of interface is
defined: a device node. Such interfaces are represented by a
struct :c:type:`media_intf_devnode`.
struct media_intf_devnode.
Drivers initialize and create device node interfaces by calling
:c:func:`media_devnode_create()`
@ -79,7 +79,7 @@ and remove them by calling:
Pads
^^^^
Pads are represented by a struct :c:type:`media_pad` instance,
Pads are represented by a struct media_pad instance,
defined in ``include/media/media-entity.h``. Each entity stores its pads in
a pads array managed by the entity driver. Drivers usually embed the array in
a driver-specific structure.
@ -87,8 +87,8 @@ a driver-specific structure.
Pads are identified by their entity and their 0-based index in the pads
array.
Both information are stored in the struct :c:type:`media_pad`,
making the struct :c:type:`media_pad` pointer the canonical way
Both information are stored in the struct media_pad,
making the struct media_pad pointer the canonical way
to store and pass link references.
Pads have flags that describe the pad capabilities and state.
@ -104,7 +104,7 @@ Pads have flags that describe the pad capabilities and state.
Links
^^^^^
Links are represented by a struct :c:type:`media_link` instance,
Links are represented by a struct media_link instance,
defined in ``include/media/media-entity.h``. There are two types of links:
**1. pad to pad links**:
@ -187,7 +187,7 @@ Use count and power handling
Due to the wide differences between drivers regarding power management
needs, the media controller does not implement power management. However,
the struct :c:type:`media_entity` includes a ``use_count``
the struct media_entity includes a ``use_count``
field that media drivers
can use to track the number of users of every entity for power management
needs.
@ -213,11 +213,11 @@ prevent link states from being modified during streaming by calling
The function will mark all entities connected to the given entity through
enabled links, either directly or indirectly, as streaming.
The struct :c:type:`media_pipeline` instance pointed to by
The struct media_pipeline instance pointed to by
the pipe argument will be stored in every entity in the pipeline.
Drivers should embed the struct :c:type:`media_pipeline`
Drivers should embed the struct media_pipeline
in higher-level pipeline structures and can then access the
pipeline through the struct :c:type:`media_entity`
pipeline through the struct media_entity
pipe field.
Calls to :c:func:`media_pipeline_start()` can be nested.

View File

@ -27,7 +27,7 @@ V4L2 specification with respect to controls in a central place. And to make
life as easy as possible for the driver developer.
Note that the control framework relies on the presence of a struct
:c:type:`v4l2_device` for V4L2 drivers and struct :c:type:`v4l2_subdev` for
:c:type:`v4l2_device` for V4L2 drivers and struct v4l2_subdev for
sub-device drivers.

View File

@ -67,7 +67,7 @@ You should also set these fields of :c:type:`video_device`:
file operation is called this lock will be taken by the core and released
afterwards. See the next section for more details.
- :c:type:`video_device`->queue: a pointer to the struct :c:type:`vb2_queue`
- :c:type:`video_device`->queue: a pointer to the struct vb2_queue
associated with this device node.
If queue is not ``NULL``, and queue->lock is not ``NULL``, then queue->lock
is used for the queuing ioctls (``VIDIOC_REQBUFS``, ``CREATE_BUFS``,
@ -81,7 +81,7 @@ You should also set these fields of :c:type:`video_device`:
- :c:type:`video_device`->prio: keeps track of the priorities. Used to
implement ``VIDIOC_G_PRIORITY`` and ``VIDIOC_S_PRIORITY``.
If left to ``NULL``, then it will use the struct :c:type:`v4l2_prio_state`
If left to ``NULL``, then it will use the struct v4l2_prio_state
in :c:type:`v4l2_device`. If you want to have a separate priority state per
(group of) device node(s), then you can point it to your own struct
:c:type:`v4l2_prio_state`.
@ -95,7 +95,7 @@ You should also set these fields of :c:type:`video_device`:
but it is used by both a raw video PCI device (cx8800) and a MPEG PCI device
(cx8802). Since the :c:type:`v4l2_device` cannot be associated with two PCI
devices at the same time it is setup without a parent device. But when the
struct :c:type:`video_device` is initialized you **do** know which parent
struct video_device is initialized you **do** know which parent
PCI device to use and so you set ``dev_device`` to the correct PCI device.
If you use :c:type:`v4l2_ioctl_ops`, then you should set
@ -138,7 +138,7 @@ ioctls and locking
------------------
The V4L core provides optional locking services. The main service is the
lock field in struct :c:type:`video_device`, which is a pointer to a mutex.
lock field in struct video_device, which is a pointer to a mutex.
If you set this pointer, then that will be used by unlocked_ioctl to
serialize all ioctls.

View File

@ -3,7 +3,7 @@
V4L2 device instance
--------------------
Each device instance is represented by a struct :c:type:`v4l2_device`.
Each device instance is represented by a struct v4l2_device.
Very simple devices can just allocate this struct, but most of the time you
would embed this struct inside a larger struct.
@ -18,9 +18,9 @@ dev->driver_data field is ``NULL``, it will be linked to
Drivers that want integration with the media device framework need to set
dev->driver_data manually to point to the driver-specific device structure
that embed the struct :c:type:`v4l2_device` instance. This is achieved by a
that embed the struct v4l2_device instance. This is achieved by a
``dev_set_drvdata()`` call before registering the V4L2 device instance.
They must also set the struct :c:type:`v4l2_device` mdev field to point to a
They must also set the struct v4l2_device mdev field to point to a
properly initialized and registered :c:type:`media_device` instance.
If :c:type:`v4l2_dev <v4l2_device>`\ ->name is empty then it will be set to a

View File

@ -44,18 +44,18 @@ such objects.
So to summarize:
- struct :c:type:`v4l2_fh` has two lists: one of the ``subscribed`` events,
- struct v4l2_fh has two lists: one of the ``subscribed`` events,
and one of the ``available`` events.
- struct :c:type:`v4l2_subscribed_event` has a ringbuffer of raised
- struct v4l2_subscribed_event has a ringbuffer of raised
(pending) events of that particular type.
- If struct :c:type:`v4l2_subscribed_event` is associated with a specific
- If struct v4l2_subscribed_event is associated with a specific
object, then that object will have an internal list of
struct :c:type:`v4l2_subscribed_event` so it knows who subscribed an
struct v4l2_subscribed_event so it knows who subscribed an
event to that object.
Furthermore, the internal struct :c:type:`v4l2_subscribed_event` has
Furthermore, the internal struct v4l2_subscribed_event has
``merge()`` and ``replace()`` callbacks which drivers can set. These
callbacks are called when a new event is raised and there is no more room.

View File

@ -3,11 +3,11 @@
V4L2 File handlers
------------------
struct :c:type:`v4l2_fh` provides a way to easily keep file handle specific
struct v4l2_fh provides a way to easily keep file handle specific
data that is used by the V4L2 framework.
.. attention::
New drivers must use struct :c:type:`v4l2_fh`
New drivers must use struct v4l2_fh
since it is also used to implement priority handling
(:ref:`VIDIOC_G_PRIORITY`).
@ -16,11 +16,11 @@ whether a driver uses :c:type:`v4l2_fh` as its ``file->private_data`` pointer
by testing the ``V4L2_FL_USES_V4L2_FH`` bit in :c:type:`video_device`->flags.
This bit is set whenever :c:func:`v4l2_fh_init` is called.
struct :c:type:`v4l2_fh` is allocated as a part of the driver's own file handle
struct v4l2_fh is allocated as a part of the driver's own file handle
structure and ``file->private_data`` is set to it in the driver's ``open()``
function by the driver.
In many cases the struct :c:type:`v4l2_fh` will be embedded in a larger
In many cases the struct v4l2_fh will be embedded in a larger
structure. In that case you should call:
#) :c:func:`v4l2_fh_init` and :c:func:`v4l2_fh_add` in ``open()``
@ -102,18 +102,18 @@ Below is a short description of the :c:type:`v4l2_fh` functions used:
memory can be freed.
If struct :c:type:`v4l2_fh` is not embedded, then you can use these helper functions:
If struct v4l2_fh is not embedded, then you can use these helper functions:
:c:func:`v4l2_fh_open <v4l2_fh_open>`
(struct file \*filp)
- This allocates a struct :c:type:`v4l2_fh`, initializes it and adds it to
the struct :c:type:`video_device` associated with the file struct.
- This allocates a struct v4l2_fh, initializes it and adds it to
the struct video_device associated with the file struct.
:c:func:`v4l2_fh_release <v4l2_fh_release>`
(struct file \*filp)
- This deletes it from the struct :c:type:`video_device` associated with the
- This deletes it from the struct video_device associated with the
file struct, uninitialised the :c:type:`v4l2_fh` and frees it.
These two functions can be plugged into the v4l2_file_operation's ``open()``

View File

@ -110,7 +110,7 @@ pads:
err = media_entity_pads_init(&sd->entity, npads, pads);
The pads array must have been previously initialized. There is no need to
manually set the struct :c:type:`media_entity` function and name fields, but the
manually set the struct media_entity function and name fields, but the
revision field must be initialized if needed.
A reference to the entity will be automatically acquired/released when the

View File

@ -116,7 +116,7 @@ core, providing operations structures to the core. A notifier interface
allows error conditions to be reported to the core.
Registration should be triggered by explicit setup done by the platform,
supplying a struct :c:type:`regulator_init_data` for the regulator
supplying a struct regulator_init_data for the regulator
containing constraint and supply information.
Machine interface
@ -144,7 +144,7 @@ a given system, for example supporting higher supply voltages than the
consumers are rated for.
This is done at driver registration time` by providing a
struct :c:type:`regulation_constraints`.
struct regulation_constraints.
The constraints may also specify an initial configuration for the
regulator in the constraints, which is particularly useful for use with

View File

@ -47,7 +47,7 @@ called USB Request Block, or URB for short.
The URB structure
=================
Some of the fields in struct :c:type:`urb` are::
Some of the fields in struct urb are::
struct urb
{

View File

@ -176,9 +176,9 @@ Kernel Mode Gadget API
Gadget drivers declare themselves through a struct
:c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration
for a struct :c:type:`usb_gadget`. The response to a set_configuration usually
involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by
the gadget, and submitting one or more struct :c:type:`usb_request` buffers to
for a struct usb_gadget. The response to a set_configuration usually
involves enabling one or more of the struct usb_ep objects exposed by
the gadget, and submitting one or more struct usb_request buffers to
transfer data. Understand those four data types, and their operations,
and you will understand how this API works.
@ -339,8 +339,8 @@ multi-configuration devices (also more than one function, but not
necessarily sharing a given configuration). There is however an optional
framework which makes it easier to reuse and combine functions.
Devices using this framework provide a struct :c:type:`usb_composite_driver`,
which in turn provides one or more struct :c:type:`usb_configuration`
Devices using this framework provide a struct usb_composite_driver,
which in turn provides one or more struct usb_configuration
instances. Each such configuration includes at least one struct
:c:type:`usb_function`, which packages a user visible role such as "network
link" or "mass storage device". Management functions may also exist,

View File

@ -122,7 +122,7 @@ and their quirks, might have a MODULE_DEVICE_TABLE like this::
Most USB device drivers should pass these tables to the USB subsystem as
well as to the module management subsystem. Not all, though: some driver
frameworks connect using interfaces layered over USB, and so they won't
need such a struct :c:type:`usb_driver`.
need such a struct usb_driver.
Drivers that connect directly to the USB subsystem should be declared
something like this::

View File

@ -84,7 +84,7 @@ FS_IOC_ENABLE_VERITY
--------------------
The FS_IOC_ENABLE_VERITY ioctl enables fs-verity on a file. It takes
in a pointer to a :c:type:`struct fsverity_enable_arg`, defined as
in a pointer to a struct fsverity_enable_arg, defined as
follows::
struct fsverity_enable_arg {

View File

@ -34,20 +34,20 @@ substream. In this procedure, PCM hardware parameters are decided by
interaction between applications and ALSA PCM core. Once decided, runtime of
the PCM substream keeps the parameters.
The parameters are described in :c:type:`struct snd_pcm_hw_params`. This
The parameters are described in struct snd_pcm_hw_params. This
structure includes several types of parameters. Applications set preferable
value to these parameters, then execute ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE
or SNDRV_PCM_IOCTL_HW_PARAMS. The former is used just for refining available
set of parameters. The latter is used for an actual decision of the parameters.
The :c:type:`struct snd_pcm_hw_params` structure has below members:
The struct snd_pcm_hw_params structure has below members:
``flags``
Configurable. ALSA PCM core and some drivers handle this flag to select
convenient parameters or change their behaviour.
``masks``
Configurable. This type of parameter is described in
:c:type:`struct snd_mask` and represent mask values. As of PCM protocol
struct snd_mask and represent mask values. As of PCM protocol
v2.0.13, three types are defined.
- SNDRV_PCM_HW_PARAM_ACCESS
@ -55,7 +55,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members:
- SNDRV_PCM_HW_PARAM_SUBFORMAT
``intervals``
Configurable. This type of parameter is described in
:c:type:`struct snd_interval` and represent values with a range. As of
struct snd_interval and represent values with a range. As of
PCM protocol v2.0.13, twelve types are defined.
- SNDRV_PCM_HW_PARAM_SAMPLE_BITS
@ -78,7 +78,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members:
are going to be changed.
``cmask``
Read-only. After returning from ioctl(2), buffer in user space for
:c:type:`struct snd_pcm_hw_params` includes result of each operation.
struct snd_pcm_hw_params includes result of each operation.
This mask represents which mask/interval parameter is actually changed.
``info``
Read-only. This represents hardware/driver capabilities as bit flags
@ -110,10 +110,10 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members:
value to this parameter but some drivers intentionally set zero with
a care of hardware design or data transmission protocol.
ALSA PCM core handles buffer of :c:type:`struct snd_pcm_hw_params` when
ALSA PCM core handles buffer of struct snd_pcm_hw_params when
applications execute ioctl(2) with SNDRV_PCM_HW_REFINE or SNDRV_PCM_HW_PARAMS.
Parameters in the buffer are changed according to
:c:type:`struct snd_pcm_hardware` and rules of constraints in the runtime. The
struct snd_pcm_hardware and rules of constraints in the runtime. The
structure describes capabilities of handled hardware. The rules describes
dependencies on which a parameter is decided according to several parameters.
A rule has a callback function, and drivers can register arbitrary functions
@ -121,17 +121,17 @@ to compute the target parameter. ALSA PCM core registers some rules to the
runtime as a default.
Each driver can join in the interaction as long as it prepared for two stuffs
in a callback of :c:type:`struct snd_pcm_ops.open`.
in a callback of struct snd_pcm_ops.open.
1. In the callback, drivers are expected to change a member of
:c:type:`struct snd_pcm_hardware` type in the runtime, according to
struct snd_pcm_hardware type in the runtime, according to
capacities of corresponding hardware.
2. In the same callback, drivers are also expected to register additional rules
of constraints into the runtime when several parameters have dependencies
due to hardware design.
The driver can refers to result of the interaction in a callback of
:c:type:`struct snd_pcm_ops.hw_params`, however it should not change the
struct snd_pcm_ops.hw_params, however it should not change the
content.
Tracepoints in this category are designed to trace changes of the
@ -163,7 +163,7 @@ fields are different according to type of the parameter. For parameters of mask
type, the fields represent hexadecimal dump of content of the parameter. For
parameters of interval type, the fields represent values of each member of
``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in
:c:type:`struct snd_interval` in this order.
struct snd_interval in this order.
Tracepoints in drivers
======================

View File

@ -110,7 +110,7 @@ while (<IN>) {
) {
my $s = $1;
$structs{$s} = "struct :c:type:`$s`\\ ";
$structs{$s} = "struct $s\\ ";
next;
}
}

View File

@ -26,7 +26,7 @@ tree.
If a KSM page is shared between less than ``max_page_sharing`` VMAs,
the node of the stable tree that represents such KSM page points to a
list of :c:type:`struct rmap_item` and the ``page->mapping`` of the
list of struct rmap_item and the ``page->mapping`` of the
KSM page points to the stable tree node.
When the sharing passes this threshold, KSM adds a second dimension to

View File

@ -24,7 +24,7 @@ whether it is possible to manually override that default.
although it is still in use by several architectures.
All the memory models track the status of physical page frames using
:c:type:`struct page` arranged in one or more arrays.
struct page arranged in one or more arrays.
Regardless of the selected memory model, there exists one-to-one
mapping between the physical page frame number (PFN) and the
@ -111,7 +111,7 @@ maps for non-volatile memory devices and deferred initialization of
the memory map for larger systems.
The SPARSEMEM model presents the physical memory as a collection of
sections. A section is represented with :c:type:`struct mem_section`
sections. A section is represented with struct mem_section
that contains `section_mem_map` that is, logically, a pointer to an
array of struct pages. However, it is stored with some other magic
that aids the sections management. The section size and maximal number
@ -172,7 +172,7 @@ management.
The virtually mapped memory map allows storing `struct page` objects
for persistent memory devices in pre-allocated storage on those
devices. This storage is represented with :c:type:`struct vmem_altmap`
devices. This storage is represented with struct vmem_altmap
that is eventually passed to vmemmap_populate() through a long chain
of function calls. The vmemmap_populate() implementation may use the
`vmem_altmap` along with :c:func:`vmemmap_alloc_block_buf` helper to

View File

@ -81,7 +81,7 @@
* different KSM page copy of that content
*
* Internally, the regular nodes, "dups" and "chains" are represented
* using the same :c:type:`struct stable_node` structure.
* using the same struct stable_node structure.
*
* In addition to the stable tree, KSM uses a second data structure called the
* unstable tree: this tree holds pointers to pages which have been found to

View File

@ -48,12 +48,12 @@
* boot regardless of the possible restrictions and memory hot(un)plug;
* the ``physmem`` type is only available on some architectures.
*
* Each region is represented by :c:type:`struct memblock_region` that
* Each region is represented by struct memblock_region that
* defines the region extents, its attributes and NUMA node id on NUMA
* systems. Every memory type is described by the :c:type:`struct
* memblock_type` which contains an array of memory regions along with
* the allocator metadata. The "memory" and "reserved" types are nicely
* wrapped with :c:type:`struct memblock`. This structure is statically
* wrapped with struct memblock. This structure is statically
* initialized at build time. The region arrays are initially sized to
* %INIT_MEMBLOCK_REGIONS for "memory" and %INIT_MEMBLOCK_RESERVED_REGIONS
* for "reserved". The region array for "physmem" is initially sized to