From 5b76632ed957e7b43e12f4105d0efb8d734fc659 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 26 Sep 2020 09:08:38 +0200 Subject: media: cec-core.rst: don't use c:type for structs The new C domain code on Sphinx 3 doesn't allow anymore to use c:type:: for structs. Now that cdomain.py has backward support, let's use c:struct:: instead. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/cec-core.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/media/cec-core.rst b/Documentation/driver-api/media/cec-core.rst index 03016eeaf8f4..bc42982ac21e 100644 --- a/Documentation/driver-api/media/cec-core.rst +++ b/Documentation/driver-api/media/cec-core.rst @@ -98,7 +98,7 @@ Implementing the Low-Level CEC Adapter The following low-level adapter operations have to be implemented in your driver: -.. c:type:: struct cec_adap_ops +.. c:struct:: cec_adap_ops .. code-block:: none -- cgit v1.2.3-59-g8ed1b From abc59fd4a56abba8a9d9beadac7a371f4bb76187 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 25 Sep 2020 09:38:33 +0200 Subject: docs: remove some replace macros like |struct foo| There are three files with replace macros for structs, mapping them into Sphinx 2.x C domain references. Well, this is broken on Sphinx 3.x. Also, for Sphinx 2.x, the automarkup macro should be able to take care of them. So, let's just drop those. Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/pm/cpufreq.rst | 11 +++--- Documentation/driver-api/device_link.rst | 10 ++--- Documentation/driver-api/pm/cpuidle.rst | 65 +++++++++++++++----------------- 3 files changed, 38 insertions(+), 48 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst index 368e612145d2..6adb7988e0eb 100644 --- a/Documentation/admin-guide/pm/cpufreq.rst +++ b/Documentation/admin-guide/pm/cpufreq.rst @@ -1,7 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 .. include:: -.. |struct cpufreq_policy| replace:: :c:type:`struct cpufreq_policy ` .. |intel_pstate| replace:: :doc:`intel_pstate ` ======================= @@ -92,16 +91,16 @@ control the P-state of multiple CPUs at the same time and writing to it affects all of those CPUs simultaneously. Sets of CPUs sharing hardware P-state control interfaces are represented by -``CPUFreq`` as |struct cpufreq_policy| objects. For consistency, -|struct cpufreq_policy| is also used when there is only one CPU in the given +``CPUFreq`` as struct cpufreq_policy objects. For consistency, +struct cpufreq_policy is also used when there is only one CPU in the given set. -The ``CPUFreq`` core maintains a pointer to a |struct cpufreq_policy| object for +The ``CPUFreq`` core maintains a pointer to a struct cpufreq_policy object for every CPU in the system, including CPUs that are currently offline. If multiple CPUs share the same hardware P-state control interface, all of the pointers -corresponding to them point to the same |struct cpufreq_policy| object. +corresponding to them point to the same struct cpufreq_policy object. -``CPUFreq`` uses |struct cpufreq_policy| as its basic data type and the design +``CPUFreq`` uses struct cpufreq_policy as its basic data type and the design of its user space interface is based on the policy concept. diff --git a/Documentation/driver-api/device_link.rst b/Documentation/driver-api/device_link.rst index bc2d89af88ce..76950d061632 100644 --- a/Documentation/driver-api/device_link.rst +++ b/Documentation/driver-api/device_link.rst @@ -1,7 +1,3 @@ -.. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain ` -.. |struct generic_pm_domain| replace:: :c:type:`struct generic_pm_domain ` - - .. _device_link: ============ @@ -166,7 +162,7 @@ Examples is the same as if the MMU was the parent of the master device. The fact that both devices share the same power domain would normally - suggest usage of a |struct dev_pm_domain| or |struct generic_pm_domain|, + suggest usage of a struct dev_pm_domain or struct generic_pm_domain, however these are not independent devices that happen to share a power switch, but rather the MMU device serves the busmaster device and is useless without it. A device link creates a synthetic hierarchical @@ -202,7 +198,7 @@ Examples Alternatives ============ -* A |struct dev_pm_domain| can be used to override the bus, +* A struct dev_pm_domain can be used to override the bus, class or device type callbacks. It is intended for devices sharing a single on/off switch, however it does not guarantee a specific suspend/resume ordering, this needs to be implemented separately. @@ -211,7 +207,7 @@ Alternatives suspended. Furthermore it cannot be used to enforce a specific shutdown ordering or a driver presence dependency. -* A |struct generic_pm_domain| is a lot more heavyweight than a +* A struct generic_pm_domain is a lot more heavyweight than a device link and does not allow for shutdown ordering or driver presence dependencies. It also cannot be used on ACPI systems. diff --git a/Documentation/driver-api/pm/cpuidle.rst b/Documentation/driver-api/pm/cpuidle.rst index 3588bf078566..d477208604b8 100644 --- a/Documentation/driver-api/pm/cpuidle.rst +++ b/Documentation/driver-api/pm/cpuidle.rst @@ -1,11 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 .. include:: -.. |struct cpuidle_governor| replace:: :c:type:`struct cpuidle_governor ` -.. |struct cpuidle_device| replace:: :c:type:`struct cpuidle_device ` -.. |struct cpuidle_driver| replace:: :c:type:`struct cpuidle_driver ` -.. |struct cpuidle_state| replace:: :c:type:`struct cpuidle_state ` - ======================== CPU Idle Time Management ======================== @@ -54,7 +49,7 @@ platform that the Linux kernel can run on. For this reason, data structures operated on by them cannot depend on any hardware architecture or platform design details as well. -The governor itself is represented by a |struct cpuidle_governor| object +The governor itself is represented by a struct cpuidle_governor object containing four callback pointers, :c:member:`enable`, :c:member:`disable`, :c:member:`select`, :c:member:`reflect`, a :c:member:`rating` field described below, and a name (string) used for identifying it. @@ -83,11 +78,11 @@ callbacks: int (*enable) (struct cpuidle_driver *drv, struct cpuidle_device *dev); The role of this callback is to prepare the governor for handling the - (logical) CPU represented by the |struct cpuidle_device| object pointed - to by the ``dev`` argument. The |struct cpuidle_driver| object pointed + (logical) CPU represented by the struct cpuidle_device object pointed + to by the ``dev`` argument. The struct cpuidle_driver object pointed to by the ``drv`` argument represents the ``CPUIdle`` driver to be used with that CPU (among other things, it should contain the list of - |struct cpuidle_state| objects representing idle states that the + struct cpuidle_state objects representing idle states that the processor holding the given CPU can be asked to enter). It may fail, in which case it is expected to return a negative error @@ -102,7 +97,7 @@ callbacks: void (*disable) (struct cpuidle_driver *drv, struct cpuidle_device *dev); Called to make the governor stop handling the (logical) CPU represented - by the |struct cpuidle_device| object pointed to by the ``dev`` + by the struct cpuidle_device object pointed to by the ``dev`` argument. It is expected to reverse any changes made by the ``->enable()`` @@ -116,12 +111,12 @@ callbacks: bool *stop_tick); Called to select an idle state for the processor holding the (logical) - CPU represented by the |struct cpuidle_device| object pointed to by the + CPU represented by the struct cpuidle_device object pointed to by the ``dev`` argument. The list of idle states to take into consideration is represented by the - :c:member:`states` array of |struct cpuidle_state| objects held by the - |struct cpuidle_driver| object pointed to by the ``drv`` argument (which + :c:member:`states` array of struct cpuidle_state objects held by the + struct cpuidle_driver object pointed to by the ``drv`` argument (which represents the ``CPUIdle`` driver to be used with the CPU at hand). The value returned by this callback is interpreted as an index into that array (unless it is a negative error code). @@ -136,7 +131,7 @@ callbacks: asking the processor to enter the idle state). This callback is mandatory (i.e. the :c:member:`select` callback pointer - in |struct cpuidle_governor| must not be ``NULL`` for the registration + in struct cpuidle_governor must not be ``NULL`` for the registration of the governor to succeed). :c:member:`reflect` @@ -167,21 +162,21 @@ CPU idle time management (``CPUIdle``) drivers provide an interface between the other parts of ``CPUIdle`` and the hardware. First of all, a ``CPUIdle`` driver has to populate the :c:member:`states` array -of |struct cpuidle_state| objects included in the |struct cpuidle_driver| object +of struct cpuidle_state objects included in the struct cpuidle_driver object representing it. Going forward this array will represent the list of available idle states that the processor hardware can be asked to enter shared by all of the logical CPUs handled by the given driver. The entries in the :c:member:`states` array are expected to be sorted by the -value of the :c:member:`target_residency` field in |struct cpuidle_state| in +value of the :c:member:`target_residency` field in struct cpuidle_state in the ascending order (that is, index 0 should correspond to the idle state with the minimum value of :c:member:`target_residency`). [Since the :c:member:`target_residency` value is expected to reflect the "depth" of the -idle state represented by the |struct cpuidle_state| object holding it, this +idle state represented by the struct cpuidle_state object holding it, this sorting order should be the same as the ascending sorting order by the idle state "depth".] -Three fields in |struct cpuidle_state| are used by the existing ``CPUIdle`` +Three fields in struct cpuidle_state are used by the existing ``CPUIdle`` governors for computations related to idle state selection: :c:member:`target_residency` @@ -203,7 +198,7 @@ governors for computations related to idle state selection: any idle state at all. [There are other flags used by the ``CPUIdle`` core in special situations.] -The :c:member:`enter` callback pointer in |struct cpuidle_state|, which must not +The :c:member:`enter` callback pointer in struct cpuidle_state, which must not be ``NULL``, points to the routine to execute in order to ask the processor to enter this particular idle state: @@ -212,14 +207,14 @@ enter this particular idle state: void (*enter) (struct cpuidle_device *dev, struct cpuidle_driver *drv, int index); -The first two arguments of it point to the |struct cpuidle_device| object +The first two arguments of it point to the struct cpuidle_device object representing the logical CPU running this callback and the -|struct cpuidle_driver| object representing the driver itself, respectively, -and the last one is an index of the |struct cpuidle_state| entry in the driver's +struct cpuidle_driver object representing the driver itself, respectively, +and the last one is an index of the struct cpuidle_state entry in the driver's :c:member:`states` array representing the idle state to ask the processor to enter. -The analogous ``->enter_s2idle()`` callback in |struct cpuidle_state| is used +The analogous ``->enter_s2idle()`` callback in struct cpuidle_state is used only for implementing the suspend-to-idle system-wide power management feature. The difference between in and ``->enter()`` is that it must not re-enable interrupts at any point (even temporarily) or attempt to change the states of @@ -227,48 +222,48 @@ clock event devices, which the ``->enter()`` callback may do sometimes. Once the :c:member:`states` array has been populated, the number of valid entries in it has to be stored in the :c:member:`state_count` field of the -|struct cpuidle_driver| object representing the driver. Moreover, if any +struct cpuidle_driver object representing the driver. Moreover, if any entries in the :c:member:`states` array represent "coupled" idle states (that is, idle states that can only be asked for if multiple related logical CPUs are -idle), the :c:member:`safe_state_index` field in |struct cpuidle_driver| needs +idle), the :c:member:`safe_state_index` field in struct cpuidle_driver needs to be the index of an idle state that is not "coupled" (that is, one that can be asked for if only one logical CPU is idle). In addition to that, if the given ``CPUIdle`` driver is only going to handle a subset of logical CPUs in the system, the :c:member:`cpumask` field in its -|struct cpuidle_driver| object must point to the set (mask) of CPUs that will be +struct cpuidle_driver object must point to the set (mask) of CPUs that will be handled by it. A ``CPUIdle`` driver can only be used after it has been registered. If there are no "coupled" idle state entries in the driver's :c:member:`states` array, -that can be accomplished by passing the driver's |struct cpuidle_driver| object +that can be accomplished by passing the driver's struct cpuidle_driver object to :c:func:`cpuidle_register_driver()`. Otherwise, :c:func:`cpuidle_register()` should be used for this purpose. -However, it also is necessary to register |struct cpuidle_device| objects for +However, it also is necessary to register struct cpuidle_device objects for all of the logical CPUs to be handled by the given ``CPUIdle`` driver with the help of :c:func:`cpuidle_register_device()` after the driver has been registered and :c:func:`cpuidle_register_driver()`, unlike :c:func:`cpuidle_register()`, does not do that automatically. For this reason, the drivers that use :c:func:`cpuidle_register_driver()` to register themselves must also take care -of registering the |struct cpuidle_device| objects as needed, so it is generally +of registering the struct cpuidle_device objects as needed, so it is generally recommended to use :c:func:`cpuidle_register()` for ``CPUIdle`` driver registration in all cases. -The registration of a |struct cpuidle_device| object causes the ``CPUIdle`` +The registration of a struct cpuidle_device object causes the ``CPUIdle`` ``sysfs`` interface to be created and the governor's ``->enable()`` callback to be invoked for the logical CPU represented by it, so it must take place after registering the driver that will handle the CPU in question. -``CPUIdle`` drivers and |struct cpuidle_device| objects can be unregistered +``CPUIdle`` drivers and struct cpuidle_device objects can be unregistered when they are not necessary any more which allows some resources associated with them to be released. Due to dependencies between them, all of the -|struct cpuidle_device| objects representing CPUs handled by the given +struct cpuidle_device objects representing CPUs handled by the given ``CPUIdle`` driver must be unregistered, with the help of :c:func:`cpuidle_unregister_device()`, before calling :c:func:`cpuidle_unregister_driver()` to unregister the driver. Alternatively, :c:func:`cpuidle_unregister()` can be called to unregister a ``CPUIdle`` driver -along with all of the |struct cpuidle_device| objects representing CPUs handled +along with all of the struct cpuidle_device objects representing CPUs handled by it. ``CPUIdle`` drivers can respond to runtime system configuration changes that @@ -277,8 +272,8 @@ happen, for example, when the system's power source is switched from AC to battery or the other way around). Upon a notification of such a change, a ``CPUIdle`` driver is expected to call :c:func:`cpuidle_pause_and_lock()` to turn ``CPUIdle`` off temporarily and then :c:func:`cpuidle_disable_device()` for -all of the |struct cpuidle_device| objects representing CPUs affected by that +all of the struct cpuidle_device objects representing CPUs affected by that change. Next, it can update its :c:member:`states` array in accordance with the new configuration of the system, call :c:func:`cpuidle_enable_device()` for -all of the relevant |struct cpuidle_device| objects and invoke +all of the relevant struct cpuidle_device objects and invoke :c:func:`cpuidle_resume_and_unlock()` to allow ``CPUIdle`` to be used again. -- cgit v1.2.3-59-g8ed1b From 9303c9d5e9883d5aef73e58baa595395f09954c5 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 25 Sep 2020 12:01:25 +0200 Subject: docs: get rid of :c:type explicit declarations for structs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 # blk-mq.rst Reviewed-by: Takashi Iwai # sound Reviewed-by: Mike Rapoport Reviewed-by: Greg Kroah-Hartman Signed-off-by: Mauro Carvalho Chehab --- Documentation/block/blk-mq.rst | 8 ++++---- Documentation/block/inline-encryption.rst | 8 ++++---- Documentation/driver-api/fpga/fpga-bridge.rst | 4 ++-- Documentation/driver-api/fpga/fpga-mgr.rst | 4 ++-- Documentation/driver-api/fpga/fpga-region.rst | 2 +- Documentation/driver-api/iio/buffers.rst | 2 +- Documentation/driver-api/iio/core.rst | 6 +++--- Documentation/driver-api/iio/hw-consumer.rst | 2 +- Documentation/driver-api/iio/triggered-buffers.rst | 2 +- Documentation/driver-api/iio/triggers.rst | 4 ++-- Documentation/driver-api/media/dtv-frontend.rst | 4 ++-- Documentation/driver-api/media/mc-core.rst | 24 +++++++++++----------- Documentation/driver-api/media/v4l2-controls.rst | 2 +- Documentation/driver-api/media/v4l2-dev.rst | 8 ++++---- Documentation/driver-api/media/v4l2-device.rst | 6 +++--- Documentation/driver-api/media/v4l2-event.rst | 10 ++++----- Documentation/driver-api/media/v4l2-fh.rst | 16 +++++++-------- Documentation/driver-api/media/v4l2-subdev.rst | 2 +- Documentation/driver-api/regulator.rst | 4 ++-- Documentation/driver-api/usb/URB.rst | 2 +- Documentation/driver-api/usb/gadget.rst | 10 ++++----- Documentation/driver-api/usb/hotplug.rst | 2 +- Documentation/filesystems/fsverity.rst | 2 +- Documentation/sound/designs/tracepoints.rst | 22 ++++++++++---------- Documentation/sphinx/parse-headers.pl | 2 +- Documentation/vm/ksm.rst | 2 +- Documentation/vm/memory-model.rst | 6 +++--- mm/ksm.c | 2 +- mm/memblock.c | 4 ++-- 29 files changed, 86 insertions(+), 86 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/block/blk-mq.rst b/Documentation/block/blk-mq.rst index 88c56afcb070..86a632af02b0 100644 --- a/Documentation/block/blk-mq.rst +++ b/Documentation/block/blk-mq.rst @@ -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 diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 354817b80887..e75151e467d3 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -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 diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst index ccd677ba7d76..198aadafd3e7 100644 --- a/Documentation/driver-api/fpga/fpga-bridge.rst +++ b/Documentation/driver-api/fpga/fpga-bridge.rst @@ -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 diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst index af5382af1379..22f7885b32c9 100644 --- a/Documentation/driver-api/fpga/fpga-mgr.rst +++ b/Documentation/driver-api/fpga/fpga-mgr.rst @@ -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 diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst index 31118a8ba218..3e52be7e2968 100644 --- a/Documentation/driver-api/fpga/fpga-region.rst +++ b/Documentation/driver-api/fpga/fpga-region.rst @@ -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 diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst index dd64c9c5fb1e..3ddebddc02ca 100644 --- a/Documentation/driver-api/iio/buffers.rst +++ b/Documentation/driver-api/iio/buffers.rst @@ -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 diff --git a/Documentation/driver-api/iio/core.rst b/Documentation/driver-api/iio/core.rst index 51b21e002396..715cf29482a1 100644 --- a/Documentation/driver-api/iio/core.rst +++ b/Documentation/driver-api/iio/core.rst @@ -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:: diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst index 819fb9edc005..76133a3796f2 100644 --- a/Documentation/driver-api/iio/hw-consumer.rst +++ b/Documentation/driver-api/iio/hw-consumer.rst @@ -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 diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst index 0db12660cc90..417555dbbdf4 100644 --- a/Documentation/driver-api/iio/triggered-buffers.rst +++ b/Documentation/driver-api/iio/triggered-buffers.rst @@ -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:: diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst index dfd7ba3eabde..288625e40672 100644 --- a/Documentation/driver-api/iio/triggers.rst +++ b/Documentation/driver-api/iio/triggers.rst @@ -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: diff --git a/Documentation/driver-api/media/dtv-frontend.rst b/Documentation/driver-api/media/dtv-frontend.rst index b362109bb131..91f77fe58e83 100644 --- a/Documentation/driver-api/media/dtv-frontend.rst +++ b/Documentation/driver-api/media/dtv-frontend.rst @@ -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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/driver-api/media/mc-core.rst b/Documentation/driver-api/media/mc-core.rst index 05bba0b61748..57b5bbba944e 100644 --- a/Documentation/driver-api/media/mc-core.rst +++ b/Documentation/driver-api/media/mc-core.rst @@ -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. diff --git a/Documentation/driver-api/media/v4l2-controls.rst b/Documentation/driver-api/media/v4l2-controls.rst index 5129019afb49..77f42ea3bac7 100644 --- a/Documentation/driver-api/media/v4l2-controls.rst +++ b/Documentation/driver-api/media/v4l2-controls.rst @@ -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. diff --git a/Documentation/driver-api/media/v4l2-dev.rst b/Documentation/driver-api/media/v4l2-dev.rst index 63c064837c00..666330af31ed 100644 --- a/Documentation/driver-api/media/v4l2-dev.rst +++ b/Documentation/driver-api/media/v4l2-dev.rst @@ -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. diff --git a/Documentation/driver-api/media/v4l2-device.rst b/Documentation/driver-api/media/v4l2-device.rst index 5e25bf182c18..7bd9c45f551b 100644 --- a/Documentation/driver-api/media/v4l2-device.rst +++ b/Documentation/driver-api/media/v4l2-device.rst @@ -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 `\ ->name is empty then it will be set to a diff --git a/Documentation/driver-api/media/v4l2-event.rst b/Documentation/driver-api/media/v4l2-event.rst index a4b7ae2b94d8..5b8254eba7da 100644 --- a/Documentation/driver-api/media/v4l2-event.rst +++ b/Documentation/driver-api/media/v4l2-event.rst @@ -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. diff --git a/Documentation/driver-api/media/v4l2-fh.rst b/Documentation/driver-api/media/v4l2-fh.rst index 4c62b19af744..3eeaa8da0c9e 100644 --- a/Documentation/driver-api/media/v4l2-fh.rst +++ b/Documentation/driver-api/media/v4l2-fh.rst @@ -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 ` (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 ` (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()`` diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst index 6248ea99e979..bb5b1a7cdfd9 100644 --- a/Documentation/driver-api/media/v4l2-subdev.rst +++ b/Documentation/driver-api/media/v4l2-subdev.rst @@ -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 diff --git a/Documentation/driver-api/regulator.rst b/Documentation/driver-api/regulator.rst index 520da0a5251d..b43c78eb24d8 100644 --- a/Documentation/driver-api/regulator.rst +++ b/Documentation/driver-api/regulator.rst @@ -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 diff --git a/Documentation/driver-api/usb/URB.rst b/Documentation/driver-api/usb/URB.rst index 1e4abc896a0d..a182c0f5e38a 100644 --- a/Documentation/driver-api/usb/URB.rst +++ b/Documentation/driver-api/usb/URB.rst @@ -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 { diff --git a/Documentation/driver-api/usb/gadget.rst b/Documentation/driver-api/usb/gadget.rst index 3e8a3809c0b8..09396edd6131 100644 --- a/Documentation/driver-api/usb/gadget.rst +++ b/Documentation/driver-api/usb/gadget.rst @@ -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, diff --git a/Documentation/driver-api/usb/hotplug.rst b/Documentation/driver-api/usb/hotplug.rst index 79663e653ca1..c1e13107c50e 100644 --- a/Documentation/driver-api/usb/hotplug.rst +++ b/Documentation/driver-api/usb/hotplug.rst @@ -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:: diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index 6c8944f6f0f7..895e9711ed88 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -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 { diff --git a/Documentation/sound/designs/tracepoints.rst b/Documentation/sound/designs/tracepoints.rst index 78bc5572f829..b0a7e3010187 100644 --- a/Documentation/sound/designs/tracepoints.rst +++ b/Documentation/sound/designs/tracepoints.rst @@ -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 ====================== diff --git a/Documentation/sphinx/parse-headers.pl b/Documentation/sphinx/parse-headers.pl index 00a69aceff44..1910079f984f 100755 --- a/Documentation/sphinx/parse-headers.pl +++ b/Documentation/sphinx/parse-headers.pl @@ -110,7 +110,7 @@ while () { ) { my $s = $1; - $structs{$s} = "struct :c:type:`$s`\\ "; + $structs{$s} = "struct $s\\ "; next; } } diff --git a/Documentation/vm/ksm.rst b/Documentation/vm/ksm.rst index d1b7270ad55c..9e37add068e6 100644 --- a/Documentation/vm/ksm.rst +++ b/Documentation/vm/ksm.rst @@ -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 diff --git a/Documentation/vm/memory-model.rst b/Documentation/vm/memory-model.rst index 769449734573..9daadf9faba1 100644 --- a/Documentation/vm/memory-model.rst +++ b/Documentation/vm/memory-model.rst @@ -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 diff --git a/mm/ksm.c b/mm/ksm.c index 9afccc36dbd2..0960750bb316 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -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 diff --git a/mm/memblock.c b/mm/memblock.c index 165f40a8a254..d84790cb7ac3 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -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 -- cgit v1.2.3-59-g8ed1b From 1842c96beebb1bab9241c3f55091d5f975f37926 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 28 Sep 2020 16:31:44 +0200 Subject: docs: remove sound API duplication The sound API is documented on two different parts: under Documentation/driver-api/sound.rst and under Documentation/sound/kernel-api/alsa-driver-api.rst. The alsa-driver-api.rst seems more complete, and APIs are split per type. There's just one missing kernel-doc markup there. Add it and drop the duplicated one. Reviewed-by: Takashi Iwai Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/index.rst | 1 - Documentation/driver-api/sound.rst | 54 ---------------------- Documentation/sound/kernel-api/alsa-driver-api.rst | 1 + 3 files changed, 1 insertion(+), 55 deletions(-) delete mode 100644 Documentation/driver-api/sound.rst (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 6e7c702e0268..987d6e74ea6a 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -27,7 +27,6 @@ available subsections can be seen below. component message-based infiniband - sound frame-buffer regulator iio/index diff --git a/Documentation/driver-api/sound.rst b/Documentation/driver-api/sound.rst deleted file mode 100644 index afef6eabc073..000000000000 --- a/Documentation/driver-api/sound.rst +++ /dev/null @@ -1,54 +0,0 @@ -Sound Devices -============= - -.. kernel-doc:: include/sound/core.h - :internal: - -.. kernel-doc:: sound/sound_core.c - :export: - -.. kernel-doc:: include/sound/pcm.h - :internal: - -.. kernel-doc:: sound/core/pcm.c - :export: - -.. kernel-doc:: sound/core/device.c - :export: - -.. kernel-doc:: sound/core/info.c - :export: - -.. kernel-doc:: sound/core/rawmidi.c - :export: - -.. kernel-doc:: sound/core/sound.c - :export: - -.. kernel-doc:: sound/core/memory.c - :export: - -.. kernel-doc:: sound/core/pcm_memory.c - :export: - -.. kernel-doc:: sound/core/init.c - :export: - -.. kernel-doc:: sound/core/isadma.c - :export: - -.. kernel-doc:: sound/core/control.c - :export: - -.. kernel-doc:: sound/core/pcm_lib.c - :export: - -.. kernel-doc:: sound/core/hwdep.c - :export: - -.. kernel-doc:: sound/core/pcm_native.c - :export: - -.. kernel-doc:: sound/core/memalloc.c - :export: - diff --git a/Documentation/sound/kernel-api/alsa-driver-api.rst b/Documentation/sound/kernel-api/alsa-driver-api.rst index c8cc651eccf7..d24c64df7069 100644 --- a/Documentation/sound/kernel-api/alsa-driver-api.rst +++ b/Documentation/sound/kernel-api/alsa-driver-api.rst @@ -132,3 +132,4 @@ ISA DMA Helpers Other Helper Macros ------------------- .. kernel-doc:: include/sound/core.h +.. kernel-doc:: sound/sound_core.c -- cgit v1.2.3-59-g8ed1b From c9e3d519ee37631a15d7940e9f1856c4e6206854 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 28 Sep 2020 16:49:26 +0200 Subject: docs: basics.rst: move kernel-doc workqueue markups to workqueue.rst As there's already a rst file with workqueue markups, containing part of them, move the other definitions, in order to avoid warnings with Sphinx. Signed-off-by: Mauro Carvalho Chehab --- Documentation/core-api/workqueue.rst | 2 ++ Documentation/driver-api/basics.rst | 9 --------- 2 files changed, 2 insertions(+), 9 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst index 00a5ba51e63f..541d31de8926 100644 --- a/Documentation/core-api/workqueue.rst +++ b/Documentation/core-api/workqueue.rst @@ -396,3 +396,5 @@ Kernel Inline Documentations Reference ====================================== .. kernel-doc:: include/linux/workqueue.h + +.. kernel-doc:: kernel/workqueue.c diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst index 1ba88c7b3984..54f8d5ca7475 100644 --- a/Documentation/driver-api/basics.rst +++ b/Documentation/driver-api/basics.rst @@ -55,15 +55,6 @@ High-resolution timers .. kernel-doc:: kernel/time/hrtimer.c :export: -Workqueues and Kevents ----------------------- - -.. kernel-doc:: include/linux/workqueue.h - :internal: - -.. kernel-doc:: kernel/workqueue.c - :export: - Internal Functions ------------------ -- cgit v1.2.3-59-g8ed1b From 3048ba60070e9ce00ed72b73cdfc1feb2641f8a1 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 28 Sep 2020 16:54:17 +0200 Subject: docs: scsi: target.rst: remove iSCSI transport class kernel-doc markup This is already included at scsi.rst. So, remove the duplication, in order to avoid Sphinx warnings. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/target.rst | 12 ------------ 1 file changed, 12 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/target.rst b/Documentation/driver-api/target.rst index 620ec6173a93..c70ca25171c0 100644 --- a/Documentation/driver-api/target.rst +++ b/Documentation/driver-api/target.rst @@ -41,18 +41,6 @@ iSCSI boot information .. kernel-doc:: drivers/scsi/iscsi_boot_sysfs.c :export: - -iSCSI transport class -===================== - -The file drivers/scsi/scsi_transport_iscsi.c defines transport -attributes for the iSCSI class, which sends SCSI packets over TCP/IP -connections. - -.. kernel-doc:: drivers/scsi/scsi_transport_iscsi.c - :export: - - iSCSI TCP interfaces ==================== -- cgit v1.2.3-59-g8ed1b From 58bc57b0de854f657b58a4f87f44ea82b8240719 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 28 Sep 2020 17:01:31 +0200 Subject: docs: device_link.rst: remove duplicated kernel-doc include The infrastructure.rst file already includes the external symbols from drivers/base/core.c. Duplicating 3 functions there causes namespace collisions: Documentation/driver-api/device_link.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/infrastructure'. Declaration is 'device_link_state'. Documentation/driver-api/device_link.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/infrastructure'. Declaration is 'device_link_add'. Documentation/driver-api/device_link.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/infrastructure'. Declaration is 'device_link_del'. Documentation/driver-api/device_link.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/infrastructure'. Declaration is 'device_link_remove'. So, drop the reference, adding just a mention to the functions associated with device_link. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/device_link.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/device_link.rst b/Documentation/driver-api/device_link.rst index 76950d061632..ee913ae16371 100644 --- a/Documentation/driver-api/device_link.rst +++ b/Documentation/driver-api/device_link.rst @@ -317,5 +317,4 @@ State machine API === -.. kernel-doc:: drivers/base/core.c - :functions: device_link_add device_link_del device_link_remove +See device_link_add(), device_link_del() and device_link_remove(). -- cgit v1.2.3-59-g8ed1b From 044248db5db16f8aec28c08d505a4467d3afb3cb Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 29 Sep 2020 08:39:30 +0200 Subject: docs: basics.rst: get rid of rcu kernel-doc macros Those are already defined at kernel-api.rst, as part of the synchronization primitives chapter. This solves several Sphinx 3 warnings, like: .../Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'. Declaration is 'rcu_idle_enter'. .../Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'. Declaration is 'rcu_idle_exit'. .../Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'. Declaration is 'rcu_is_watching'. .../Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'. Declaration is 'call_rcu'. .../Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'. Declaration is 'synchronize_rcu'. ... Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/basics.rst | 6 ------ 1 file changed, 6 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst index 54f8d5ca7475..63bbe3ed5e76 100644 --- a/Documentation/driver-api/basics.rst +++ b/Documentation/driver-api/basics.rst @@ -103,12 +103,6 @@ Kernel utility functions .. kernel-doc:: kernel/panic.c :export: -.. kernel-doc:: kernel/rcu/tree.c - :export: - -.. kernel-doc:: kernel/rcu/update.c - :export: - .. kernel-doc:: include/linux/overflow.h :internal: -- cgit v1.2.3-59-g8ed1b From 6624d64da6bf2f62a8588fca81077dbeedb62116 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 29 Sep 2020 09:20:06 +0200 Subject: docs: devices.rst: get rid of :c:type macros There's no need to use macros to use :c:type on this file, as automarkup.py should do this automatically. Also, this breaks compatibility with Sphinx 3.x, as there, structs should be declared using .. c:struct. So, get rid of them. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/pm/devices.rst | 24 ++++++++---------------- 1 file changed, 8 insertions(+), 16 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index 946ad0b94e31..4bda8a21f5d1 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -1,14 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 .. include:: -.. |struct dev_pm_ops| replace:: :c:type:`struct dev_pm_ops ` -.. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain ` -.. |struct bus_type| replace:: :c:type:`struct bus_type ` -.. |struct device_type| replace:: :c:type:`struct device_type ` -.. |struct class| replace:: :c:type:`struct class ` -.. |struct wakeup_source| replace:: :c:type:`struct wakeup_source ` -.. |struct device| replace:: :c:type:`struct device ` - .. _driverapi_pm_devices: ============================== @@ -107,7 +99,7 @@ Device Power Management Operations Device power management operations, at the subsystem level as well as at the device driver level, are implemented by defining and populating objects of type -|struct dev_pm_ops| defined in :file:`include/linux/pm.h`. The roles of the +struct dev_pm_ops defined in :file:`include/linux/pm.h`. The roles of the methods included in it will be explained in what follows. For now, it should be sufficient to remember that the last three methods are specific to runtime power management while the remaining ones are used during system-wide power @@ -115,7 +107,7 @@ transitions. There also is a deprecated "old" or "legacy" interface for power management operations available at least for some subsystems. This approach does not use -|struct dev_pm_ops| objects and it is suitable only for implementing system +struct dev_pm_ops objects and it is suitable only for implementing system sleep power management methods in a limited way. Therefore it is not described in this document, so please refer directly to the source code for more information about it. @@ -125,9 +117,9 @@ Subsystem-Level Methods ----------------------- The core methods to suspend and resume devices reside in -|struct dev_pm_ops| pointed to by the :c:member:`ops` member of -|struct dev_pm_domain|, or by the :c:member:`pm` member of |struct bus_type|, -|struct device_type| and |struct class|. They are mostly of interest to the +struct dev_pm_ops pointed to by the :c:member:`ops` member of +struct dev_pm_domain, or by the :c:member:`pm` member of struct bus_type, +struct device_type and struct class. They are mostly of interest to the people writing infrastructure for platforms and buses, like PCI or USB, or device type and device class drivers. They also are relevant to the writers of device drivers whose subsystems (PM domains, device types, device classes and @@ -156,7 +148,7 @@ The :c:member:`power.can_wakeup` flag just records whether the device (and its driver) can physically support wakeup events. The :c:func:`device_set_wakeup_capable()` routine affects this flag. The :c:member:`power.wakeup` field is a pointer to an object of type -|struct wakeup_source| used for controlling whether or not the device should use +struct wakeup_source used for controlling whether or not the device should use its system wakeup mechanism and for notifying the PM core of system wakeup events signaled by the device. This object is only present for wakeup-capable devices (i.e. devices whose :c:member:`can_wakeup` flags are set) and is created @@ -713,8 +705,8 @@ nested inside another power domain. The nested domain is referred to as the sub-domain of the parent domain. Support for power domains is provided through the :c:member:`pm_domain` field of -|struct device|. This field is a pointer to an object of type -|struct dev_pm_domain|, defined in :file:`include/linux/pm.h`, providing a set +struct device. This field is a pointer to an object of type +struct dev_pm_domain, defined in :file:`include/linux/pm.h`, providing a set of power management callbacks analogous to the subsystem-level and device driver callbacks that are executed for the given device during all power transitions, instead of the respective subsystem-level callbacks. Specifically, if a -- cgit v1.2.3-59-g8ed1b From 64d4151658c14b18905ba0d82cc26ccf6b92a1a1 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 29 Sep 2020 11:09:46 +0200 Subject: docs: fpga: replace :c:member: macros Those macros are not doing the right thing with Sphinx 3, causing parse errors: ./Documentation/driver-api/fpga/fpga-mgr.rst:104: WARNING: Unparseable C cross-reference: 'fpga_manager->state' Invalid C declaration: Expected end of definition. [error at 12] fpga_manager->state ------------^ ./Documentation/driver-api/fpga/fpga-programming.rst:18: WARNING: Unparseable C cross-reference: 'fpga_region->info' Invalid C declaration: Expected end of definition. [error at 11] fpga_region->info -----------^ ./Documentation/driver-api/fpga/fpga-region.rst:62: WARNING: Unparseable C cross-reference: 'fpga_region->bridge_list' Invalid C declaration: Expected end of definition. [error at 11] fpga_region->bridge_list -----------^ ./Documentation/driver-api/fpga/fpga-region.rst:62: WARNING: Unparseable C cross-reference: 'fpga_region->get_bridges' Invalid C declaration: Expected end of definition. [error at 11] fpga_region->get_bridges -----------^ Replace them by :c:expr:, with does what's desired. Reviewed-by: Moritz Fischer Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/fpga/fpga-mgr.rst | 2 +- Documentation/driver-api/fpga/fpga-programming.rst | 2 +- Documentation/driver-api/fpga/fpga-region.rst | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst index 22f7885b32c9..917ee22db429 100644 --- a/Documentation/driver-api/fpga/fpga-mgr.rst +++ b/Documentation/driver-api/fpga/fpga-mgr.rst @@ -101,7 +101,7 @@ in state. API for implementing a new FPGA Manager driver ---------------------------------------------- -* ``fpga_mgr_states`` — Values for :c:member:`fpga_manager->state`. +* ``fpga_mgr_states`` — Values for :c:expr:`fpga_manager->state`. * 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 diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst index f487ad64dfb9..002392dab04f 100644 --- a/Documentation/driver-api/fpga/fpga-programming.rst +++ b/Documentation/driver-api/fpga/fpga-programming.rst @@ -15,7 +15,7 @@ the FPGA manager and bridges. It will: * lock the mutex of the region's FPGA manager * build a list of FPGA bridges if a method has been specified to do so * disable the bridges - * program the FPGA using info passed in :c:member:`fpga_region->info`. + * program the FPGA using info passed in :c:expr:`fpga_region->info`. * re-enable the bridges * release the locks diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst index 3e52be7e2968..363a8171ab0a 100644 --- a/Documentation/driver-api/fpga/fpga-region.rst +++ b/Documentation/driver-api/fpga/fpga-region.rst @@ -61,9 +61,9 @@ during the region's probe function. The FPGA region will need to specify which bridges to control while programming the FPGA. The region driver can build a list of bridges during probe time -(:c:member:`fpga_region->bridge_list`) or it can have a function that creates +(:c:expr:`fpga_region->bridge_list`) or it can have a function that creates the list of bridges to program just before programming -(:c:member:`fpga_region->get_bridges`). The FPGA bridge framework supplies the +(:c:expr:`fpga_region->get_bridges`). The FPGA bridge framework supplies the following APIs to handle building or tearing down that list. * fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a -- cgit v1.2.3-59-g8ed1b From b989451b8e0015b8fe2fac0736ab84bf4389fcb0 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 29 Sep 2020 11:23:19 +0200 Subject: docs: libata.rst: fix a wrong usage of :c:type: tag The usage of :c:type: to reference to a struct member is wrong, as pointed by Sphinx 3: ./Documentation/driver-api/libata.rst:511: WARNING: Unparseable C cross-reference: 'qc->complete_fn' Invalid C declaration: Expected end of definition. [error at 2] qc->complete_fn --^ Instead, let's use :c:expr: for such purpose. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/libata.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/libata.rst b/Documentation/driver-api/libata.rst index e2f87b82b074..d477e296bda5 100644 --- a/Documentation/driver-api/libata.rst +++ b/Documentation/driver-api/libata.rst @@ -508,7 +508,7 @@ also complete commands. 2. ATA_QCFLAG_ACTIVE is cleared from qc->flags. -3. :c:func:`qc->complete_fn` callback is invoked. If the return value of the +3. :c:expr:`qc->complete_fn` callback is invoked. If the return value of the callback is not zero. Completion is short circuited and :c:func:`ata_qc_complete` returns. -- cgit v1.2.3-59-g8ed1b From afe178adb9f263922d358d0aa9a04a34c5278e27 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 29 Sep 2020 11:50:50 +0200 Subject: docs: infrastructure.rst: don't include firmware kernel-doc Those are already documented at: Documentation/driver-api/firmware/request_firmware.rst Including it twice is causing lots of warnings: ./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'. Declaration is 'request_firmware'. ./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'. Declaration is 'firmware_request_nowarn'. ./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'. Declaration is 'request_firmware_direct'. ./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'. Declaration is 'firmware_request_platform'. ./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'. Declaration is 'firmware_request_cache'. ./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'. Declaration is 'request_firmware_into_buf'. ./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'. Declaration is 'request_firmware_nowait'. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/infrastructure.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst index 06d98c4526df..e38d79be4e16 100644 --- a/Documentation/driver-api/infrastructure.rst +++ b/Documentation/driver-api/infrastructure.rst @@ -28,9 +28,6 @@ Device Drivers Base .. kernel-doc:: drivers/base/node.c :internal: -.. kernel-doc:: drivers/base/firmware_loader/main.c - :export: - .. kernel-doc:: drivers/base/transport_class.c :export: -- cgit v1.2.3-59-g8ed1b From 2f27ed756813887395e3b287fc6522c06a56e528 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 29 Sep 2020 12:38:37 +0200 Subject: docs: devices.rst: fix a C reference markup The C domain parser of Sphinx3 expects just function names for :c:func: markups: ./Documentation/driver-api/pm/devices.rst:413: WARNING: Unparseable C cross-reference: 'device_may_wakeup(dev)' Invalid C declaration: Expected end of definition. [error at 17] device_may_wakeup(dev) -----------------^ Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/pm/devices.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index 4bda8a21f5d1..6b3bfd29fd84 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -410,7 +410,7 @@ On many platforms they will gate off one or more clock sources; sometimes they will also switch off power supplies or reduce voltages. [Drivers supporting runtime PM may already have performed some or all of these steps.] -If :c:func:`device_may_wakeup(dev)` returns ``true``, the device should be +If :c:func:`device_may_wakeup()` returns ``true``, the device should be prepared for generating hardware wakeup signals to trigger a system wakeup event when the system is in the sleep state. For example, :c:func:`enable_irq_wake()` might identify GPIO signals hooked up to a switch or other external hardware, -- cgit v1.2.3-59-g8ed1b From ccf1227313cf583cad2d47b043fc3bb90438f2ca Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 29 Sep 2020 12:43:40 +0200 Subject: docs: mei.rst: fix a C expression markup Sphinx 3.x doesn't allow expressions using :c:func markup: ./Documentation/driver-api/mei/mei.rst:41: WARNING: Unparseable C cross-reference: 'close(int fd)' Invalid C declaration: Expected end of definition. [error at 5] close(int fd) -----^ So, convert it into a :c:expr. Acked-by: Tomas Winkler Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/mei/mei.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/mei/mei.rst b/Documentation/driver-api/mei/mei.rst index c800d8e5f422..71edf022a7fe 100644 --- a/Documentation/driver-api/mei/mei.rst +++ b/Documentation/driver-api/mei/mei.rst @@ -38,7 +38,7 @@ Because some of the Intel ME features can change the system configuration, the driver by default allows only a privileged user to access it. -The session is terminated calling :c:func:`close(int fd)`. +The session is terminated calling :c:expr:`close(fd)`. A code snippet for an application communicating with Intel AMTHI client: -- cgit v1.2.3-59-g8ed1b From a57c3522e816ab25c11fac0820bedb07e4727bdf Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 29 Sep 2020 12:51:00 +0200 Subject: docs: basics.rst: avoid duplicated C function declaration pci_device_id is already documented at pci.rst: ./Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'PCI/pci'. Declaration is 'pci_device_id'. The kstrtol and kstrtoul are already at kernel-api: ./Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'. Declaration is 'kstrtoul'. ./Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'. Declaration is 'kstrtol'. And the printk is already defined at printk-basics: ./Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/printk-basics'. Declaration is 'printk'. So, exclude those identifiers from basirs.rst. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/basics.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst index 63bbe3ed5e76..3e2dae954898 100644 --- a/Documentation/driver-api/basics.rst +++ b/Documentation/driver-api/basics.rst @@ -12,6 +12,8 @@ Driver device table .. kernel-doc:: include/linux/mod_devicetable.h :internal: + :no-identifiers: pci_device_id + Delaying, scheduling, and timer routines ---------------------------------------- @@ -96,9 +98,11 @@ Kernel utility functions .. kernel-doc:: include/linux/kernel.h :internal: + :no-identifiers: kstrtol kstrtoul .. kernel-doc:: kernel/printk/printk.c :export: + :no-identifiers: printk .. kernel-doc:: kernel/panic.c :export: -- cgit v1.2.3-59-g8ed1b From f41f716dc3feee0ce311b7fbbc889088796b3f06 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 5 Oct 2020 11:03:49 +0200 Subject: docs: infrastructure.rst: exclude device_link_state from device.h This is already documented at device_link.rst, causing this warning, due to a broken cross-reference: .../Documentation/driver-api/device_link.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/infrastructure'. Declaration is 'device_link_state'. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/infrastructure.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst index e38d79be4e16..683bd460e222 100644 --- a/Documentation/driver-api/infrastructure.rst +++ b/Documentation/driver-api/infrastructure.rst @@ -6,6 +6,7 @@ The Basic Device Driver-Model Structures .. kernel-doc:: include/linux/device.h :internal: + :no-identifiers: device_link_state Device Drivers Base ------------------- -- cgit v1.2.3-59-g8ed1b From 1b7743912bcf2b4a9d9c96de668542156450554f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 10 Sep 2020 09:25:14 +0200 Subject: usb: docs: document altmode register/unregister functions The typec_bus.rst asks for documentation of those two functions, but they don't exist: ./drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not found ./drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found Also, they're not declared on bus.c but, instead, at a header file (typec_altmode.h). So, add documentation for both functions at the header and change the kernel-doc markup under typec_bus.rst to point to the right place. While here, also place the documentation for both structs declared on typec_altmode.h at the rst file. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/usb/typec_bus.rst | 8 +++++++- include/linux/usb/typec_altmode.h | 16 ++++++++++++++++ 2 files changed, 23 insertions(+), 1 deletion(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/usb/typec_bus.rst b/Documentation/driver-api/usb/typec_bus.rst index 03dfa9c018b7..21c890ae17e5 100644 --- a/Documentation/driver-api/usb/typec_bus.rst +++ b/Documentation/driver-api/usb/typec_bus.rst @@ -91,10 +91,16 @@ their control. Driver API ---------- +Alternate mode structs +~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/linux/usb/typec_altmode.h + :functions: typec_altmode_driver typec_altmode_ops + Alternate mode driver registering/unregistering ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/usb/typec/bus.c +.. kernel-doc:: include/linux/usb/typec_altmode.h :functions: typec_altmode_register_driver typec_altmode_unregister_driver Alternate mode driver operations diff --git a/include/linux/usb/typec_altmode.h b/include/linux/usb/typec_altmode.h index a4b65eaa0f62..5e0a7b7647c3 100644 --- a/include/linux/usb/typec_altmode.h +++ b/include/linux/usb/typec_altmode.h @@ -152,10 +152,26 @@ struct typec_altmode_driver { #define to_altmode_driver(d) container_of(d, struct typec_altmode_driver, \ driver) +/** + * typec_altmode_register_driver - registers a USB Type-C alternate mode + * device driver + * @drv: pointer to struct typec_altmode_driver + * + * These drivers will be bind to the partner alternate mode devices. They will + * handle all SVID specific communication. + */ #define typec_altmode_register_driver(drv) \ __typec_altmode_register_driver(drv, THIS_MODULE) int __typec_altmode_register_driver(struct typec_altmode_driver *drv, struct module *module); +/** + * typec_altmode_unregister_driver - unregisters a USB Type-C alternate mode + * device driver + * @drv: pointer to struct typec_altmode_driver + * + * These drivers will be bind to the partner alternate mode devices. They will + * handle all SVID specific communication. + */ void typec_altmode_unregister_driver(struct typec_altmode_driver *drv); #define module_typec_altmode_driver(__typec_altmode_driver) \ -- cgit v1.2.3-59-g8ed1b