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

~~~~~~~~~~~~~~~~~~~~~~~

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.

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

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.

=================================================================

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.

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.

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

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

----------------------------------------------

* ``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

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