Commit 54a4c789 authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'docs/v5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

Pull documentation updates from Mauro Carvalho Chehab:
 "A series of patches addressing warnings produced by make htmldocs.
  This includes:

   - kernel-doc markup fixes

   - ReST fixes

   - Updates at the build system in order to support newer versions of
     the docs build toolchain (Sphinx)

  After this series, the number of html build warnings should reduce
  significantly, and building with Sphinx 3.1 or later should now be
  supported (although it is still recommended to use Sphinx 2.4.4).

  As agreed with Jon, I should be sending you a late pull request by the
  end of the merge window addressing remaining issues with docs build,
  as there are a number of warning fixes that depends on pull requests
  that should be happening along the merge window.

  The end goal is to have a clean htmldocs build on Kernel 5.10.

  PS. It should be noticed that Sphinx 3.0 is not currently supported,
  as it lacks support for C domain namespaces. Such feature, needed in
  order to document uAPI system calls with Sphinx 3.x, was added only on
  Sphinx 3.1"

* tag 'docs/v5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (75 commits)
  PM / devfreq: remove a duplicated kernel-doc markup
  mm/doc: fix a literal block markup
  workqueue: fix a kernel-doc warning
  docs: virt: user_mode_linux_howto_v2.rst: fix a literal block markup
  Input: sparse-keymap: add a description for @sw
  rcu/tree: docs: document bkvcache new members at struct kfree_rcu_cpu
  nl80211: docs: add a description for s1g_cap parameter
  usb: docs: document altmode register/unregister functions
  kunit: test.h: fix a bad kernel-doc markup
  drivers: core: fix kernel-doc markup for dev_err_probe()
  docs: bio: fix a kerneldoc markup
  kunit: test.h: solve kernel-doc warnings
  block: bio: fix a warning at the kernel-doc markups
  docs: powerpc: syscall64-abi.rst: fix a malformed table
  drivers: net: hamradio: fix document location
  net: appletalk: Kconfig: Fix docs location
  dt-bindings: fix references to files converted to yaml
  memblock: get rid of a :c:type leftover
  math64.h: kernel-docs: Convert some markups into normal comments
  media: uAPI: buffer.rst: remove a left-over documentation
  ...
parents 93f3d8f5 3e2ac979
.. SPDX-License-Identifier: GPL-2.0 .. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt> .. include:: <isonum.txt>
.. |struct cpufreq_policy| replace:: :c:type:`struct cpufreq_policy <cpufreq_policy>`
.. |intel_pstate| replace:: :doc:`intel_pstate <intel_pstate>` .. |intel_pstate| replace:: :doc:`intel_pstate <intel_pstate>`
======================= =======================
...@@ -92,16 +91,16 @@ control the P-state of multiple CPUs at the same time and writing to it affects ...@@ -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. all of those CPUs simultaneously.
Sets of CPUs sharing hardware P-state control interfaces are represented by Sets of CPUs sharing hardware P-state control interfaces are represented by
``CPUFreq`` as |struct cpufreq_policy| objects. For consistency, ``CPUFreq`` as struct cpufreq_policy objects. For consistency,
|struct cpufreq_policy| is also used when there is only one CPU in the given struct cpufreq_policy is also used when there is only one CPU in the given
set. 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 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 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. of its user space interface is based on the policy concept.
......
...@@ -154,17 +154,11 @@ Configurations for driver ...@@ -154,17 +154,11 @@ Configurations for driver
Only a block device driver cares about these configurations. A block device Only a block device driver cares about these configurations. A block device
driver uses ``register_pstore_blk`` to register to pstore/blk. driver uses ``register_pstore_blk`` to register to pstore/blk.
.. kernel-doc:: fs/pstore/blk.c
:identifiers: register_pstore_blk
A non-block device driver uses ``register_pstore_device`` with A non-block device driver uses ``register_pstore_device`` with
``struct pstore_device_info`` to register to pstore/blk. ``struct pstore_device_info`` to register to pstore/blk.
.. kernel-doc:: fs/pstore/blk.c .. kernel-doc:: fs/pstore/blk.c
:identifiers: register_pstore_device :export:
.. kernel-doc:: include/linux/pstore_blk.h
:identifiers: pstore_device_info
Compression and header Compression and header
---------------------- ----------------------
...@@ -237,7 +231,7 @@ For developer reference, here are all the important structures and APIs: ...@@ -237,7 +231,7 @@ For developer reference, here are all the important structures and APIs:
:internal: :internal:
.. kernel-doc:: fs/pstore/blk.c .. kernel-doc:: fs/pstore/blk.c
:export: :internal:
.. kernel-doc:: include/linux/pstore_blk.h .. kernel-doc:: include/linux/pstore_blk.h
:internal: :internal:
...@@ -63,10 +63,10 @@ Software staging queues ...@@ -63,10 +63,10 @@ Software staging queues
~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
The block IO subsystem adds requests in the 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 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 block layer through the data structure struct bio. The block layer
will then build a new structure from it, the struct :c:type:`request` that will 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 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. 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. ...@@ -102,7 +102,7 @@ hardware queue will be drained in sequence according to their mapping.
Hardware dispatch queues 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 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 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 low level device driver taking ownership of the request. To run this queue, the
...@@ -110,9 +110,9 @@ block layer removes requests from the associated software queues and tries to ...@@ -110,9 +110,9 @@ block layer removes requests from the associated software queues and tries to
dispatch to the hardware. dispatch to the hardware.
If it's not possible to send the requests directly to hardware, they will be If it's not possible to send the requests directly to hardware, they will be
added to a linked list (:c:type:`hctx->dispatch`) of requests. Then, added to a linked list (``hctx->dispatch``) of requests. Then,
next time the block layer runs a queue, it will send the requests laying at the next time the block layer runs a queue, it will send the requests laying at the
:c:type:`dispatch` list first, to ensure a fairness dispatch with those ``dispatch`` list first, to ensure a fairness dispatch with those
requests that were ready to be sent first. The number of hardware queues requests that were ready to be sent first. The number of hardware queues
depends on the number of hardware contexts supported by the hardware and its depends on the number of hardware contexts supported by the hardware and its
device driver, but it will not be more than the number of cores of the system. device driver, but it will not be more than the number of cores of the system.
......
...@@ -52,7 +52,7 @@ Constraints and notes ...@@ -52,7 +52,7 @@ Constraints and notes
Design 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 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 encryption context from the upper layers (like the fs layer) to the
device driver to act upon. device driver to act upon.
...@@ -85,7 +85,7 @@ blk-mq changes, other block layer changes and blk-crypto-fallback ...@@ -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 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 for the request. This ``keyslot`` is the keyslot into which the
``bi_crypt_context`` has been programmed in the KSM of the ``request_queue`` ``bi_crypt_context`` has been programmed in the KSM of the ``request_queue``
that this request is being sent to. that this request is being sent to.
...@@ -118,7 +118,7 @@ of the algorithm being used adheres to spec and functions correctly). ...@@ -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 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 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 ``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 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_manager, and obtain a keyslot, which it stores in its newly added
``keyslot`` field. This keyslot is released when the request is completed. ``keyslot`` field. This keyslot is released when the request is completed.
...@@ -188,7 +188,7 @@ keyslots supported by the hardware. ...@@ -188,7 +188,7 @@ keyslots supported by the hardware.
The device driver also needs to tell the KSM how to actually manipulate the 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 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 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``. must fill up after initing the ``blk_keyslot_manager``.
The KSM also handles runtime power management for the device when applicable The KSM also handles runtime power management for the device when applicable
......
...@@ -47,9 +47,68 @@ extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', ...@@ -47,9 +47,68 @@ extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
# #
if major >= 3: if major >= 3:
sys.stderr.write('''WARNING: The kernel documentation build process sys.stderr.write('''WARNING: The kernel documentation build process
does not work correctly with Sphinx v3.0 and above. Expect errors support for Sphinx v3.0 and above is brand new. Be prepared for
in the generated output. possible issues in the generated output.
''') ''')
if minor > 0 or patch >= 2:
# Sphinx c function parser is more pedantic with regards to type
# checking. Due to that, having macros at c:function cause problems.
# Those needed to be scaped by using c_id_attributes[] array
c_id_attributes = [
# GCC Compiler types not parsed by Sphinx:
"__restrict__",
# include/linux/compiler_types.h:
"__iomem",
"__kernel",
"noinstr",
"notrace",
"__percpu",
"__rcu",
"__user",
# include/linux/compiler_attributes.h:
"__alias",
"__aligned",
"__aligned_largest",
"__always_inline",
"__assume_aligned",
"__cold",
"__attribute_const__",
"__copy",
"__pure",
"__designated_init",
"__visible",
"__printf",
"__scanf",
"__gnu_inline",
"__malloc",
"__mode",
"__no_caller_saved_registers",
"__noclone",
"__nonstring",
"__noreturn",
"__packed",
"__pure",
"__section",
"__always_unused",
"__maybe_unused",
"__used",
"__weak",
"noinline",
# include/linux/memblock.h:
"__init_memblock",
"__meminit",
# include/linux/init.h:
"__init",
"__ref",
# include/linux/linkage.h:
"asmlinkage",
]
else: else:
extensions.append('cdomain') extensions.append('cdomain')
......
...@@ -419,6 +419,7 @@ functions which are exported. ...@@ -419,6 +419,7 @@ functions which are exported.
.. kernel-doc:: kernel/irq/manage.c .. kernel-doc:: kernel/irq/manage.c
.. kernel-doc:: kernel/irq/chip.c .. kernel-doc:: kernel/irq/chip.c
:export:
Internal Functions Provided Internal Functions Provided
=========================== ===========================
...@@ -431,6 +432,7 @@ functions. ...@@ -431,6 +432,7 @@ functions.
.. kernel-doc:: kernel/irq/handle.c .. kernel-doc:: kernel/irq/handle.c
.. kernel-doc:: kernel/irq/chip.c .. kernel-doc:: kernel/irq/chip.c
:internal:
Credits Credits
======= =======
......
...@@ -231,12 +231,6 @@ Refer to the file kernel/module.c for more information. ...@@ -231,12 +231,6 @@ Refer to the file kernel/module.c for more information.
Hardware Interfaces Hardware Interfaces
=================== ===================
Interrupt Handling
------------------
.. kernel-doc:: kernel/irq/manage.c
:export:
DMA Channels DMA Channels
------------ ------------
......
...@@ -396,3 +396,5 @@ Kernel Inline Documentations Reference ...@@ -396,3 +396,5 @@ Kernel Inline Documentations Reference
====================================== ======================================
.. kernel-doc:: include/linux/workqueue.h .. kernel-doc:: include/linux/workqueue.h
.. kernel-doc:: kernel/workqueue.c
...@@ -726,7 +726,7 @@ The kernel debugger is organized into a number of components: ...@@ -726,7 +726,7 @@ The kernel debugger is organized into a number of components:
- contains an arch-specific trap catcher which invokes - contains an arch-specific trap catcher which invokes
kgdb_handle_exception() to start kgdb about doing its work kgdb_handle_exception() to start kgdb about doing its work
- translation to and from gdb specific packet format to :c:type:`pt_regs` - translation to and from gdb specific packet format to struct pt_regs
- Registration and unregistration of architecture specific trap - Registration and unregistration of architecture specific trap
hooks hooks
...@@ -846,7 +846,7 @@ invokes a callback in the serial core which in turn uses the callback in ...@@ -846,7 +846,7 @@ invokes a callback in the serial core which in turn uses the callback in
the UART driver. the UART driver.
When using kgdboc with a UART, the UART driver must implement two When using kgdboc with a UART, the UART driver must implement two
callbacks in the :c:type:`struct uart_ops <uart_ops>`. callbacks in the struct uart_ops.
Example from ``drivers/8250.c``:: Example from ``drivers/8250.c``::
...@@ -875,7 +875,7 @@ kernel when ``CONFIG_KDB_KEYBOARD=y`` is set in the kernel configuration. ...@@ -875,7 +875,7 @@ kernel when ``CONFIG_KDB_KEYBOARD=y`` is set in the kernel configuration.
The core polled keyboard driver for PS/2 type keyboards is in The core polled keyboard driver for PS/2 type keyboards is in
``drivers/char/kdb_keyboard.c``. This driver is hooked into the debug core ``drivers/char/kdb_keyboard.c``. This driver is hooked into the debug core
when kgdboc populates the callback in the array called when kgdboc populates the callback in the array called
:c:type:`kdb_poll_funcs[]`. The kdb_get_kbd_char() is the top-level :c:expr:`kdb_poll_funcs[]`. The kdb_get_kbd_char() is the top-level
function which polls hardware for single character input. function which polls hardware for single character input.
kgdboc and kms kgdboc and kms
......
...@@ -37,7 +37,7 @@ Optional nodes: ...@@ -37,7 +37,7 @@ Optional nodes:
supports a single port with a single endpoint. supports a single port with a single endpoint.
- See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt for connecting Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml for connecting
tfp410 DVI encoder or lcd panel to lcdc tfp410 DVI encoder or lcd panel to lcdc
[1] There is an errata about AM335x color wiring. For 16-bit color mode [1] There is an errata about AM335x color wiring. For 16-bit color mode
......
...@@ -69,7 +69,7 @@ The following are mandatory properties for the K3 AM65x and J721E SoCs only: ...@@ -69,7 +69,7 @@ The following are mandatory properties for the K3 AM65x and J721E SoCs only:
the interrupt routes between the IP and the main GIC the interrupt routes between the IP and the main GIC
controllers. See the following binding for additional controllers. See the following binding for additional
details, details,
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
Child Nodes: Child Nodes:
============ ============
......
...@@ -56,7 +56,7 @@ Optional Connector Properties: ...@@ -56,7 +56,7 @@ Optional Connector Properties:
instead of using the autodetection mechnism. Please look at instead of using the autodetection mechnism. Please look at
[1] for more information. [1] for more information.
[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt. [1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml.
Example - three input sources: Example - three input sources:
#include <dt-bindings/display/sdtv-standards.h> #include <dt-bindings/display/sdtv-standards.h>
......
...@@ -14,7 +14,7 @@ description: | ...@@ -14,7 +14,7 @@ description: |
Google's ChromeOS EC PWM is a simple PWM attached to the Embedded Controller Google's ChromeOS EC PWM is a simple PWM attached to the Embedded Controller
(EC) and controlled via a host-command interface. (EC) and controlled via a host-command interface.
An EC PWM node should be only found as a sub-node of the EC node (see An EC PWM node should be only found as a sub-node of the EC node (see
Documentation/devicetree/bindings/mfd/cros-ec.txt). Documentation/devicetree/bindings/mfd/google,cros-ec.yaml).
properties: properties:
compatible: compatible:
......
...@@ -20,7 +20,7 @@ description: | ...@@ -20,7 +20,7 @@ description: |
present and this subnode may contain children that designate regulator present and this subnode may contain children that designate regulator
resources. resources.
Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
for information on the regulator subnodes that can exist under the for information on the regulator subnodes that can exist under the
rpm_requests. rpm_requests.
......
...@@ -13,7 +13,7 @@ description: | ...@@ -13,7 +13,7 @@ description: |
Google's ChromeOS EC codec is a digital mic codec provided by the Google's ChromeOS EC codec is a digital mic codec provided by the
Embedded Controller (EC) and is controlled via a host-command interface. Embedded Controller (EC) and is controlled via a host-command interface.
An EC codec node should only be found as a sub-node of the EC node (see An EC codec node should only be found as a sub-node of the EC node (see
Documentation/devicetree/bindings/mfd/cros-ec.txt). Documentation/devicetree/bindings/mfd/google,cros-ec.yaml).
properties: properties:
compatible: compatible:
......
...@@ -490,6 +490,14 @@ identifiers: *[ function/type ...]* ...@@ -490,6 +490,14 @@ identifiers: *[ function/type ...]*
.. kernel-doc:: lib/idr.c .. kernel-doc:: lib/idr.c
:identifiers: :identifiers:
no-identifiers: *[ function/type ...]*
Exclude documentation for each *function* and *type* in *source*.
Example::
.. kernel-doc:: lib/bitmap.c
:no-identifiers: bitmap_parselist
functions: *[ function/type ...]* functions: *[ function/type ...]*
This is an alias of the 'identifiers' directive and deprecated. This is an alias of the 'identifiers' directive and deprecated.
......
...@@ -12,6 +12,8 @@ Driver device table ...@@ -12,6 +12,8 @@ Driver device table
.. kernel-doc:: include/linux/mod_devicetable.h .. kernel-doc:: include/linux/mod_devicetable.h
:internal: :internal:
:no-identifiers: pci_device_id
Delaying, scheduling, and timer routines Delaying, scheduling, and timer routines
---------------------------------------- ----------------------------------------
...@@ -55,15 +57,6 @@ High-resolution timers ...@@ -55,15 +57,6 @@ High-resolution timers
.. kernel-doc:: kernel/time/hrtimer.c .. kernel-doc:: kernel/time/hrtimer.c
:export: :export:
Workqueues and Kevents
----------------------
.. kernel-doc:: include/linux/workqueue.h
:internal:
.. kernel-doc:: kernel/workqueue.c
:export:
Internal Functions Internal Functions
------------------ ------------------
...@@ -105,19 +98,15 @@ Kernel utility functions ...@@ -105,19 +98,15 @@ Kernel utility functions
.. kernel-doc:: include/linux/kernel.h .. kernel-doc:: include/linux/kernel.h
:internal: :internal:
:no-identifiers: kstrtol kstrtoul
.. kernel-doc:: kernel/printk/printk.c .. kernel-doc:: kernel/printk/printk.c
:export: :export:
:no-identifiers: printk
.. kernel-doc:: kernel/panic.c .. kernel-doc:: kernel/panic.c
:export: :export:
.. kernel-doc:: kernel/rcu/tree.c
:export:
.. kernel-doc:: kernel/rcu/update.c
:export:
.. kernel-doc:: include/linux/overflow.h .. kernel-doc:: include/linux/overflow.h
:internal: :internal:
......
.. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain <dev_pm_domain>`
.. |struct generic_pm_domain| replace:: :c:type:`struct generic_pm_domain <generic_pm_domain>`
.. _device_link: .. _device_link:
============ ============
...@@ -166,7 +162,7 @@ Examples ...@@ -166,7 +162,7 @@ Examples
is the same as if the MMU was the parent of the master device. 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 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 however these are not independent devices that happen to share a power
switch, but rather the MMU device serves the busmaster device and is switch, but rather the MMU device serves the busmaster device and is
useless without it. A device link creates a synthetic hierarchical useless without it. A device link creates a synthetic hierarchical
...@@ -202,7 +198,7 @@ Examples ...@@ -202,7 +198,7 @@ Examples
Alternatives 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 class or device type callbacks. It is intended for devices sharing
a single on/off switch, however it does not guarantee a specific a single on/off switch, however it does not guarantee a specific
suspend/resume ordering, this needs to be implemented separately. suspend/resume ordering, this needs to be implemented separately.
...@@ -211,7 +207,7 @@ Alternatives ...@@ -211,7 +207,7 @@ Alternatives
suspended. Furthermore it cannot be used to enforce a specific shutdown suspended. Furthermore it cannot be used to enforce a specific shutdown
ordering or a driver presence dependency. 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 device link and does not allow for shutdown ordering or driver presence
dependencies. It also cannot be used on ACPI systems. dependencies. It also cannot be used on ACPI systems.
...@@ -321,5 +317,4 @@ State machine ...@@ -321,5 +317,4 @@ State machine
API API
=== ===
.. kernel-doc:: drivers/base/core.c See device_link_add(), device_link_del() and device_link_remove().
:functions: device_link_add device_link_del device_link_remove
...@@ -4,8 +4,8 @@ FPGA Bridge ...@@ -4,8 +4,8 @@ FPGA Bridge
API to implement a new FPGA bridge API to implement a new FPGA bridge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* struct :c:type:`fpga_bridge` — The FPGA Bridge structure * struct fpga_bridge — The FPGA Bridge structure
* struct :c:type:`fpga_bridge_ops` — Low level Bridge driver ops * struct fpga_bridge_ops — Low level Bridge driver ops
* devm_fpga_bridge_create() — Allocate and init a bridge struct * devm_fpga_bridge_create() — Allocate and init a bridge struct
* fpga_bridge_register() — Register a bridge * fpga_bridge_register() — Register a bridge
* fpga_bridge_unregister() — Unregister a bridge * fpga_bridge_unregister() — Unregister a bridge
......
...@@ -101,9 +101,9 @@ in state. ...@@ -101,9 +101,9 @@ in state.
API for implementing a new FPGA Manager driver 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 :c:type:`fpga_manager` — the FPGA manager struct * struct fpga_manager — the FPGA manager struct
* struct :c:type:`fpga_manager_ops` — Low level FPGA manager driver ops * struct fpga_manager_ops — Low level FPGA manager driver ops
* devm_fpga_mgr_create() — Allocate and init a manager struct * devm_fpga_mgr_create() — Allocate and init a manager struct
* fpga_mgr_register() — Register an FPGA manager * fpga_mgr_register() — Register an FPGA manager
* fpga_mgr_unregister() — Unregister an FPGA manager * fpga_mgr_unregister() — Unregister an FPGA manager
......
...@@ -15,7 +15,7 @@ the FPGA manager and bridges. It will: ...@@ -15,7 +15,7 @@ the FPGA manager and bridges. It will:
* lock the mutex of the region's FPGA manager * lock the mutex of the region's FPGA manager
* build a list of FPGA bridges if a method has been specified to do so * build a list of FPGA bridges if a method has been specified to do so
* disable the bridges * 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 * re-enable the bridges
* release the locks * release the locks
......
...@@ -45,7 +45,7 @@ An example of usage can be seen in the probe function of [#f2]_. ...@@ -45,7 +45,7 @@ An example of usage can be seen in the probe function of [#f2]_.
API to add a new FPGA region 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 * devm_fpga_region_create() — Allocate and init a region struct
* fpga_region_register() — Register an FPGA region * fpga_region_register() — Register an FPGA region
* fpga_region_unregister() — Unregister an FPGA region * fpga_region_unregister() — Unregister an FPGA region
...@@ -61,9 +61,9 @@ during the region's probe function. ...@@ -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 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 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 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. 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 * fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a
......
...@@ -2,7 +2,7 @@ ...@@ -2,7 +2,7 @@
Buffers 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 * :c:func:`iio_validate_scan_mask_onehot` — Validates that exactly one channel
is selected is selected
* :c:func:`iio_buffer_get` — Grab a reference to the buffer * :c:func:`iio_buffer_get` — Grab a reference to the buffer
......
...@@ -10,7 +10,7 @@ applications manipulating sensors. The implementation can be found under ...@@ -10,7 +10,7 @@ applications manipulating sensors. The implementation can be found under
Industrial I/O Devices 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_alloc() - allocate an :c:type:`iio_dev` from a driver
* iio_device_free() - free 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 * iio_device_register() - register a device with the IIO subsystem
...@@ -66,7 +66,7 @@ Common attributes are: ...@@ -66,7 +66,7 @@ Common attributes are:
IIO device channels 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 An IIO device channel is a representation of a data channel. An IIO device can
have one or multiple channels. For example: have one or multiple channels. For example:
...@@ -77,7 +77,7 @@ 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 * an accelerometer can have up to 3 channels representing acceleration on X, Y
and Z axes. 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 A thermometer driver for the temperature sensor in the example above would
have to describe its channel as follows:: have to describe its channel as follows::
......
...@@ -8,7 +8,7 @@ software buffer for data. The implementation can be found under ...@@ -8,7 +8,7 @@ software buffer for data. The implementation can be found under
:file:`drivers/iio/buffer/hw-consumer.c` :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_alloc` — Allocate IIO hardware consumer
* :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer * :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer
* :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer * :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer
......
...@@ -10,7 +10,7 @@ IIO triggered buffer setup ...@@ -10,7 +10,7 @@ IIO triggered buffer setup
* :c:func:`iio_triggered_buffer_setup` — Setup triggered buffer and pollfunc * :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_cleanup` — Free resources allocated by
:c:func:`iio_triggered_buffer_setup` :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:: A typical triggered buffer setup looks like this::
......
...@@ -2,7 +2,7 @@ ...@@ -2,7 +2,7 @@
Triggers 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_alloc` — Resource-managed iio_trigger_alloc
* :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register * :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register
iio_trigger_unregister 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:: ...@@ -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 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: Notice that a trigger has a set of operations attached:
......
...@@ -27,7 +27,6 @@ available subsections can be seen below. ...@@ -27,7 +27,6 @@ available subsections can be seen below.
component component
message-based message-based
infiniband infiniband
sound
frame-buffer frame-buffer
regulator regulator
iio/index iio/index
......
...@@ -6,6 +6,7 @@ The Basic Device Driver-Model Structures ...@@ -6,6 +6,7 @@ The Basic Device Driver-Model Structures
.. kernel-doc:: include/linux/device.h .. kernel-doc:: include/linux/device.h
:internal: :internal:
:no-identifiers: device_link_state
Device Drivers Base Device Drivers Base
------------------- -------------------
...@@ -28,9 +29,6 @@ Device Drivers Base ...@@ -28,9 +29,6 @@ Device Drivers Base
.. kernel-doc:: drivers/base/node.c .. kernel-doc:: drivers/base/node.c
:internal: :internal:
.. kernel-doc:: drivers/base/firmware_loader/main.c
:export:
.. kernel-doc:: drivers/base/transport_class.c .. kernel-doc:: drivers/base/transport_class.c
:export: :export:
......
...@@ -508,7 +508,7 @@ also complete commands. ...@@ -508,7 +508,7 @@ also complete commands.
2. ATA_QCFLAG_ACTIVE is cleared from qc->flags. 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 callback is not zero. Completion is short circuited and
:c:func:`ata_qc_complete` returns. :c:func:`ata_qc_complete` returns.
......
...@@ -98,7 +98,7 @@ Implementing the Low-Level CEC Adapter ...@@ -98,7 +98,7 @@ Implementing the Low-Level CEC Adapter
The following low-level adapter operations have to be implemented in The following low-level adapter operations have to be implemented in
your driver: your driver:
.. c:type:: struct cec_adap_ops .. c:struct:: cec_adap_ops
.. code-block:: none .. code-block:: none
......
...@@ -125,7 +125,7 @@ responsible for tuning the device. It supports multiple algorithms to ...@@ -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`. 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 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, ``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``, 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|, 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``. ...@@ -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 a third type (``DVBFE_ALGO_CUSTOM``), in order to allow the driver to
define its own hardware-assisted algorithm. Very few hardware need to define its own hardware-assisted algorithm. Very few hardware need to
use it nowadays. Using ``DVBFE_ALGO_CUSTOM`` require to provide other 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 Attaching frontend driver to the bridge driver
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
......
...@@ -36,7 +36,7 @@ pad to a sink pad. ...@@ -36,7 +36,7 @@ pad to a sink pad.
Media device 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``. instance, defined in ``include/media/media-device.h``.
Allocation of the structure is handled by the media device driver, usually by 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 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()`. ...@@ -49,7 +49,7 @@ and unregistered by calling :c:func:`media_device_unregister()`.
Entities 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 instance, defined in ``include/media/media-entity.h``. The structure is usually
embedded into a higher-level structure, such as embedded into a higher-level structure, such as
:c:type:`v4l2_subdev` or :c:type:`video_device` :c:type:`v4l2_subdev` or :c:type:`video_device`
...@@ -67,10 +67,10 @@ Interfaces ...@@ -67,10 +67,10 @@ Interfaces
^^^^^^^^^^ ^^^^^^^^^^
Interfaces are represented by a 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 ``include/media/media-entity.h``. Currently, only one type of interface is
defined: a device node. Such interfaces are represented by a 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 Drivers initialize and create device node interfaces by calling
:c:func:`media_devnode_create()` :c:func:`media_devnode_create()`
...@@ -79,7 +79,7 @@ and remove them by calling: ...@@ -79,7 +79,7 @@ and remove them by calling:
Pads 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 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 pads array managed by the entity driver. Drivers usually embed the array in
a driver-specific structure. a driver-specific structure.
...@@ -87,8 +87,8 @@ 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 Pads are identified by their entity and their 0-based index in the pads
array. array.
Both information are stored in the struct :c:type:`media_pad`, Both information are stored in the struct media_pad,
making the struct :c:type:`media_pad` pointer the canonical way making the struct media_pad pointer the canonical way
to store and pass link references. to store and pass link references.
Pads have flags that describe the pad capabilities and state. Pads have flags that describe the pad capabilities and state.
...@@ -104,7 +104,7 @@ 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
^^^^^ ^^^^^
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: defined in ``include/media/media-entity.h``. There are two types of links:
**1. pad to pad links**: **1. pad to pad links**:
...@@ -187,7 +187,7 @@ Use count and power handling ...@@ -187,7 +187,7 @@ Use count and power handling
Due to the wide differences between drivers regarding power management Due to the wide differences between drivers regarding power management
needs, the media controller does not implement power management. However, 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 field that media drivers
can use to track the number of users of every entity for power management can use to track the number of users of every entity for power management
needs. needs.
...@@ -213,11 +213,11 @@ prevent link states from being modified during streaming by calling ...@@ -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 The function will mark all entities connected to the given entity through
enabled links, either directly or indirectly, as streaming. 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. 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 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. pipe field.
Calls to :c:func:`media_pipeline_start()` can be nested. Calls to :c:func:`media_pipeline_start()` can be nested.
......
...@@ -27,7 +27,7 @@ V4L2 specification with respect to controls in a central place. And to make ...@@ -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. life as easy as possible for the driver developer.
Note that the control framework relies on the presence of a struct 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. sub-device drivers.
......
...@@ -67,7 +67,7 @@ You should also set these fields of :c:type:`video_device`: ...@@ -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 file operation is called this lock will be taken by the core and released
afterwards. See the next section for more details. 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. associated with this device node.
If queue is not ``NULL``, and queue->lock is not ``NULL``, then queue->lock If queue is not ``NULL``, and queue->lock is not ``NULL``, then queue->lock
is used for the queuing ioctls (``VIDIOC_REQBUFS``, ``CREATE_BUFS``, 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`: ...@@ -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 - :c:type:`video_device`->prio: keeps track of the priorities. Used to
implement ``VIDIOC_G_PRIORITY`` and ``VIDIOC_S_PRIORITY``. 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 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 (group of) device node(s), then you can point it to your own struct
:c:type:`v4l2_prio_state`. :c:type:`v4l2_prio_state`.
...@@ -95,7 +95,7 @@ You should also set these fields of :c:type:`video_device`: ...@@ -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 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 (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 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. 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 If you use :c:type:`v4l2_ioctl_ops`, then you should set
...@@ -138,7 +138,7 @@ ioctls and locking ...@@ -138,7 +138,7 @@ ioctls and locking
------------------ ------------------
The V4L core provides optional locking services. The main service is the 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 If you set this pointer, then that will be used by unlocked_ioctl to
serialize all ioctls. serialize all ioctls.
......
...@@ -3,7 +3,7 @@ ...@@ -3,7 +3,7 @@
V4L2 device instance 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 Very simple devices can just allocate this struct, but most of the time you
would embed this struct inside a larger struct. would embed this struct inside a larger struct.
...@@ -18,9 +18,9 @@ dev->driver_data field is ``NULL``, it will be linked to ...@@ -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 Drivers that want integration with the media device framework need to set
dev->driver_data manually to point to the driver-specific device structure 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. ``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. properly initialized and registered :c:type:`media_device` instance.
If :c:type:`v4l2_dev <v4l2_device>`\ ->name is empty then it will be set to a If :c:type:`v4l2_dev <v4l2_device>`\ ->name is empty then it will be set to a
......
...@@ -44,18 +44,18 @@ such objects. ...@@ -44,18 +44,18 @@ such objects.
So to summarize: 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. 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. (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 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. 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 ``merge()`` and ``replace()`` callbacks which drivers can set. These
callbacks are called when a new event is raised and there is no more room. callbacks are called when a new event is raised and there is no more room.
......
...@@ -3,11 +3,11 @@ ...@@ -3,11 +3,11 @@
V4L2 File handlers 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. data that is used by the V4L2 framework.
.. attention:: .. 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 since it is also used to implement priority handling
(:ref:`VIDIOC_G_PRIORITY`). (:ref:`VIDIOC_G_PRIORITY`).
...@@ -16,11 +16,11 @@ whether a driver uses :c:type:`v4l2_fh` as its ``file->private_data`` pointer ...@@ -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. 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. 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()`` structure and ``file->private_data`` is set to it in the driver's ``open()``
function by the driver. 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: structure. In that case you should call:
#) :c:func:`v4l2_fh_init` and :c:func:`v4l2_fh_add` in ``open()`` #) :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: ...@@ -102,18 +102,18 @@ Below is a short description of the :c:type:`v4l2_fh` functions used:
memory can be freed. memory can be freed.
If struct :c:type:`v4l2_fh` is not embedded, then you can use these helper functions: If struct v4l2_fh is not embedded, then you can use these helper functions:
:c:func:`v4l2_fh_open <v4l2_fh_open>` :c:func:`v4l2_fh_open <v4l2_fh_open>`
(struct file \*filp) (struct file \*filp)
- This allocates a struct :c:type:`v4l2_fh`, initializes it and adds it to - This allocates a struct v4l2_fh, initializes it and adds it to
the struct :c:type:`video_device` associated with the file struct. the struct video_device associated with the file struct.
:c:func:`v4l2_fh_release <v4l2_fh_release>` :c:func:`v4l2_fh_release <v4l2_fh_release>`
(struct file \*filp) (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. file struct, uninitialised the :c:type:`v4l2_fh` and frees it.
These two functions can be plugged into the v4l2_file_operation's ``open()`` These two functions can be plugged into the v4l2_file_operation's ``open()``
......
...@@ -110,7 +110,7 @@ pads: ...@@ -110,7 +110,7 @@ pads:
err = media_entity_pads_init(&sd->entity, npads, pads); err = media_entity_pads_init(&sd->entity, npads, pads);
The pads array must have been previously initialized. There is no need to 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. revision field must be initialized if needed.
A reference to the entity will be automatically acquired/released when the A reference to the entity will be automatically acquired/released when the
......
...@@ -38,7 +38,7 @@ Because some of the Intel ME features can change the system ...@@ -38,7 +38,7 @@ Because some of the Intel ME features can change the system
configuration, the driver by default allows only a privileged configuration, the driver by default allows only a privileged
user to access it. 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: A code snippet for an application communicating with Intel AMTHI client:
......
This diff is collapsed.
.. SPDX-License-Identifier: GPL-2.0 .. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt> .. include:: <isonum.txt>
.. |struct dev_pm_ops| replace:: :c:type:`struct dev_pm_ops <dev_pm_ops>`
.. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain <dev_pm_domain>`
.. |struct bus_type| replace:: :c:type:`struct bus_type <bus_type>`
.. |struct device_type| replace:: :c:type:`struct device_type <device_type>`
.. |struct class| replace:: :c:type:`struct class <class>`
.. |struct wakeup_source| replace:: :c:type:`struct wakeup_source <wakeup_source>`
.. |struct device| replace:: :c:type:`struct device <device>`
.. _driverapi_pm_devices: .. _driverapi_pm_devices:
============================== ==============================
...@@ -107,7 +99,7 @@ Device Power Management Operations ...@@ -107,7 +99,7 @@ Device Power Management Operations
Device power management operations, at the subsystem level as well as at the 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 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 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 sufficient to remember that the last three methods are specific to runtime power
management while the remaining ones are used during system-wide power management while the remaining ones are used during system-wide power
...@@ -115,7 +107,7 @@ transitions. ...@@ -115,7 +107,7 @@ transitions.
There also is a deprecated "old" or "legacy" interface for power management There also is a deprecated "old" or "legacy" interface for power management
operations available at least for some subsystems. This approach does not use 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 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 in this document, so please refer directly to the source code for more
information about it. information about it.
...@@ -125,9 +117,9 @@ Subsystem-Level Methods ...@@ -125,9 +117,9 @@ Subsystem-Level Methods
----------------------- -----------------------
The core methods to suspend and resume devices reside in 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_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 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 device_type and struct class. They are mostly of interest to the
people writing infrastructure for platforms and buses, like PCI or USB, or 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 type and device class drivers. They also are relevant to the writers of
device drivers whose subsystems (PM domains, device types, device classes and 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 ...@@ -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 driver) can physically support wakeup events. The
:c:func:`device_set_wakeup_capable()` routine affects this flag. 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 :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 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 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 devices (i.e. devices whose :c:member:`can_wakeup` flags are set) and is created
...@@ -418,7 +410,7 @@ On many platforms they will gate off one or more clock sources; sometimes they ...@@ -418,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 will also switch off power supplies or reduce voltages. [Drivers supporting
runtime PM may already have performed some or all of these steps.] 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 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()` 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, might identify GPIO signals hooked up to a switch or other external hardware,
...@@ -713,8 +705,8 @@ nested inside another power domain. The nested domain is referred to as the ...@@ -713,8 +705,8 @@ nested inside another power domain. The nested domain is referred to as the
sub-domain of the parent domain. sub-domain of the parent domain.
Support for power domains is provided through the :c:member:`pm_domain` field of 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 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 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 of power management callbacks analogous to the subsystem-level and device driver
callbacks that are executed for the given device during all power transitions, callbacks that are executed for the given device during all power transitions,
instead of the respective subsystem-level callbacks. Specifically, if a instead of the respective subsystem-level callbacks. Specifically, if a
......
...@@ -116,7 +116,7 @@ core, providing operations structures to the core. A notifier interface ...@@ -116,7 +116,7 @@ core, providing operations structures to the core. A notifier interface
allows error conditions to be reported to the core. allows error conditions to be reported to the core.
Registration should be triggered by explicit setup done by the platform, 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. containing constraint and supply information.
Machine interface Machine interface
...@@ -144,7 +144,7 @@ a given system, for example supporting higher supply voltages than the ...@@ -144,7 +144,7 @@ a given system, for example supporting higher supply voltages than the
consumers are rated for. consumers are rated for.
This is done at driver registration time` by providing a 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 The constraints may also specify an initial configuration for the
regulator in the constraints, which is particularly useful for use with regulator in the constraints, which is particularly useful for use with
......
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:
...@@ -41,18 +41,6 @@ iSCSI boot information ...@@ -41,18 +41,6 @@ iSCSI boot information
.. kernel-doc:: drivers/scsi/iscsi_boot_sysfs.c .. kernel-doc:: drivers/scsi/iscsi_boot_sysfs.c
:export: :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 iSCSI TCP interfaces
==================== ====================
......
...@@ -47,7 +47,7 @@ called USB Request Block, or URB for short. ...@@ -47,7 +47,7 @@ called USB Request Block, or URB for short.
The URB structure The URB structure
================= =================
Some of the fields in struct :c:type:`urb` are:: Some of the fields in struct urb are::
struct urb struct urb
{ {
......
...@@ -176,9 +176,9 @@ Kernel Mode Gadget API ...@@ -176,9 +176,9 @@ Kernel Mode Gadget API
Gadget drivers declare themselves through a struct Gadget drivers declare themselves through a struct
:c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration :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 for a struct usb_gadget. The response to a set_configuration usually
involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by involves enabling one or more of the struct usb_ep objects exposed by
the gadget, and submitting one or more struct :c:type:`usb_request` buffers to the gadget, and submitting one or more struct usb_request buffers to
transfer data. Understand those four data types, and their operations, transfer data. Understand those four data types, and their operations,
and you will understand how this API works. and you will understand how this API works.
...@@ -339,8 +339,8 @@ multi-configuration devices (also more than one function, but not ...@@ -339,8 +339,8 @@ multi-configuration devices (also more than one function, but not
necessarily sharing a given configuration). There is however an optional necessarily sharing a given configuration). There is however an optional
framework which makes it easier to reuse and combine functions. framework which makes it easier to reuse and combine functions.
Devices using this framework provide a struct :c:type:`usb_composite_driver`, Devices using this framework provide a struct usb_composite_driver,
which in turn provides one or more struct :c:type:`usb_configuration` which in turn provides one or more struct usb_configuration
instances. Each such configuration includes at least one struct instances. Each such configuration includes at least one struct
:c:type:`usb_function`, which packages a user visible role such as "network :c:type:`usb_function`, which packages a user visible role such as "network
link" or "mass storage device". Management functions may also exist, link" or "mass storage device". Management functions may also exist,
......
...@@ -122,7 +122,7 @@ and their quirks, might have a MODULE_DEVICE_TABLE like this:: ...@@ -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 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 well as to the module management subsystem. Not all, though: some driver
frameworks connect using interfaces layered over USB, and so they won't 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 Drivers that connect directly to the USB subsystem should be declared
something like this:: something like this::
......
...@@ -91,10 +91,16 @@ their control. ...@@ -91,10 +91,16 @@ their control.
Driver API 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 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 :functions: typec_altmode_register_driver typec_altmode_unregister_driver
Alternate mode driver operations Alternate mode driver operations
......
...@@ -436,9 +436,9 @@ FS_IOC_SET_ENCRYPTION_POLICY ...@@ -436,9 +436,9 @@ FS_IOC_SET_ENCRYPTION_POLICY
The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an
empty directory or verifies that a directory or regular file already empty directory or verifies that a directory or regular file already
has the specified encryption policy. It takes in a pointer to a has the specified encryption policy. It takes in a pointer to
:c:type:`struct fscrypt_policy_v1` or a :c:type:`struct struct fscrypt_policy_v1 or struct fscrypt_policy_v2, defined as
fscrypt_policy_v2`, defined as follows:: follows::
#define FSCRYPT_POLICY_V1 0 #define FSCRYPT_POLICY_V1 0
#define FSCRYPT_KEY_DESCRIPTOR_SIZE 8 #define FSCRYPT_KEY_DESCRIPTOR_SIZE 8
...@@ -464,11 +464,11 @@ fscrypt_policy_v2`, defined as follows:: ...@@ -464,11 +464,11 @@ fscrypt_policy_v2`, defined as follows::
This structure must be initialized as follows: This structure must be initialized as follows:
- ``version`` must be FSCRYPT_POLICY_V1 (0) if the struct is - ``version`` must be FSCRYPT_POLICY_V1 (0) if
:c:type:`fscrypt_policy_v1` or FSCRYPT_POLICY_V2 (2) if the struct struct fscrypt_policy_v1 is used or FSCRYPT_POLICY_V2 (2) if
is :c:type:`fscrypt_policy_v2`. (Note: we refer to the original struct fscrypt_policy_v2 is used. (Note: we refer to the original
policy version as "v1", though its version code is really 0.) For policy version as "v1", though its version code is really 0.)
new encrypted directories, use v2 policies. For new encrypted directories, use v2 policies.
- ``contents_encryption_mode`` and ``filenames_encryption_mode`` must - ``contents_encryption_mode`` and ``filenames_encryption_mode`` must
be set to constants from ``<linux/fscrypt.h>`` which identify the be set to constants from ``<linux/fscrypt.h>`` which identify the
...@@ -508,9 +508,9 @@ This structure must be initialized as follows: ...@@ -508,9 +508,9 @@ This structure must be initialized as follows:
replaced with ``master_key_identifier``, which is longer and cannot replaced with ``master_key_identifier``, which is longer and cannot
be arbitrarily chosen. Instead, the key must first be added using be arbitrarily chosen. Instead, the key must first be added using
`FS_IOC_ADD_ENCRYPTION_KEY`_. Then, the ``key_spec.u.identifier`` `FS_IOC_ADD_ENCRYPTION_KEY`_. Then, the ``key_spec.u.identifier``
the kernel returned in the :c:type:`struct fscrypt_add_key_arg` must the kernel returned in the struct fscrypt_add_key_arg must
be used as the ``master_key_identifier`` in the :c:type:`struct be used as the ``master_key_identifier`` in
fscrypt_policy_v2`. struct fscrypt_policy_v2.
If the file is not yet encrypted, then FS_IOC_SET_ENCRYPTION_POLICY If the file is not yet encrypted, then FS_IOC_SET_ENCRYPTION_POLICY
verifies that the file is an empty directory. If so, the specified verifies that the file is an empty directory. If so, the specified
...@@ -590,7 +590,7 @@ FS_IOC_GET_ENCRYPTION_POLICY_EX ...@@ -590,7 +590,7 @@ FS_IOC_GET_ENCRYPTION_POLICY_EX
The FS_IOC_GET_ENCRYPTION_POLICY_EX ioctl retrieves the encryption The FS_IOC_GET_ENCRYPTION_POLICY_EX ioctl retrieves the encryption
policy, if any, for a directory or regular file. No additional policy, if any, for a directory or regular file. No additional
permissions are required beyond the ability to open the file. It permissions are required beyond the ability to open the file. It
takes in a pointer to a :c:type:`struct fscrypt_get_policy_ex_arg`, takes in a pointer to struct fscrypt_get_policy_ex_arg,
defined as follows:: defined as follows::
struct fscrypt_get_policy_ex_arg { struct fscrypt_get_policy_ex_arg {
...@@ -637,9 +637,8 @@ The FS_IOC_GET_ENCRYPTION_POLICY ioctl can also retrieve the ...@@ -637,9 +637,8 @@ The FS_IOC_GET_ENCRYPTION_POLICY ioctl can also retrieve the
encryption policy, if any, for a directory or regular file. However, encryption policy, if any, for a directory or regular file. However,
unlike `FS_IOC_GET_ENCRYPTION_POLICY_EX`_, unlike `FS_IOC_GET_ENCRYPTION_POLICY_EX`_,
FS_IOC_GET_ENCRYPTION_POLICY only supports the original policy FS_IOC_GET_ENCRYPTION_POLICY only supports the original policy
version. It takes in a pointer directly to a :c:type:`struct version. It takes in a pointer directly to struct fscrypt_policy_v1
fscrypt_policy_v1` rather than a :c:type:`struct rather than struct fscrypt_get_policy_ex_arg.
fscrypt_get_policy_ex_arg`.
The error codes for FS_IOC_GET_ENCRYPTION_POLICY are the same as those The error codes for FS_IOC_GET_ENCRYPTION_POLICY are the same as those
for FS_IOC_GET_ENCRYPTION_POLICY_EX, except that for FS_IOC_GET_ENCRYPTION_POLICY_EX, except that
...@@ -680,8 +679,7 @@ the filesystem, making all files on the filesystem which were ...@@ -680,8 +679,7 @@ the filesystem, making all files on the filesystem which were
encrypted using that key appear "unlocked", i.e. in plaintext form. encrypted using that key appear "unlocked", i.e. in plaintext form.
It can be executed on any file or directory on the target filesystem, It can be executed on any file or directory on the target filesystem,
but using the filesystem's root directory is recommended. It takes in but using the filesystem's root directory is recommended. It takes in
a pointer to a :c:type:`struct fscrypt_add_key_arg`, defined as a pointer to struct fscrypt_add_key_arg, defined as follows::
follows::
struct fscrypt_add_key_arg { struct fscrypt_add_key_arg {
struct fscrypt_key_specifier key_spec; struct fscrypt_key_specifier key_spec;
...@@ -710,17 +708,16 @@ follows:: ...@@ -710,17 +708,16 @@ follows::
__u8 raw[]; __u8 raw[];
}; };
:c:type:`struct fscrypt_add_key_arg` must be zeroed, then initialized struct fscrypt_add_key_arg must be zeroed, then initialized
as follows: as follows:
- If the key is being added for use by v1 encryption policies, then - If the key is being added for use by v1 encryption policies, then
``key_spec.type`` must contain FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR, and ``key_spec.type`` must contain FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR, and
``key_spec.u.descriptor`` must contain the descriptor of the key ``key_spec.u.descriptor`` must contain the descriptor of the key
being added, corresponding to the value in the being added, corresponding to the value in the
``master_key_descriptor`` field of :c:type:`struct ``master_key_descriptor`` field of struct fscrypt_policy_v1.
fscrypt_policy_v1`. To add this type of key, the calling process To add this type of key, the calling process must have the
must have the CAP_SYS_ADMIN capability in the initial user CAP_SYS_ADMIN capability in the initial user namespace.
namespace.
Alternatively, if the key is being added for use by v2 encryption Alternatively, if the key is being added for use by v2 encryption
policies, then ``key_spec.type`` must contain policies, then ``key_spec.type`` must contain
...@@ -737,12 +734,13 @@ as follows: ...@@ -737,12 +734,13 @@ as follows:
- ``key_id`` is 0 if the raw key is given directly in the ``raw`` - ``key_id`` is 0 if the raw key is given directly in the ``raw``
field. Otherwise ``key_id`` is the ID of a Linux keyring key of field. Otherwise ``key_id`` is the ID of a Linux keyring key of
type "fscrypt-provisioning" whose payload is a :c:type:`struct type "fscrypt-provisioning" whose payload is
fscrypt_provisioning_key_payload` whose ``raw`` field contains the struct fscrypt_provisioning_key_payload whose ``raw`` field contains
raw key and whose ``type`` field matches ``key_spec.type``. Since the raw key and whose ``type`` field matches ``key_spec.type``.
``raw`` is variable-length, the total size of this key's payload Since ``raw`` is variable-length, the total size of this key's
must be ``sizeof(struct fscrypt_provisioning_key_payload)`` plus the payload must be ``sizeof(struct fscrypt_provisioning_key_payload)``
raw key size. The process must have Search permission on this key. plus the raw key size. The process must have Search permission on
this key.
Most users should leave this 0 and specify the raw key directly. Most users should leave this 0 and specify the raw key directly.
The support for specifying a Linux keyring key is intended mainly to The support for specifying a Linux keyring key is intended mainly to
...@@ -860,8 +858,8 @@ The FS_IOC_REMOVE_ENCRYPTION_KEY ioctl removes a claim to a master ...@@ -860,8 +858,8 @@ The FS_IOC_REMOVE_ENCRYPTION_KEY ioctl removes a claim to a master
encryption key from the filesystem, and possibly removes the key encryption key from the filesystem, and possibly removes the key
itself. It can be executed on any file or directory on the target itself. It can be executed on any file or directory on the target
filesystem, but using the filesystem's root directory is recommended. filesystem, but using the filesystem's root directory is recommended.
It takes in a pointer to a :c:type:`struct fscrypt_remove_key_arg`, It takes in a pointer to struct fscrypt_remove_key_arg, defined
defined as follows:: as follows::
struct fscrypt_remove_key_arg { struct fscrypt_remove_key_arg {
struct fscrypt_key_specifier key_spec; struct fscrypt_key_specifier key_spec;
...@@ -956,8 +954,8 @@ FS_IOC_GET_ENCRYPTION_KEY_STATUS ...@@ -956,8 +954,8 @@ FS_IOC_GET_ENCRYPTION_KEY_STATUS
The FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl retrieves the status of a The FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl retrieves the status of a
master encryption key. It can be executed on any file or directory on master encryption key. It can be executed on any file or directory on
the target filesystem, but using the filesystem's root directory is the target filesystem, but using the filesystem's root directory is
recommended. It takes in a pointer to a :c:type:`struct recommended. It takes in a pointer to
fscrypt_get_key_status_arg`, defined as follows:: struct fscrypt_get_key_status_arg, defined as follows::
struct fscrypt_get_key_status_arg { struct fscrypt_get_key_status_arg {
/* input */ /* input */
...@@ -1148,10 +1146,10 @@ Implementation details ...@@ -1148,10 +1146,10 @@ Implementation details
Encryption context Encryption context
------------------ ------------------
An encryption policy is represented on-disk by a :c:type:`struct An encryption policy is represented on-disk by
fscrypt_context_v1` or a :c:type:`struct fscrypt_context_v2`. It is struct fscrypt_context_v1 or struct fscrypt_context_v2. It is up to
up to individual filesystems to decide where to store it, but normally individual filesystems to decide where to store it, but normally it
it would be stored in a hidden extended attribute. It should *not* be would be stored in a hidden extended attribute. It should *not* be
exposed by the xattr-related system calls such as getxattr() and exposed by the xattr-related system calls such as getxattr() and
setxattr() because of the special semantics of the encryption xattr. setxattr() because of the special semantics of the encryption xattr.
(In particular, there would be much confusion if an encryption policy (In particular, there would be much confusion if an encryption policy
...@@ -1249,8 +1247,8 @@ a strong "hash" of the ciphertext filename, along with the optional ...@@ -1249,8 +1247,8 @@ a strong "hash" of the ciphertext filename, along with the optional
filesystem-specific hash(es) needed for directory lookups. This filesystem-specific hash(es) needed for directory lookups. This
allows the filesystem to still, with a high degree of confidence, map allows the filesystem to still, with a high degree of confidence, map
the filename given in ->lookup() back to a particular directory entry the filename given in ->lookup() back to a particular directory entry
that was previously listed by readdir(). See :c:type:`struct that was previously listed by readdir(). See
fscrypt_nokey_name` in the source for more details. struct fscrypt_nokey_name in the source for more details.
Note that the precise way that filenames are presented to userspace Note that the precise way that filenames are presented to userspace
without the key is subject to change in the future. It is only meant without the key is subject to change in the future. It is only meant
......
...@@ -84,7 +84,7 @@ FS_IOC_ENABLE_VERITY ...@@ -84,7 +84,7 @@ FS_IOC_ENABLE_VERITY
-------------------- --------------------
The FS_IOC_ENABLE_VERITY ioctl enables fs-verity on a file. It takes 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:: follows::
struct fsverity_enable_arg { struct fsverity_enable_arg {
......
...@@ -636,15 +636,36 @@ i915 Perf Observation Architecture Stream ...@@ -636,15 +636,36 @@ i915 Perf Observation Architecture Stream
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
:functions: i915_oa_poll_wait :functions: i915_oa_poll_wait
All i915 Perf Internals Other i915 Perf Internals
----------------------- -------------------------
This section simply includes all currently documented i915 perf internals, in This section simply includes all other currently documented i915 perf internals,
no particular order, but may include some more minor utilities or platform in no particular order, but may include some more minor utilities or platform
specific details than found in the more high-level sections. specific details than found in the more high-level sections.
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
:internal: :internal:
:no-identifiers:
i915_perf_init
i915_perf_fini
i915_perf_register
i915_perf_unregister
i915_perf_open_ioctl
i915_perf_release
i915_perf_add_config_ioctl
i915_perf_remove_config_ioctl
read_properties_unlocked
i915_perf_open_ioctl_locked
i915_perf_destroy_locked
i915_perf_read i915_perf_ioctl
i915_perf_enable_locked
i915_perf_disable_locked
i915_perf_poll i915_perf_poll_locked
i915_oa_stream_init i915_oa_read
i915_oa_stream_enable
i915_oa_stream_disable
i915_oa_wait_unlocked
i915_oa_poll_wait
Style Style
===== =====
......
...@@ -26,7 +26,9 @@ The stack is composed of three main parts: ...@@ -26,7 +26,9 @@ The stack is composed of three main parts:
Socket API Socket API
========== ==========
.. c:function:: int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0); ::
int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
The address family, socket addresses etc. are defined in the The address family, socket addresses etc. are defined in the
include/net/af_ieee802154.h header or in the special header include/net/af_ieee802154.h header or in the special header
...@@ -131,12 +133,12 @@ Register PHY in the system. ...@@ -131,12 +133,12 @@ Register PHY in the system.
Freeing registered PHY. Freeing registered PHY.
.. c:function:: void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb, u8 lqi): .. c:function:: void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb, u8 lqi)
Telling 802.15.4 module there is a new received frame in the skb with Telling 802.15.4 module there is a new received frame in the skb with
the RF Link Quality Indicator (LQI) from the hardware device. the RF Link Quality Indicator (LQI) from the hardware device.
.. c:function:: void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb, bool ifs_handling): .. c:function:: void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb, bool ifs_handling)
Telling 802.15.4 module the frame in the skb is or going to be Telling 802.15.4 module the frame in the skb is or going to be
transmitted through the hardware device transmitted through the hardware device
...@@ -155,25 +157,25 @@ operations structure at least:: ...@@ -155,25 +157,25 @@ operations structure at least::
... ...
}; };
.. c:function:: int start(struct ieee802154_hw *hw): .. c:function:: int start(struct ieee802154_hw *hw)
Handler that 802.15.4 module calls for the hardware device initialization. Handler that 802.15.4 module calls for the hardware device initialization.
.. c:function:: void stop(struct ieee802154_hw *hw): .. c:function:: void stop(struct ieee802154_hw *hw)
Handler that 802.15.4 module calls for the hardware device cleanup. Handler that 802.15.4 module calls for the hardware device cleanup.
.. c:function:: int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb): .. c:function:: int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb)
Handler that 802.15.4 module calls for each frame in the skb going to be Handler that 802.15.4 module calls for each frame in the skb going to be
transmitted through the hardware device. transmitted through the hardware device.
.. c:function:: int ed(struct ieee802154_hw *hw, u8 *level): .. c:function:: int ed(struct ieee802154_hw *hw, u8 *level)
Handler that 802.15.4 module calls for Energy Detection from the hardware Handler that 802.15.4 module calls for Energy Detection from the hardware
device. device.
.. c:function:: int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel): .. c:function:: int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel)
Set radio for listening on specific channel of the hardware device. Set radio for listening on specific channel of the hardware device.
......
...@@ -49,22 +49,22 @@ Register preservation rules ...@@ -49,22 +49,22 @@ Register preservation rules
Register preservation rules match the ELF ABI calling sequence with the Register preservation rules match the ELF ABI calling sequence with the
following differences: following differences:
--- For the sc instruction, differences with the ELF ABI --- +------------------------------------------------------------------------+
=========== ============= ======================================== | For the sc instruction, differences with the ELF ABI |
r0 Volatile (System call number.) +--------------+--------------+------------------------------------------+
r3 Volatile (Parameter 1, and return value.) | r0 | Volatile | (System call number.) |
r4-r8 Volatile (Parameters 2-6.) | rr3 | Volatile | (Parameter 1, and return value.) |
cr0 Volatile (cr0.SO is the return error condition.) | rr4-r8 | Volatile | (Parameters 2-6.) |
cr1, cr5-7 Nonvolatile | rcr0 | Volatile | (cr0.SO is the return error condition.) |
lr Nonvolatile | rcr1, cr5-7 | Nonvolatile | |
=========== ============= ======================================== | rlr | Nonvolatile | |
+--------------+--------------+------------------------------------------+
--- For the scv 0 instruction, differences with the ELF ABI --- | For the scv 0 instruction, differences with the ELF ABI |
=========== ============= ======================================== +--------------+--------------+------------------------------------------+
r0 Volatile (System call number.) | r0 | Volatile | (System call number.) |
r3 Volatile (Parameter 1, and return value.) | r3 | Volatile | (Parameter 1, and return value.) |
r4-r8 Volatile (Parameters 2-6.) | r4-r8 | Volatile | (Parameters 2-6.) |
=========== ============= ======================================== +--------------+--------------+------------------------------------------+
All floating point and vector data registers as well as control and status All floating point and vector data registers as well as control and status
registers are nonvolatile. registers are nonvolatile.
......
...@@ -34,20 +34,20 @@ substream. In this procedure, PCM hardware parameters are decided by ...@@ -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 interaction between applications and ALSA PCM core. Once decided, runtime of
the PCM substream keeps the parameters. 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 structure includes several types of parameters. Applications set preferable
value to these parameters, then execute ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE 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 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. 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`` ``flags``
Configurable. ALSA PCM core and some drivers handle this flag to select Configurable. ALSA PCM core and some drivers handle this flag to select
convenient parameters or change their behaviour. convenient parameters or change their behaviour.
``masks`` ``masks``
Configurable. This type of parameter is described in 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. v2.0.13, three types are defined.
- SNDRV_PCM_HW_PARAM_ACCESS - SNDRV_PCM_HW_PARAM_ACCESS
...@@ -55,7 +55,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: ...@@ -55,7 +55,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members:
- SNDRV_PCM_HW_PARAM_SUBFORMAT - SNDRV_PCM_HW_PARAM_SUBFORMAT
``intervals`` ``intervals``
Configurable. This type of parameter is described in 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. PCM protocol v2.0.13, twelve types are defined.
- SNDRV_PCM_HW_PARAM_SAMPLE_BITS - SNDRV_PCM_HW_PARAM_SAMPLE_BITS
...@@ -78,7 +78,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: ...@@ -78,7 +78,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members:
are going to be changed. are going to be changed.
``cmask`` ``cmask``
Read-only. After returning from ioctl(2), buffer in user space for 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. This mask represents which mask/interval parameter is actually changed.
``info`` ``info``
Read-only. This represents hardware/driver capabilities as bit flags 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: ...@@ -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 value to this parameter but some drivers intentionally set zero with
a care of hardware design or data transmission protocol. 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. applications execute ioctl(2) with SNDRV_PCM_HW_REFINE or SNDRV_PCM_HW_PARAMS.
Parameters in the buffer are changed according to 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 structure describes capabilities of handled hardware. The rules describes
dependencies on which a parameter is decided according to several parameters. dependencies on which a parameter is decided according to several parameters.
A rule has a callback function, and drivers can register arbitrary functions 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 ...@@ -121,17 +121,17 @@ to compute the target parameter. ALSA PCM core registers some rules to the
runtime as a default. runtime as a default.
Each driver can join in the interaction as long as it prepared for two stuffs 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 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. capacities of corresponding hardware.
2. In the same callback, drivers are also expected to register additional rules 2. In the same callback, drivers are also expected to register additional rules
of constraints into the runtime when several parameters have dependencies of constraints into the runtime when several parameters have dependencies
due to hardware design. due to hardware design.
The driver can refers to result of the interaction in a callback of 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. content.
Tracepoints in this category are designed to trace changes of the 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 ...@@ -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 type, the fields represent hexadecimal dump of content of the parameter. For
parameters of interval type, the fields represent values of each member of parameters of interval type, the fields represent values of each member of
``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in ``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in
:c:type:`struct snd_interval` in this order. struct snd_interval in this order.
Tracepoints in drivers Tracepoints in drivers
====================== ======================
......
...@@ -132,3 +132,4 @@ ISA DMA Helpers ...@@ -132,3 +132,4 @@ ISA DMA Helpers
Other Helper Macros Other Helper Macros
------------------- -------------------
.. kernel-doc:: include/sound/core.h .. kernel-doc:: include/sound/core.h
.. kernel-doc:: sound/sound_core.c
...@@ -22,13 +22,34 @@ from itertools import chain ...@@ -22,13 +22,34 @@ from itertools import chain
# :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last # :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last
# bit tries to restrict matches to things that won't create trouble. # bit tries to restrict matches to things that won't create trouble.
# #
RE_function = re.compile(r'(([\w_][\w\d_]+)\(\))') RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=re.ASCII)
RE_type = re.compile(r'(struct|union|enum|typedef)\s+([\w_][\w\d_]+)')
#
# Sphinx 2 uses the same :c:type role for struct, union, enum and typedef
#
RE_generic_type = re.compile(r'\b(struct|union|enum|typedef)\s+([a-zA-Z_]\w+)',
flags=re.ASCII)
#
# Sphinx 3 uses a different C role for each one of struct, union, enum and
# typedef
#
RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
# #
# Detects a reference to a documentation page of the form Documentation/... with # Detects a reference to a documentation page of the form Documentation/... with
# an optional extension # an optional extension
# #
RE_doc = re.compile(r'Documentation(/[\w\-_/]+)(\.\w+)*') RE_doc = re.compile(r'\bDocumentation(/[\w\-_/]+)(\.\w+)*')
#
# Reserved C words that we should skip when cross-referencing
#
Skipnames = [ 'for', 'if', 'register', 'sizeof', 'struct', 'unsigned' ]
# #
# Many places in the docs refer to common system calls. It is # Many places in the docs refer to common system calls. It is
...@@ -48,9 +69,22 @@ def markup_refs(docname, app, node): ...@@ -48,9 +69,22 @@ def markup_refs(docname, app, node):
# #
# Associate each regex with the function that will markup its matches # Associate each regex with the function that will markup its matches
# #
markup_func = {RE_type: markup_c_ref, markup_func_sphinx2 = {RE_doc: markup_doc_ref,
RE_function: markup_c_ref, RE_function: markup_c_ref,
RE_doc: markup_doc_ref} RE_generic_type: markup_c_ref}
markup_func_sphinx3 = {RE_doc: markup_doc_ref,
RE_function: markup_func_ref_sphinx3,
RE_struct: markup_c_ref,
RE_union: markup_c_ref,
RE_enum: markup_c_ref,
RE_typedef: markup_c_ref}
if sphinx.version_info[0] >= 3:
markup_func = markup_func_sphinx3
else:
markup_func = markup_func_sphinx2
match_iterators = [regex.finditer(t) for regex in markup_func] match_iterators = [regex.finditer(t) for regex in markup_func]
# #
# Sort all references by the starting position in text # Sort all references by the starting position in text
...@@ -75,12 +109,63 @@ def markup_refs(docname, app, node): ...@@ -75,12 +109,63 @@ def markup_refs(docname, app, node):
return repl return repl
# #
# Try to replace a C reference (function() or struct/union/enum/typedef # In sphinx3 we can cross-reference to C macro and function, each one with its
# type_name) with an appropriate cross reference. # own C role, but both match the same regex, so we try both.
# #
def markup_func_ref_sphinx3(docname, app, match):
class_str = ['c-func', 'c-macro']
reftype_str = ['function', 'macro']
cdom = app.env.domains['c']
#
# Go through the dance of getting an xref out of the C domain
#
target = match.group(2)
target_text = nodes.Text(match.group(0))
xref = None
if not (target in Skipfuncs or target in Skipnames):
for class_s, reftype_s in zip(class_str, reftype_str):
lit_text = nodes.literal(classes=['xref', 'c', class_s])
lit_text += target_text
pxref = addnodes.pending_xref('', refdomain = 'c',
reftype = reftype_s,
reftarget = target, modname = None,
classname = None)
#
# XXX The Latex builder will throw NoUri exceptions here,
# work around that by ignoring them.
#
try:
xref = cdom.resolve_xref(app.env, docname, app.builder,
reftype_s, target, pxref,
lit_text)
except NoUri:
xref = None
if xref:
return xref
return target_text
def markup_c_ref(docname, app, match): def markup_c_ref(docname, app, match):
class_str = {RE_function: 'c-func', RE_type: 'c-type'} class_str = {# Sphinx 2 only
reftype_str = {RE_function: 'function', RE_type: 'type'} RE_function: 'c-func',
RE_generic_type: 'c-type',
# Sphinx 3+ only
RE_struct: 'c-struct',
RE_union: 'c-union',
RE_enum: 'c-enum',
RE_typedef: 'c-type',
}
reftype_str = {# Sphinx 2 only
RE_function: 'function',
RE_generic_type: 'type',
# Sphinx 3+ only
RE_struct: 'struct',
RE_union: 'union',
RE_enum: 'enum',
RE_typedef: 'type',
}
cdom = app.env.domains['c'] cdom = app.env.domains['c']
# #
...@@ -89,7 +174,8 @@ def markup_c_ref(docname, app, match): ...@@ -89,7 +174,8 @@ def markup_c_ref(docname, app, match):
target = match.group(2) target = match.group(2)
target_text = nodes.Text(match.group(0)) target_text = nodes.Text(match.group(0))
xref = None xref = None
if not (match.re == RE_function and target in Skipfuncs): if not ((match.re == RE_function and target in Skipfuncs)
or (target in Skipnames)):
lit_text = nodes.literal(classes=['xref', 'c', class_str[match.re]]) lit_text = nodes.literal(classes=['xref', 'c', class_str[match.re]])
lit_text += target_text lit_text += target_text
pxref = addnodes.pending_xref('', refdomain = 'c', pxref = addnodes.pending_xref('', refdomain = 'c',
......
...@@ -40,14 +40,94 @@ from sphinx import addnodes ...@@ -40,14 +40,94 @@ from sphinx import addnodes
from sphinx.domains.c import c_funcptr_sig_re, c_sig_re from sphinx.domains.c import c_funcptr_sig_re, c_sig_re
from sphinx.domains.c import CObject as Base_CObject from sphinx.domains.c import CObject as Base_CObject
from sphinx.domains.c import CDomain as Base_CDomain from sphinx.domains.c import CDomain as Base_CDomain
from itertools import chain
import re
__version__ = '1.0' __version__ = '1.1'
# Get Sphinx version # Get Sphinx version
major, minor, patch = sphinx.version_info[:3] major, minor, patch = sphinx.version_info[:3]
# Namespace to be prepended to the full name
namespace = None
#
# Handle trivial newer c domain tags that are part of Sphinx 3.1 c domain tags
# - Store the namespace if ".. c:namespace::" tag is found
#
RE_namespace = re.compile(r'^\s*..\s*c:namespace::\s*(\S+)\s*$')
def markup_namespace(match):
global namespace
namespace = match.group(1)
return ""
#
# Handle c:macro for function-style declaration
#
RE_macro = re.compile(r'^\s*..\s*c:macro::\s*(\S+)\s+(\S.*)\s*$')
def markup_macro(match):
return ".. c:function:: " + match.group(1) + ' ' + match.group(2)
#
# Handle newer c domain tags that are evaluated as .. c:type: for
# backward-compatibility with Sphinx < 3.0
#
RE_ctype = re.compile(r'^\s*..\s*c:(struct|union|enum|enumerator|alias)::\s*(.*)$')
def markup_ctype(match):
return ".. c:type:: " + match.group(2)
#
# Handle newer c domain tags that are evaluated as :c:type: for
# backward-compatibility with Sphinx < 3.0
#
RE_ctype_refs = re.compile(r':c:(var|struct|union|enum|enumerator)::`([^\`]+)`')
def markup_ctype_refs(match):
return ":c:type:`" + match.group(2) + '`'
#
# Simply convert :c:expr: and :c:texpr: into a literal block.
#
RE_expr = re.compile(r':c:(expr|texpr):`([^\`]+)`')
def markup_c_expr(match):
return '\ ``' + match.group(2) + '``\ '
#
# Parse Sphinx 3.x C markups, replacing them by backward-compatible ones
#
def c_markups(app, docname, source):
result = ""
markup_func = {
RE_namespace: markup_namespace,
RE_expr: markup_c_expr,
RE_macro: markup_macro,
RE_ctype: markup_ctype,
RE_ctype_refs: markup_ctype_refs,
}
lines = iter(source[0].splitlines(True))
for n in lines:
match_iterators = [regex.finditer(n) for regex in markup_func]
matches = sorted(chain(*match_iterators), key=lambda m: m.start())
for m in matches:
n = n[:m.start()] + markup_func[m.re](m) + n[m.end():]
result = result + n
source[0] = result
#
# Now implements support for the cdomain namespacing logic
#
def setup(app): def setup(app):
# Handle easy Sphinx 3.1+ simple new tags: :c:expr and .. c:namespace::
app.connect('source-read', c_markups)
if (major == 1 and minor < 8): if (major == 1 and minor < 8):
app.override_domain(CDomain) app.override_domain(CDomain)
else: else:
...@@ -75,6 +155,8 @@ class CObject(Base_CObject): ...@@ -75,6 +155,8 @@ class CObject(Base_CObject):
function-like macro, the name of the macro is returned. Otherwise function-like macro, the name of the macro is returned. Otherwise
``False`` is returned. """ ``False`` is returned. """
global namespace
if not self.objtype == 'function': if not self.objtype == 'function':
return False return False
...@@ -107,11 +189,16 @@ class CObject(Base_CObject): ...@@ -107,11 +189,16 @@ class CObject(Base_CObject):
param += nodes.emphasis(argname, argname) param += nodes.emphasis(argname, argname)
paramlist += param paramlist += param
if namespace:
fullname = namespace + "." + fullname
return fullname return fullname
def handle_signature(self, sig, signode): def handle_signature(self, sig, signode):
"""Transform a C signature into RST nodes.""" """Transform a C signature into RST nodes."""
global namespace
fullname = self.handle_func_like_macro(sig, signode) fullname = self.handle_func_like_macro(sig, signode)
if not fullname: if not fullname:
fullname = super(CObject, self).handle_signature(sig, signode) fullname = super(CObject, self).handle_signature(sig, signode)
...@@ -122,6 +209,10 @@ class CObject(Base_CObject): ...@@ -122,6 +209,10 @@ class CObject(Base_CObject):
else: else:
# FIXME: handle :name: value of other declaration types? # FIXME: handle :name: value of other declaration types?
pass pass
else:
if namespace:
fullname = namespace + "." + fullname
return fullname return fullname
def add_target_and_index(self, name, sig, signode): def add_target_and_index(self, name, sig, signode):
......
...@@ -62,6 +62,7 @@ class KernelDocDirective(Directive): ...@@ -62,6 +62,7 @@ class KernelDocDirective(Directive):
'export': directives.unchanged, 'export': directives.unchanged,
'internal': directives.unchanged, 'internal': directives.unchanged,
'identifiers': directives.unchanged, 'identifiers': directives.unchanged,
'no-identifiers': directives.unchanged,
'functions': directives.unchanged, 'functions': directives.unchanged,
} }
has_content = False has_content = False
...@@ -70,6 +71,11 @@ class KernelDocDirective(Directive): ...@@ -70,6 +71,11 @@ class KernelDocDirective(Directive):
env = self.state.document.settings.env env = self.state.document.settings.env
cmd = [env.config.kerneldoc_bin, '-rst', '-enable-lineno'] cmd = [env.config.kerneldoc_bin, '-rst', '-enable-lineno']
# Pass the version string to kernel-doc, as it needs to use a different
# dialect, depending what the C domain supports for each specific
# Sphinx versions
cmd += ['-sphinx-version', sphinx.__version__]
filename = env.config.kerneldoc_srctree + '/' + self.arguments[0] filename = env.config.kerneldoc_srctree + '/' + self.arguments[0]
export_file_patterns = [] export_file_patterns = []
...@@ -99,6 +105,12 @@ class KernelDocDirective(Directive): ...@@ -99,6 +105,12 @@ class KernelDocDirective(Directive):
else: else:
cmd += ['-no-doc-sections'] cmd += ['-no-doc-sections']
if 'no-identifiers' in self.options:
no_identifiers = self.options.get('no-identifiers').split()
if no_identifiers:
for i in no_identifiers:
cmd += ['-nosymbol', i]
for pattern in export_file_patterns: for pattern in export_file_patterns:
for f in glob.glob(env.config.kerneldoc_srctree + '/' + pattern): for f in glob.glob(env.config.kerneldoc_srctree + '/' + pattern):
env.note_dependency(os.path.abspath(f)) env.note_dependency(os.path.abspath(f))
...@@ -136,7 +148,8 @@ class KernelDocDirective(Directive): ...@@ -136,7 +148,8 @@ class KernelDocDirective(Directive):
lineoffset = int(match.group(1)) - 1 lineoffset = int(match.group(1)) - 1
# we must eat our comments since the upset the markup # we must eat our comments since the upset the markup
else: else:
result.append(line, filename, lineoffset) doc = env.srcdir + "/" + env.docname + ":" + str(self.lineno)
result.append(line, doc + ": " + filename, lineoffset)
lineoffset += 1 lineoffset += 1
node = nodes.section() node = nodes.section()
......
...@@ -110,7 +110,7 @@ while (<IN>) { ...@@ -110,7 +110,7 @@ while (<IN>) {
) { ) {
my $s = $1; my $s = $1;
$structs{$s} = "struct :c:type:`$s`\\ "; $structs{$s} = "struct $s\\ ";
next; next;
} }
} }
......
...@@ -55,17 +55,17 @@ an ftrace_ops with ftrace: ...@@ -55,17 +55,17 @@ an ftrace_ops with ftrace:
Both .flags and .private are optional. Only .func is required. Both .flags and .private are optional. Only .func is required.
To enable tracing call: To enable tracing call::
.. c:function:: register_ftrace_function(&ops); register_ftrace_function(&ops);
To disable tracing call: To disable tracing call::
.. c:function:: unregister_ftrace_function(&ops); unregister_ftrace_function(&ops);
The above is defined by including the header: The above is defined by including the header::
.. c:function:: #include <linux/ftrace.h> #include <linux/ftrace.h>
The registered callback will start being called some time after the The registered callback will start being called some time after the
register_ftrace_function() is called and before it returns. The exact time register_ftrace_function() is called and before it returns. The exact time
......
...@@ -402,7 +402,7 @@ il valore convertito. Tutte le varianti supportano anche il processo inverso: ...@@ -402,7 +402,7 @@ il valore convertito. Tutte le varianti supportano anche il processo inverso:
:c:func:`be32_to_cpu()`, eccetera. :c:func:`be32_to_cpu()`, eccetera.
Queste funzioni hanno principalmente due varianti: la variante per Queste funzioni hanno principalmente due varianti: la variante per
puntatori, come :c:func:`cpu_to_be32p(), che prende un puntatore puntatori, come :c:func:`cpu_to_be32p()`, che prende un puntatore
ad un tipo, e ritorna il valore convertito. L'altra variante per ad un tipo, e ritorna il valore convertito. L'altra variante per
la famiglia di conversioni "in-situ", come :c:func:`cpu_to_be32s()`, la famiglia di conversioni "in-situ", come :c:func:`cpu_to_be32s()`,
che convertono il valore puntato da un puntatore, e ritornano void. che convertono il valore puntato da un puntatore, e ritornano void.
......
.. include:: ../disclaimer-ita.rst .. include:: ../disclaimer-ita.rst
.. c:namespace:: it_IT
:Original: :ref:`Documentation/kernel-hacking/locking.rst <kernel_hacking_lock>` :Original: :ref:`Documentation/kernel-hacking/locking.rst <kernel_hacking_lock>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it> :Translator: Federico Vaga <federico.vaga@vaga.pv.it>
......
...@@ -4,9 +4,9 @@ ...@@ -4,9 +4,9 @@
Translator: Bailu Lin <bailu.lin@vivo.com> Translator: Bailu Lin <bailu.lin@vivo.com>
================================= ==================================
AArch64 Linux 中扩展的活动监控单元 AArch64 Linux 中扩展的活动监控单元
================================= ==================================
作者: Ionela Voinescu <ionela.voinescu@arm.com> 作者: Ionela Voinescu <ionela.voinescu@arm.com>
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: CEC
.. _cec-func-close: .. _cec-func-close:
...@@ -11,7 +12,6 @@ Name ...@@ -11,7 +12,6 @@ Name
cec-close - Close a cec device cec-close - Close a cec device
Synopsis Synopsis
======== ========
...@@ -19,16 +19,13 @@ Synopsis ...@@ -19,16 +19,13 @@ Synopsis
#include <unistd.h> #include <unistd.h>
.. c:function:: int close( int fd ) .. c:function:: int close( int fd )
:name: cec-close
Arguments Arguments
========= =========
``fd`` ``fd``
File descriptor returned by :c:func:`open() <cec-open>`. File descriptor returned by :c:func:`open()`.
Description Description
=========== ===========
...@@ -36,11 +33,10 @@ Description ...@@ -36,11 +33,10 @@ Description
Closes the cec device. Resources associated with the file descriptor are Closes the cec device. Resources associated with the file descriptor are
freed. The device configuration remain unchanged. freed. The device configuration remain unchanged.
Return Value Return Value
============ ============
:c:func:`close() <cec-close>` returns 0 on success. On error, -1 is returned, and :c:func:`close()` returns 0 on success. On error, -1 is returned, and
``errno`` is set appropriately. Possible error codes are: ``errno`` is set appropriately. Possible error codes are:
``EBADF`` ``EBADF``
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: CEC
.. _cec-func-ioctl: .. _cec-func-ioctl:
...@@ -18,15 +19,13 @@ Synopsis ...@@ -18,15 +19,13 @@ Synopsis
#include <sys/ioctl.h> #include <sys/ioctl.h>
``int ioctl(int fd, int request, void *argp)``
.. c:function:: int ioctl( int fd, int request, void *argp )
:name: cec-ioctl
Arguments Arguments
========= =========
``fd`` ``fd``
File descriptor returned by :c:func:`open() <cec-open>`. File descriptor returned by :c:func:`open()`.
``request`` ``request``
CEC ioctl request code as defined in the cec.h header file, for CEC ioctl request code as defined in the cec.h header file, for
...@@ -35,11 +34,10 @@ Arguments ...@@ -35,11 +34,10 @@ Arguments
``argp`` ``argp``
Pointer to a request-specific structure. Pointer to a request-specific structure.
Description Description
=========== ===========
The :c:func:`ioctl() <cec-ioctl>` function manipulates cec device parameters. The The :c:func:`ioctl()` function manipulates cec device parameters. The
argument ``fd`` must be an open file descriptor. argument ``fd`` must be an open file descriptor.
The ioctl ``request`` code specifies the cec function to be called. It The ioctl ``request`` code specifies the cec function to be called. It
...@@ -51,7 +49,6 @@ their parameters are located in the cec.h header file. All cec ioctl ...@@ -51,7 +49,6 @@ their parameters are located in the cec.h header file. All cec ioctl
requests, their respective function and parameters are specified in requests, their respective function and parameters are specified in
:ref:`cec-user-func`. :ref:`cec-user-func`.
Return Value Return Value
============ ============
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: CEC
.. _cec-func-open: .. _cec-func-open:
...@@ -18,10 +19,7 @@ Synopsis ...@@ -18,10 +19,7 @@ Synopsis
#include <fcntl.h> #include <fcntl.h>
.. c:function:: int open( const char *device_name, int flags ) .. c:function:: int open( const char *device_name, int flags )
:name: cec-open
Arguments Arguments
========= =========
...@@ -42,11 +40,10 @@ Arguments ...@@ -42,11 +40,10 @@ Arguments
Other flags have no effect. Other flags have no effect.
Description Description
=========== ===========
To open a cec device applications call :c:func:`open() <cec-open>` with the To open a cec device applications call :c:func:`open()` with the
desired device name. The function has no side effects; the device desired device name. The function has no side effects; the device
configuration remain unchanged. configuration remain unchanged.
...@@ -54,11 +51,10 @@ When the device is opened in read-only mode, attempts to modify its ...@@ -54,11 +51,10 @@ When the device is opened in read-only mode, attempts to modify its
configuration will result in an error, and ``errno`` will be set to configuration will result in an error, and ``errno`` will be set to
EBADF. EBADF.
Return Value Return Value
============ ============
:c:func:`open() <cec-open>` returns the new file descriptor on success. On error, :c:func:`open()` returns the new file descriptor on success. On error,
-1 is returned, and ``errno`` is set appropriately. Possible error codes -1 is returned, and ``errno`` is set appropriately. Possible error codes
include: include:
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: CEC
.. _cec-func-poll: .. _cec-func-poll:
...@@ -11,7 +12,6 @@ Name ...@@ -11,7 +12,6 @@ Name
cec-poll - Wait for some event on a file descriptor cec-poll - Wait for some event on a file descriptor
Synopsis Synopsis
======== ========
...@@ -19,9 +19,7 @@ Synopsis ...@@ -19,9 +19,7 @@ Synopsis
#include <sys/poll.h> #include <sys/poll.h>
.. c:function:: int poll( struct pollfd *ufds, unsigned int nfds, int timeout ) .. c:function:: int poll( struct pollfd *ufds, unsigned int nfds, int timeout )
:name: cec-poll
Arguments Arguments
========= =========
...@@ -35,14 +33,13 @@ Arguments ...@@ -35,14 +33,13 @@ Arguments
``timeout`` ``timeout``
Timeout to wait for events Timeout to wait for events
Description Description
=========== ===========
With the :c:func:`poll() <cec-poll>` function applications can wait for CEC With the :c:func:`poll()` function applications can wait for CEC
events. events.
On success :c:func:`poll() <cec-poll>` returns the number of file descriptors On success :c:func:`poll()` returns the number of file descriptors
that have been selected (that is, file descriptors for which the that have been selected (that is, file descriptors for which the
``revents`` field of the respective struct :c:type:`pollfd` ``revents`` field of the respective struct :c:type:`pollfd`
is non-zero). CEC devices set the ``POLLIN`` and ``POLLRDNORM`` flags in is non-zero). CEC devices set the ``POLLIN`` and ``POLLRDNORM`` flags in
...@@ -53,13 +50,12 @@ then the ``POLLPRI`` flag is set. When the function times out it returns ...@@ -53,13 +50,12 @@ then the ``POLLPRI`` flag is set. When the function times out it returns
a value of zero, on failure it returns -1 and the ``errno`` variable is a value of zero, on failure it returns -1 and the ``errno`` variable is
set appropriately. set appropriately.
For more details see the :c:func:`poll() <cec-poll>` manual page. For more details see the :c:func:`poll()` manual page.
Return Value Return Value
============ ============
On success, :c:func:`poll() <cec-poll>` returns the number structures which have On success, :c:func:`poll()` returns the number structures which have
non-zero ``revents`` fields, or zero if the call timed out. On error -1 non-zero ``revents`` fields, or zero if the call timed out. On error -1
is returned, and the ``errno`` variable is set appropriately: is returned, and the ``errno`` variable is set appropriately:
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: CEC
.. _CEC_ADAP_G_CAPS: .. _CEC_ADAP_G_CAPS:
...@@ -14,18 +15,18 @@ CEC_ADAP_G_CAPS - Query device capabilities ...@@ -14,18 +15,18 @@ CEC_ADAP_G_CAPS - Query device capabilities
Synopsis Synopsis
======== ========
.. c:function:: int ioctl( int fd, CEC_ADAP_G_CAPS, struct cec_caps *argp ) .. c:macro:: CEC_ADAP_G_CAPS
:name: CEC_ADAP_G_CAPS
``int ioctl(int fd, CEC_ADAP_G_CAPS, struct cec_caps *argp)``
Arguments Arguments
========= =========
``fd`` ``fd``
File descriptor returned by :c:func:`open() <cec-open>`. File descriptor returned by :c:func:`open()`.
``argp`` ``argp``
Description Description
=========== ===========
...@@ -62,7 +63,6 @@ returns the information to the application. The ioctl never fails. ...@@ -62,7 +63,6 @@ returns the information to the application. The ioctl never fails.
- CEC Framework API version, formatted with the ``KERNEL_VERSION()`` - CEC Framework API version, formatted with the ``KERNEL_VERSION()``
macro. macro.
.. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.6cm}| .. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.6cm}|
.. _cec-capabilities: .. _cec-capabilities:
......
...@@ -2,6 +2,8 @@ ...@@ -2,6 +2,8 @@
.. ..
.. Copyright 2019 Google LLC .. Copyright 2019 Google LLC
.. ..
.. c:namespace:: CEC
.. _CEC_ADAP_G_CONNECTOR_INFO: .. _CEC_ADAP_G_CONNECTOR_INFO:
******************************* *******************************
...@@ -16,18 +18,18 @@ CEC_ADAP_G_CONNECTOR_INFO - Query HDMI connector information ...@@ -16,18 +18,18 @@ CEC_ADAP_G_CONNECTOR_INFO - Query HDMI connector information
Synopsis Synopsis
======== ========
.. c:function:: int ioctl( int fd, CEC_ADAP_G_CONNECTOR_INFO, struct cec_connector_info *argp ) .. c:macro:: CEC_ADAP_G_CONNECTOR_INFO
:name: CEC_ADAP_G_CONNECTOR_INFO
``int ioctl(int fd, CEC_ADAP_G_CONNECTOR_INFO, struct cec_connector_info *argp)``
Arguments Arguments
========= =========
``fd`` ``fd``
File descriptor returned by :c:func:`open() <cec-open>`. File descriptor returned by :c:func:`open()`.
``argp`` ``argp``
Description Description
=========== ===========
...@@ -57,7 +59,6 @@ is only available if the ``CEC_CAP_CONNECTOR_INFO`` capability is set. ...@@ -57,7 +59,6 @@ is only available if the ``CEC_CAP_CONNECTOR_INFO`` capability is set.
* - } * - }
- -
.. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.6cm}| .. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.6cm}|
.. _connector-type: .. _connector-type:
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: CEC
.. _CEC_ADAP_LOG_ADDRS: .. _CEC_ADAP_LOG_ADDRS:
.. _CEC_ADAP_G_LOG_ADDRS: .. _CEC_ADAP_G_LOG_ADDRS:
...@@ -13,21 +14,22 @@ Name ...@@ -13,21 +14,22 @@ Name
CEC_ADAP_G_LOG_ADDRS, CEC_ADAP_S_LOG_ADDRS - Get or set the logical addresses CEC_ADAP_G_LOG_ADDRS, CEC_ADAP_S_LOG_ADDRS - Get or set the logical addresses
Synopsis Synopsis
======== ========
.. c:function:: int ioctl( int fd, CEC_ADAP_G_LOG_ADDRS, struct cec_log_addrs *argp ) .. c:macro:: CEC_ADAP_G_LOG_ADDRS
:name: CEC_ADAP_G_LOG_ADDRS
``int ioctl(int fd, CEC_ADAP_G_LOG_ADDRS, struct cec_log_addrs *argp)``
.. c:macro:: CEC_ADAP_S_LOG_ADDRS
.. c:function:: int ioctl( int fd, CEC_ADAP_S_LOG_ADDRS, struct cec_log_addrs *argp ) ``int ioctl(int fd, CEC_ADAP_S_LOG_ADDRS, struct cec_log_addrs *argp)``
:name: CEC_ADAP_S_LOG_ADDRS
Arguments Arguments
========= =========
``fd`` ``fd``
File descriptor returned by :c:func:`open() <cec-open>`. File descriptor returned by :c:func:`open()`.
``argp`` ``argp``
Pointer to struct :c:type:`cec_log_addrs`. Pointer to struct :c:type:`cec_log_addrs`.
...@@ -148,7 +150,6 @@ logical address types are already defined will return with error ``EBUSY``. ...@@ -148,7 +150,6 @@ logical address types are already defined will return with error ``EBUSY``.
give the CEC framework more information about the device type, even give the CEC framework more information about the device type, even
though the framework won't use it directly in the CEC message. though the framework won't use it directly in the CEC message.
.. tabularcolumns:: |p{7.8cm}|p{1.0cm}|p{8.7cm}| .. tabularcolumns:: |p{7.8cm}|p{1.0cm}|p{8.7cm}|
.. _cec-log-addrs-flags: .. _cec-log-addrs-flags:
...@@ -185,7 +186,6 @@ logical address types are already defined will return with error ``EBUSY``. ...@@ -185,7 +186,6 @@ logical address types are already defined will return with error ``EBUSY``.
All other messages are ignored. All other messages are ignored.
.. tabularcolumns:: |p{7.8cm}|p{1.0cm}|p{8.7cm}| .. tabularcolumns:: |p{7.8cm}|p{1.0cm}|p{8.7cm}|
.. _cec-versions: .. _cec-versions:
...@@ -211,7 +211,6 @@ logical address types are already defined will return with error ``EBUSY``. ...@@ -211,7 +211,6 @@ logical address types are already defined will return with error ``EBUSY``.
- 6 - 6
- CEC version according to the HDMI 2.0 standard. - CEC version according to the HDMI 2.0 standard.
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}| .. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. _cec-prim-dev-types: .. _cec-prim-dev-types:
...@@ -257,7 +256,6 @@ logical address types are already defined will return with error ``EBUSY``. ...@@ -257,7 +256,6 @@ logical address types are already defined will return with error ``EBUSY``.
- 7 - 7
- Use for a video processor device. - Use for a video processor device.
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}| .. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. _cec-log-addr-types: .. _cec-log-addr-types:
...@@ -306,7 +304,6 @@ logical address types are already defined will return with error ``EBUSY``. ...@@ -306,7 +304,6 @@ logical address types are already defined will return with error ``EBUSY``.
Control). Control).
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}| .. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. _cec-all-dev-types-flags: .. _cec-all-dev-types-flags:
...@@ -348,7 +345,6 @@ logical address types are already defined will return with error ``EBUSY``. ...@@ -348,7 +345,6 @@ logical address types are already defined will return with error ``EBUSY``.
- This supports the CEC Switch or Video Processing type. - This supports the CEC Switch or Video Processing type.
Return Value Return Value
============ ============
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: CEC
.. _CEC_ADAP_PHYS_ADDR: .. _CEC_ADAP_PHYS_ADDR:
.. _CEC_ADAP_G_PHYS_ADDR: .. _CEC_ADAP_G_PHYS_ADDR:
...@@ -13,21 +14,22 @@ Name ...@@ -13,21 +14,22 @@ Name
CEC_ADAP_G_PHYS_ADDR, CEC_ADAP_S_PHYS_ADDR - Get or set the physical address CEC_ADAP_G_PHYS_ADDR, CEC_ADAP_S_PHYS_ADDR - Get or set the physical address
Synopsis Synopsis
======== ========
.. c:function:: int ioctl( int fd, CEC_ADAP_G_PHYS_ADDR, __u16 *argp ) .. c:macro:: CEC_ADAP_G_PHYS_ADDR
:name: CEC_ADAP_G_PHYS_ADDR
``int ioctl(int fd, CEC_ADAP_G_PHYS_ADDR, __u16 *argp)``
.. c:function:: int ioctl( int fd, CEC_ADAP_S_PHYS_ADDR, __u16 *argp ) .. c:macro:: CEC_ADAP_S_PHYS_ADDR
:name: CEC_ADAP_S_PHYS_ADDR
``int ioctl(int fd, CEC_ADAP_S_PHYS_ADDR, __u16 *argp)``
Arguments Arguments
========= =========
``fd`` ``fd``
File descriptor returned by :c:func:`open() <cec-open>`. File descriptor returned by :c:func:`open()`.
``argp`` ``argp``
Pointer to the CEC address. Pointer to the CEC address.
...@@ -71,7 +73,6 @@ For example, the EDID for each HDMI input of the TV will have a ...@@ -71,7 +73,6 @@ For example, the EDID for each HDMI input of the TV will have a
different physical address of the form a.0.0.0 that the sources will different physical address of the form a.0.0.0 that the sources will
read out and use as their physical address. read out and use as their physical address.
Return Value Return Value
============ ============
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: CEC
.. _CEC_DQEVENT: .. _CEC_DQEVENT:
...@@ -11,22 +12,21 @@ Name ...@@ -11,22 +12,21 @@ Name
CEC_DQEVENT - Dequeue a CEC event CEC_DQEVENT - Dequeue a CEC event
Synopsis Synopsis
======== ========
.. c:function:: int ioctl( int fd, CEC_DQEVENT, struct cec_event *argp ) .. c:macro:: CEC_DQEVENT
:name: CEC_DQEVENT
``int ioctl(int fd, CEC_DQEVENT, struct cec_event *argp)``
Arguments Arguments
========= =========
``fd`` ``fd``
File descriptor returned by :c:func:`open() <cec-open>`. File descriptor returned by :c:func:`open()`.
``argp`` ``argp``
Description Description
=========== ===========
...@@ -72,7 +72,6 @@ it is guaranteed that the state did change in between the two events. ...@@ -72,7 +72,6 @@ it is guaranteed that the state did change in between the two events.
the HDMI driver is still configuring the device or because the HDMI the HDMI driver is still configuring the device or because the HDMI
device was unbound. device was unbound.
.. c:type:: cec_event_lost_msgs .. c:type:: cec_event_lost_msgs
.. tabularcolumns:: |p{1.0cm}|p{2.0cm}|p{14.5cm}| .. tabularcolumns:: |p{1.0cm}|p{2.0cm}|p{14.5cm}|
...@@ -94,7 +93,6 @@ it is guaranteed that the state did change in between the two events. ...@@ -94,7 +93,6 @@ it is guaranteed that the state did change in between the two events.
replied to within a second according to the CEC specification, replied to within a second according to the CEC specification,
this is more than enough. this is more than enough.
.. tabularcolumns:: |p{1.0cm}|p{4.4cm}|p{2.5cm}|p{9.6cm}| .. tabularcolumns:: |p{1.0cm}|p{4.4cm}|p{2.5cm}|p{9.6cm}|
.. c:type:: cec_event .. c:type:: cec_event
...@@ -130,7 +128,6 @@ it is guaranteed that the state did change in between the two events. ...@@ -130,7 +128,6 @@ it is guaranteed that the state did change in between the two events.
* - } * - }
- -
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}| .. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
.. _cec-events: .. _cec-events:
...@@ -204,7 +201,6 @@ it is guaranteed that the state did change in between the two events. ...@@ -204,7 +201,6 @@ it is guaranteed that the state did change in between the two events.
if the 5V is high, then an initial event will be generated for that if the 5V is high, then an initial event will be generated for that
filehandle. filehandle.
.. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}| .. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}|
.. _cec-event-flags: .. _cec-event-flags:
...@@ -230,7 +226,6 @@ it is guaranteed that the state did change in between the two events. ...@@ -230,7 +226,6 @@ it is guaranteed that the state did change in between the two events.
This is an indication that the application cannot keep up. This is an indication that the application cannot keep up.
Return Value Return Value
============ ============
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: CEC
.. _CEC_MODE: .. _CEC_MODE:
.. _CEC_G_MODE: .. _CEC_G_MODE:
...@@ -13,17 +14,19 @@ CEC_G_MODE, CEC_S_MODE - Get or set exclusive use of the CEC adapter ...@@ -13,17 +14,19 @@ CEC_G_MODE, CEC_S_MODE - Get or set exclusive use of the CEC adapter
Synopsis Synopsis
======== ========
.. c:function:: int ioctl( int fd, CEC_G_MODE, __u32 *argp ) .. c:macro:: CEC_G_MODE
:name: CEC_G_MODE
.. c:function:: int ioctl( int fd, CEC_S_MODE, __u32 *argp ) ``int ioctl(int fd, CEC_G_MODE, __u32 *argp)``
:name: CEC_S_MODE
.. c:macro:: CEC_S_MODE
``int ioctl(int fd, CEC_S_MODE, __u32 *argp)``
Arguments Arguments
========= =========
``fd`` ``fd``
File descriptor returned by :c:func:`open() <cec-open>`. File descriptor returned by :c:func:`open()`.
``argp`` ``argp``
Pointer to CEC mode. Pointer to CEC mode.
...@@ -101,7 +104,6 @@ Available initiator modes are: ...@@ -101,7 +104,6 @@ Available initiator modes are:
then an attempt to become one will return the ``EBUSY`` error code then an attempt to become one will return the ``EBUSY`` error code
error. error.
Available follower modes are: Available follower modes are:
.. tabularcolumns:: |p{6.6cm}|p{0.9cm}|p{10.0cm}| .. tabularcolumns:: |p{6.6cm}|p{0.9cm}|p{10.0cm}|
...@@ -193,7 +195,6 @@ Available follower modes are: ...@@ -193,7 +195,6 @@ Available follower modes are:
the process has the ``CAP_NET_ADMIN`` capability. If that is not the process has the ``CAP_NET_ADMIN`` capability. If that is not
set, then the ``EPERM`` error code is returned. set, then the ``EPERM`` error code is returned.
Core message processing details: Core message processing details:
.. tabularcolumns:: |p{6.6cm}|p{10.9cm}| .. tabularcolumns:: |p{6.6cm}|p{10.9cm}|
...@@ -272,7 +273,6 @@ Core message processing details: ...@@ -272,7 +273,6 @@ Core message processing details:
and then just pass the message on to the follower(s). and then just pass the message on to the follower(s).
Return Value Return Value
============ ============
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: CEC
.. _CEC_TRANSMIT: .. _CEC_TRANSMIT:
.. _CEC_RECEIVE: .. _CEC_RECEIVE:
...@@ -12,21 +13,22 @@ Name ...@@ -12,21 +13,22 @@ Name
CEC_RECEIVE, CEC_TRANSMIT - Receive or transmit a CEC message CEC_RECEIVE, CEC_TRANSMIT - Receive or transmit a CEC message
Synopsis Synopsis
======== ========
.. c:function:: int ioctl( int fd, CEC_RECEIVE, struct cec_msg \*argp ) .. c:macro:: CEC_RECEIVE
:name: CEC_RECEIVE
``int ioctl(int fd, CEC_RECEIVE, struct cec_msg *argp)``
.. c:function:: int ioctl( int fd, CEC_TRANSMIT, struct cec_msg \*argp ) .. c:macro:: CEC_TRANSMIT
:name: CEC_TRANSMIT
``int ioctl(int fd, CEC_TRANSMIT, struct cec_msg *argp)``
Arguments Arguments
========= =========
``fd`` ``fd``
File descriptor returned by :c:func:`open() <cec-open>`. File descriptor returned by :c:func:`open()`.
``argp`` ``argp``
Pointer to struct cec_msg. Pointer to struct cec_msg.
...@@ -194,7 +196,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). ...@@ -194,7 +196,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
supports this, otherwise it is always 0. This counter is only supports this, otherwise it is always 0. This counter is only
valid if the :ref:`CEC_TX_STATUS_ERROR <CEC-TX-STATUS-ERROR>` status bit is set. valid if the :ref:`CEC_TX_STATUS_ERROR <CEC-TX-STATUS-ERROR>` status bit is set.
.. tabularcolumns:: |p{6.2cm}|p{1.0cm}|p{10.3cm}| .. tabularcolumns:: |p{6.2cm}|p{1.0cm}|p{10.3cm}|
.. _cec-msg-flags: .. _cec-msg-flags:
...@@ -228,7 +229,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). ...@@ -228,7 +229,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
capability. If that is not set, then the ``EPERM`` error code is capability. If that is not set, then the ``EPERM`` error code is
returned. returned.
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}| .. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
.. _cec-tx-status: .. _cec-tx-status:
...@@ -298,7 +298,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). ...@@ -298,7 +298,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
- The transmit timed out. This should not normally happen and this - The transmit timed out. This should not normally happen and this
indicates a driver problem. indicates a driver problem.
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}| .. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
.. _cec-rx-status: .. _cec-rx-status:
...@@ -335,7 +334,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). ...@@ -335,7 +334,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
reply was interrupted. reply was interrupted.
Return Value Return Value
============ ============
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_BILINGUAL_CHANNEL_SELECT: .. _AUDIO_BILINGUAL_CHANNEL_SELECT:
...@@ -16,9 +17,9 @@ AUDIO_BILINGUAL_CHANNEL_SELECT ...@@ -16,9 +17,9 @@ AUDIO_BILINGUAL_CHANNEL_SELECT
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_BILINGUAL_CHANNEL_SELECT, struct *audio_channel_select) .. c:macro:: AUDIO_BILINGUAL_CHANNEL_SELECT
:name: AUDIO_BILINGUAL_CHANNEL_SELECT
``int ioctl(int fd, AUDIO_BILINGUAL_CHANNEL_SELECT, struct audio_channel_select *select)``
Arguments Arguments
--------- ---------
...@@ -39,7 +40,6 @@ Arguments ...@@ -39,7 +40,6 @@ Arguments
- Select the output format of the audio (mono left/right, stereo). - Select the output format of the audio (mono left/right, stereo).
Description Description
----------- -----------
...@@ -50,7 +50,6 @@ for MPEG decoders controlled through V4L2. ...@@ -50,7 +50,6 @@ for MPEG decoders controlled through V4L2.
This ioctl call asks the Audio Device to select the requested channel This ioctl call asks the Audio Device to select the requested channel
for bilingual streams if possible. for bilingual streams if possible.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_CHANNEL_SELECT: .. _AUDIO_CHANNEL_SELECT:
...@@ -16,9 +17,9 @@ AUDIO_CHANNEL_SELECT ...@@ -16,9 +17,9 @@ AUDIO_CHANNEL_SELECT
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_CHANNEL_SELECT, struct *audio_channel_select) .. c:macro:: AUDIO_CHANNEL_SELECT
:name: AUDIO_CHANNEL_SELECT
``int ioctl(int fd, AUDIO_CHANNEL_SELECT, struct audio_channel_select *select)``
Arguments Arguments
--------- ---------
...@@ -27,7 +28,6 @@ Arguments ...@@ -27,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- -
- int fd - int fd
...@@ -40,7 +40,6 @@ Arguments ...@@ -40,7 +40,6 @@ Arguments
- Select the output format of the audio (mono left/right, stereo). - Select the output format of the audio (mono left/right, stereo).
Description Description
----------- -----------
...@@ -50,7 +49,6 @@ V4L2 ``V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK`` control instead. ...@@ -50,7 +49,6 @@ V4L2 ``V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK`` control instead.
This ioctl call asks the Audio Device to select the requested channel if This ioctl call asks the Audio Device to select the requested channel if
possible. possible.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_CLEAR_BUFFER: .. _AUDIO_CLEAR_BUFFER:
...@@ -16,8 +17,9 @@ AUDIO_CLEAR_BUFFER ...@@ -16,8 +17,9 @@ AUDIO_CLEAR_BUFFER
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_CLEAR_BUFFER) .. c:macro:: AUDIO_CLEAR_BUFFER
:name: AUDIO_CLEAR_BUFFER
``int ioctl(int fd, AUDIO_CLEAR_BUFFER)``
Arguments Arguments
--------- ---------
...@@ -26,7 +28,6 @@ Arguments ...@@ -26,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- int fd - int fd
...@@ -39,7 +40,6 @@ Description ...@@ -39,7 +40,6 @@ Description
This ioctl call asks the Audio Device to clear all software and hardware This ioctl call asks the Audio Device to clear all software and hardware
buffers of the audio decoder device. buffers of the audio decoder device.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_CONTINUE: .. _AUDIO_CONTINUE:
...@@ -16,9 +17,9 @@ AUDIO_CONTINUE ...@@ -16,9 +17,9 @@ AUDIO_CONTINUE
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_CONTINUE) .. c:macro:: AUDIO_CONTINUE
:name: AUDIO_CONTINUE
``int ioctl(int fd, AUDIO_CONTINUE)``
Arguments Arguments
--------- ---------
...@@ -27,7 +28,6 @@ Arguments ...@@ -27,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- int fd - int fd
...@@ -40,7 +40,6 @@ Description ...@@ -40,7 +40,6 @@ Description
This ioctl restarts the decoding and playing process previously paused This ioctl restarts the decoding and playing process previously paused
with AUDIO_PAUSE command. with AUDIO_PAUSE command.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _audio_fclose: .. _audio_fclose:
...@@ -17,8 +18,6 @@ Synopsis ...@@ -17,8 +18,6 @@ Synopsis
-------- --------
.. c:function:: int close(int fd) .. c:function:: int close(int fd)
:name: dvb-audio-close
Arguments Arguments
--------- ---------
...@@ -27,20 +26,17 @@ Arguments ...@@ -27,20 +26,17 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- int fd - int fd
- File descriptor returned by a previous call to open(). - File descriptor returned by a previous call to open().
Description Description
----------- -----------
This system call closes a previously opened audio device. This system call closes a previously opened audio device.
Return Value Return Value
------------ ------------
...@@ -48,7 +44,6 @@ Return Value ...@@ -48,7 +44,6 @@ Return Value
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- ``EBADF`` - ``EBADF``
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _audio_fopen: .. _audio_fopen:
...@@ -17,8 +18,6 @@ Synopsis ...@@ -17,8 +18,6 @@ Synopsis
-------- --------
.. c:function:: int open(const char *deviceName, int flags) .. c:function:: int open(const char *deviceName, int flags)
:name: dvb-audio-open
Arguments Arguments
--------- ---------
...@@ -27,7 +26,6 @@ Arguments ...@@ -27,7 +26,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- const char \*deviceName - const char \*deviceName
...@@ -60,7 +58,6 @@ Arguments ...@@ -60,7 +58,6 @@ Arguments
- -
- (blocking mode is the default) - (blocking mode is the default)
Description Description
----------- -----------
...@@ -78,7 +75,6 @@ fail, and an error code will be returned. If the Audio Device is opened ...@@ -78,7 +75,6 @@ fail, and an error code will be returned. If the Audio Device is opened
in O_RDONLY mode, the only ioctl call that can be used is in O_RDONLY mode, the only ioctl call that can be used is
AUDIO_GET_STATUS. All other call will return with an error code. AUDIO_GET_STATUS. All other call will return with an error code.
Return Value Return Value
------------ ------------
...@@ -88,7 +84,6 @@ Return Value ...@@ -88,7 +84,6 @@ Return Value
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- ``ENODEV`` - ``ENODEV``
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _audio_fwrite: .. _audio_fwrite:
...@@ -17,8 +18,6 @@ Synopsis ...@@ -17,8 +18,6 @@ Synopsis
-------- --------
.. c:function:: size_t write(int fd, const void *buf, size_t count) .. c:function:: size_t write(int fd, const void *buf, size_t count)
:name: dvb-audio-write
Arguments Arguments
--------- ---------
...@@ -27,7 +26,6 @@ Arguments ...@@ -27,7 +26,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- int fd - int fd
...@@ -46,7 +44,6 @@ Arguments ...@@ -46,7 +44,6 @@ Arguments
- Size of buf. - Size of buf.
Description Description
----------- -----------
...@@ -56,7 +53,6 @@ PES format. If O_NONBLOCK is not specified the function will block ...@@ -56,7 +53,6 @@ PES format. If O_NONBLOCK is not specified the function will block
until buffer space is available. The amount of data to be transferred is until buffer space is available. The amount of data to be transferred is
implied by count. implied by count.
Return Value Return Value
------------ ------------
...@@ -64,7 +60,6 @@ Return Value ...@@ -64,7 +60,6 @@ Return Value
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- ``EPERM`` - ``EPERM``
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_GET_CAPABILITIES: .. _AUDIO_GET_CAPABILITIES:
...@@ -16,9 +17,9 @@ AUDIO_GET_CAPABILITIES ...@@ -16,9 +17,9 @@ AUDIO_GET_CAPABILITIES
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_GET_CAPABILITIES, unsigned int *cap) .. c:macro:: AUDIO_GET_CAPABILITIES
:name: AUDIO_GET_CAPABILITIES
``int ioctl(int fd, AUDIO_GET_CAPABILITIES, unsigned int *cap)``
Arguments Arguments
--------- ---------
...@@ -27,7 +28,6 @@ Arguments ...@@ -27,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- -
- int fd - int fd
...@@ -40,14 +40,12 @@ Arguments ...@@ -40,14 +40,12 @@ Arguments
- Returns a bit array of supported sound formats. - Returns a bit array of supported sound formats.
Description Description
----------- -----------
This ioctl call asks the Audio Device to tell us about the decoding This ioctl call asks the Audio Device to tell us about the decoding
capabilities of the audio hardware. capabilities of the audio hardware.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_GET_STATUS: .. _AUDIO_GET_STATUS:
...@@ -16,9 +17,9 @@ AUDIO_GET_STATUS ...@@ -16,9 +17,9 @@ AUDIO_GET_STATUS
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_GET_STATUS, struct audio_status *status) .. c:macro:: AUDIO_GET_STATUS
:name: AUDIO_GET_STATUS
``int ioctl(int fd, AUDIO_GET_STATUS, struct audio_status *status)``
Arguments Arguments
--------- ---------
...@@ -27,7 +28,6 @@ Arguments ...@@ -27,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- -
- int fd - int fd
...@@ -40,14 +40,12 @@ Arguments ...@@ -40,14 +40,12 @@ Arguments
- Returns the current state of Audio Device. - Returns the current state of Audio Device.
Description Description
----------- -----------
This ioctl call asks the Audio Device to return the current state of the This ioctl call asks the Audio Device to return the current state of the
Audio Device. Audio Device.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_PAUSE: .. _AUDIO_PAUSE:
...@@ -16,8 +17,9 @@ AUDIO_PAUSE ...@@ -16,8 +17,9 @@ AUDIO_PAUSE
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_PAUSE) .. c:macro:: AUDIO_PAUSE
:name: AUDIO_PAUSE
``int ioctl(int fd, AUDIO_PAUSE)``
Arguments Arguments
--------- ---------
...@@ -26,14 +28,12 @@ Arguments ...@@ -26,14 +28,12 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- int fd - int fd
- File descriptor returned by a previous call to open(). - File descriptor returned by a previous call to open().
Description Description
----------- -----------
...@@ -41,7 +41,6 @@ This ioctl call suspends the audio stream being played. Decoding and ...@@ -41,7 +41,6 @@ This ioctl call suspends the audio stream being played. Decoding and
playing are paused. It is then possible to restart again decoding and playing are paused. It is then possible to restart again decoding and
playing process of the audio stream using AUDIO_CONTINUE command. playing process of the audio stream using AUDIO_CONTINUE command.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_PLAY: .. _AUDIO_PLAY:
...@@ -16,9 +17,9 @@ AUDIO_PLAY ...@@ -16,9 +17,9 @@ AUDIO_PLAY
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_PLAY) .. c:macro:: AUDIO_PLAY
:name: AUDIO_PLAY
``int ioctl(int fd, AUDIO_PLAY)``
Arguments Arguments
--------- ---------
...@@ -27,7 +28,6 @@ Arguments ...@@ -27,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- int fd - int fd
...@@ -40,7 +40,6 @@ Description ...@@ -40,7 +40,6 @@ Description
This ioctl call asks the Audio Device to start playing an audio stream This ioctl call asks the Audio Device to start playing an audio stream
from the selected source. from the selected source.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_SELECT_SOURCE: .. _AUDIO_SELECT_SOURCE:
...@@ -16,9 +17,9 @@ AUDIO_SELECT_SOURCE ...@@ -16,9 +17,9 @@ AUDIO_SELECT_SOURCE
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_SELECT_SOURCE, struct audio_stream_source *source) .. c:macro:: AUDIO_SELECT_SOURCE
:name: AUDIO_SELECT_SOURCE
``int ioctl(int fd, AUDIO_SELECT_SOURCE, struct audio_stream_source *source)``
Arguments Arguments
--------- ---------
...@@ -27,7 +28,6 @@ Arguments ...@@ -27,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- -
- int fd - int fd
...@@ -40,7 +40,6 @@ Arguments ...@@ -40,7 +40,6 @@ Arguments
- Indicates the source that shall be used for the Audio stream. - Indicates the source that shall be used for the Audio stream.
Description Description
----------- -----------
...@@ -49,7 +48,6 @@ the input data. The possible sources are demux or memory. If ...@@ -49,7 +48,6 @@ the input data. The possible sources are demux or memory. If
AUDIO_SOURCE_MEMORY is selected, the data is fed to the Audio Device AUDIO_SOURCE_MEMORY is selected, the data is fed to the Audio Device
through the write command. through the write command.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_SET_AV_SYNC: .. _AUDIO_SET_AV_SYNC:
...@@ -16,9 +17,9 @@ AUDIO_SET_AV_SYNC ...@@ -16,9 +17,9 @@ AUDIO_SET_AV_SYNC
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_SET_AV_SYNC, boolean state) .. c:macro:: AUDIO_SET_AV_SYNC
:name: AUDIO_SET_AV_SYNC
``int ioctl(int fd, AUDIO_SET_AV_SYNC, boolean state)``
Arguments Arguments
--------- ---------
...@@ -27,7 +28,6 @@ Arguments ...@@ -27,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- -
- int fd - int fd
...@@ -44,14 +44,12 @@ Arguments ...@@ -44,14 +44,12 @@ Arguments
FALSE: AV-sync OFF FALSE: AV-sync OFF
Description Description
----------- -----------
This ioctl call asks the Audio Device to turn ON or OFF A/V This ioctl call asks the Audio Device to turn ON or OFF A/V
synchronization. synchronization.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_SET_BYPASS_MODE: .. _AUDIO_SET_BYPASS_MODE:
...@@ -16,8 +17,9 @@ AUDIO_SET_BYPASS_MODE ...@@ -16,8 +17,9 @@ AUDIO_SET_BYPASS_MODE
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_SET_BYPASS_MODE, boolean mode) .. c:macro:: AUDIO_SET_BYPASS_MODE
:name: AUDIO_SET_BYPASS_MODE
``int ioctl(int fd, AUDIO_SET_BYPASS_MODE, boolean mode)``
Arguments Arguments
--------- ---------
...@@ -26,7 +28,6 @@ Arguments ...@@ -26,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- -
- int fd - int fd
...@@ -44,7 +45,6 @@ Arguments ...@@ -44,7 +45,6 @@ Arguments
FALSE: Bypass is enabled FALSE: Bypass is enabled
Description Description
----------- -----------
...@@ -54,7 +54,6 @@ that can’t be handled by the Digital TV system shall be decoded. Dolby ...@@ -54,7 +54,6 @@ that can’t be handled by the Digital TV system shall be decoded. Dolby
DigitalTM streams are automatically forwarded by the Digital TV subsystem if DigitalTM streams are automatically forwarded by the Digital TV subsystem if
the hardware can handle it. the hardware can handle it.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_SET_ID: .. _AUDIO_SET_ID:
...@@ -16,8 +17,9 @@ AUDIO_SET_ID ...@@ -16,8 +17,9 @@ AUDIO_SET_ID
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_SET_ID, int id) .. c:macro:: AUDIO_SET_ID
:name: AUDIO_SET_ID
``int ioctl(int fd, AUDIO_SET_ID, int id)``
Arguments Arguments
--------- ---------
...@@ -26,7 +28,6 @@ Arguments ...@@ -26,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- -
- int fd - int fd
...@@ -39,7 +40,6 @@ Arguments ...@@ -39,7 +40,6 @@ Arguments
- audio sub-stream id - audio sub-stream id
Description Description
----------- -----------
...@@ -51,7 +51,6 @@ other stream types. If the stream type is set the id just specifies the ...@@ -51,7 +51,6 @@ other stream types. If the stream type is set the id just specifies the
substream id of the audio stream and only the first 5 bits are substream id of the audio stream and only the first 5 bits are
recognized. recognized.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_SET_MIXER: .. _AUDIO_SET_MIXER:
...@@ -16,8 +17,9 @@ AUDIO_SET_MIXER ...@@ -16,8 +17,9 @@ AUDIO_SET_MIXER
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_SET_MIXER, struct audio_mixer *mix) .. c:macro:: AUDIO_SET_MIXER
:name: AUDIO_SET_MIXER
``int ioctl(int fd, AUDIO_SET_MIXER, struct audio_mixer *mix)``
Arguments Arguments
--------- ---------
...@@ -26,7 +28,6 @@ Arguments ...@@ -26,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- -
- int fd - int fd
...@@ -39,13 +40,11 @@ Arguments ...@@ -39,13 +40,11 @@ Arguments
- mixer settings. - mixer settings.
Description Description
----------- -----------
This ioctl lets you adjust the mixer settings of the audio decoder. This ioctl lets you adjust the mixer settings of the audio decoder.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_SET_MUTE: .. _AUDIO_SET_MUTE:
...@@ -16,9 +17,9 @@ AUDIO_SET_MUTE ...@@ -16,9 +17,9 @@ AUDIO_SET_MUTE
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_SET_MUTE, boolean state) .. c:macro:: AUDIO_SET_MUTE
:name: AUDIO_SET_MUTE
``int ioctl(int fd, AUDIO_SET_MUTE, boolean state)``
Arguments Arguments
--------- ---------
...@@ -27,7 +28,6 @@ Arguments ...@@ -27,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- -
- int fd - int fd
...@@ -44,7 +44,6 @@ Arguments ...@@ -44,7 +44,6 @@ Arguments
FALSE: Audio Un-mute FALSE: Audio Un-mute
Description Description
----------- -----------
...@@ -55,7 +54,6 @@ V4L2 :ref:`VIDIOC_DECODER_CMD` with the ...@@ -55,7 +54,6 @@ V4L2 :ref:`VIDIOC_DECODER_CMD` with the
This ioctl call asks the audio device to mute the stream that is This ioctl call asks the audio device to mute the stream that is
currently being played. currently being played.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_SET_STREAMTYPE: .. _AUDIO_SET_STREAMTYPE:
...@@ -16,9 +17,9 @@ AUDIO_SET_STREAMTYPE ...@@ -16,9 +17,9 @@ AUDIO_SET_STREAMTYPE
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(fd, AUDIO_SET_STREAMTYPE, int type) .. c:macro:: AUDIO_SET_STREAMTYPE
:name: AUDIO_SET_STREAMTYPE
``int ioctl(fd, AUDIO_SET_STREAMTYPE, int type)``
Arguments Arguments
--------- ---------
...@@ -27,7 +28,6 @@ Arguments ...@@ -27,7 +28,6 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- -
- int fd - int fd
...@@ -40,7 +40,6 @@ Arguments ...@@ -40,7 +40,6 @@ Arguments
- stream type - stream type
Description Description
----------- -----------
...@@ -48,7 +47,6 @@ This ioctl tells the driver which kind of audio stream to expect. This ...@@ -48,7 +47,6 @@ This ioctl tells the driver which kind of audio stream to expect. This
is useful if the stream offers several audio sub-streams like LPCM and is useful if the stream offers several audio sub-streams like LPCM and
AC3. AC3.
Return Value Return Value
------------ ------------
...@@ -57,12 +55,10 @@ appropriately. The generic error codes are described at the ...@@ -57,12 +55,10 @@ appropriately. The generic error codes are described at the
:ref:`Generic Error Codes <gen-errors>` chapter. :ref:`Generic Error Codes <gen-errors>` chapter.
.. flat-table:: .. flat-table::
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- ``EINVAL`` - ``EINVAL``
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.audio
.. _AUDIO_STOP: .. _AUDIO_STOP:
...@@ -16,8 +17,9 @@ AUDIO_STOP ...@@ -16,8 +17,9 @@ AUDIO_STOP
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(int fd, AUDIO_STOP) .. c:macro:: AUDIO_STOP
:name: AUDIO_STOP
``int ioctl(int fd, AUDIO_STOP)``
Arguments Arguments
--------- ---------
...@@ -26,21 +28,18 @@ Arguments ...@@ -26,21 +28,18 @@ Arguments
:header-rows: 0 :header-rows: 0
:stub-columns: 0 :stub-columns: 0
- .. row 1 - .. row 1
- int fd - int fd
- File descriptor returned by a previous call to open(). - File descriptor returned by a previous call to open().
Description Description
----------- -----------
This ioctl call asks the Audio Device to stop playing the current This ioctl call asks the Audio Device to stop playing the current
stream. stream.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.ca
.. _ca_fclose: .. _ca_fclose:
...@@ -11,26 +12,22 @@ Name ...@@ -11,26 +12,22 @@ Name
Digital TV CA close() Digital TV CA close()
Synopsis Synopsis
-------- --------
.. c:function:: int close(int fd) .. c:function:: int close(int fd)
:name: dvb-ca-close
Arguments Arguments
--------- ---------
``fd`` ``fd``
File descriptor returned by a previous call to :c:func:`open() <dvb-ca-open>`. File descriptor returned by a previous call to :c:func:`open()`.
Description Description
----------- -----------
This system call closes a previously opened CA device. This system call closes a previously opened CA device.
Return Value Return Value
------------ ------------
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.ca
.. _ca_fopen: .. _ca_fopen:
...@@ -11,13 +12,10 @@ Name ...@@ -11,13 +12,10 @@ Name
Digital TV CA open() Digital TV CA open()
Synopsis Synopsis
-------- --------
.. c:function:: int open(const char *name, int flags) .. c:function:: int open(const char *name, int flags)
:name: dvb-ca-open
Arguments Arguments
--------- ---------
...@@ -45,7 +43,6 @@ Arguments ...@@ -45,7 +43,6 @@ Arguments
- open in non-blocking mode - open in non-blocking mode
(blocking mode is the default) (blocking mode is the default)
Description Description
----------- -----------
...@@ -63,11 +60,9 @@ Only one user can open the CA Device in ``O_RDWR`` mode. All other ...@@ -63,11 +60,9 @@ Only one user can open the CA Device in ``O_RDWR`` mode. All other
attempts to open the device in this mode will fail, and an error code attempts to open the device in this mode will fail, and an error code
will be returned. will be returned.
Return Value Return Value
------------ ------------
On success 0 is returned. On success 0 is returned.
On error -1 is returned, and the ``errno`` variable is set On error -1 is returned, and the ``errno`` variable is set
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.ca
.. _CA_GET_CAP: .. _CA_GET_CAP:
...@@ -11,19 +12,18 @@ Name ...@@ -11,19 +12,18 @@ Name
CA_GET_CAP CA_GET_CAP
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(fd, CA_GET_CAP, struct ca_caps *caps) .. c:macro:: CA_GET_CAP
:name: CA_GET_CAP
``int ioctl(fd, CA_GET_CAP, struct ca_caps *caps)``
Arguments Arguments
--------- ---------
``fd`` ``fd``
File descriptor returned by a previous call to :c:func:`open() <dvb-ca-open>`. File descriptor returned by a previous call to :c:func:`open()`.
``caps`` ``caps``
Pointer to struct :c:type:`ca_caps`. Pointer to struct :c:type:`ca_caps`.
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.ca
.. _CA_GET_DESCR_INFO: .. _CA_GET_DESCR_INFO:
...@@ -11,18 +12,18 @@ Name ...@@ -11,18 +12,18 @@ Name
CA_GET_DESCR_INFO CA_GET_DESCR_INFO
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(fd, CA_GET_DESCR_INFO, struct ca_descr_info *desc) .. c:macro:: CA_GET_DESCR_INFO
:name: CA_GET_DESCR_INFO
``int ioctl(fd, CA_GET_DESCR_INFO, struct ca_descr_info *desc)``
Arguments Arguments
--------- ---------
``fd`` ``fd``
File descriptor returned by a previous call to :c:func:`open() <dvb-ca-open>`. File descriptor returned by a previous call to :c:func:`open()`.
``desc`` ``desc``
Pointer to struct :c:type:`ca_descr_info`. Pointer to struct :c:type:`ca_descr_info`.
......
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: DTV.ca
.. _CA_GET_MSG: .. _CA_GET_MSG:
...@@ -11,19 +12,18 @@ Name ...@@ -11,19 +12,18 @@ Name
CA_GET_MSG CA_GET_MSG
Synopsis Synopsis
-------- --------
.. c:function:: int ioctl(fd, CA_GET_MSG, struct ca_msg *msg) .. c:macro:: CA_GET_MSG
:name: CA_GET_MSG
``int ioctl(fd, CA_GET_MSG, struct ca_msg *msg)``
Arguments Arguments
--------- ---------
``fd`` ``fd``
File descriptor returned by a previous call to :c:func:`open() <dvb-ca-open>`. File descriptor returned by a previous call to :c:func:`open()`.
``msg`` ``msg``
Pointer to struct :c:type:`ca_msg`. Pointer to struct :c:type:`ca_msg`.
...@@ -38,11 +38,9 @@ Receives a message via a CI CA module. ...@@ -38,11 +38,9 @@ Receives a message via a CI CA module.
Please notice that, on most drivers, this is done by reading from Please notice that, on most drivers, this is done by reading from
the /dev/adapter?/ca? device node. the /dev/adapter?/ca? device node.
Return Value Return Value
------------ ------------
On success 0 is returned. On success 0 is returned.
On error -1 is returned, and the ``errno`` variable is set On error -1 is returned, and the ``errno`` variable is set
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment