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 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) (limited to 'Documentation/block') 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 -- cgit v1.2.3