mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
synced 2025-01-09 07:23:14 +00:00
A handful of relatively small documentation fixes.
-----BEGIN PGP SIGNATURE----- iQFDBAABCAAtFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAl/4lm0PHGNvcmJldEBs d24ubmV0AAoJEBdDWhNsDH5Y6NIH/1em6EcmaiXt1IMMxV0NxTJAVvF+jcJYbMqL 8TSDROb2YXnTpP2uEX04Hq+ioLx1hSL/vl/cKdduQ7g/RvOhJsd0hHBTYjs5XLII 6ENdxoO0sJmxPvEtAaR5vM/YcBpGOGcBXh7Ig3lnciyhBs0Es9YLcyPV0R1SIKmV vVan3wbv4RXyEEw+EMc/e+2mg5zc5AMbgmBULHPMjU5AGCA8uL9NASu+CZUzhAj4 k6x1Itn8hAmSzvHZ9aL4ozUmv4DTV6QDfiZ3DXdTGTp0zvAkDejNtAiEgsoJnFfV Dq5/F6MAB2ehAiEEU4CIOC+nuWs3cw+AIph9TNhlghtLgvKjMa8= =4CWc -----END PGP SIGNATURE----- Merge tag 'docs-5.11-3' of git://git.lwn.net/linux Pull documentation fixes from Jonathan Corbet: "A handful of relatively small documentation fixes" * tag 'docs-5.11-3' of git://git.lwn.net/linux: docs: admin-guide: bootconfig: Fix feils to fails Documentation/admin-guide: kernel-parameters: hyphenate comma-separated docs: binfmt-misc: Fix .rst formatting docs: remove mention of ENABLE_MUST_CHECK atomic: remove further references to atomic_ops Documentation: doc-guide: fixes to sphinx.rst docs/mm: concepts.rst: Correct the threshold to low watermark Documentation: admin: early_param()s are also listed in kernel-parameters docs: Fix reST markup when linking to sections
This commit is contained in:
Linus Torvalds
commit
50dbd96e4f
@ -473,7 +473,7 @@ read-side critical sections that follow the idle period (the oval near
|
||||
the bottom of the diagram above).
|
||||
|
||||
Plumbing this into the full grace-period execution is described
|
||||
`below <#Forcing%20Quiescent%20States>`__.
|
||||
`below <Forcing Quiescent States_>`__.
|
||||
|
||||
CPU-Hotplug Interface
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -494,7 +494,7 @@ mask to detect CPUs having gone offline since the beginning of this
|
||||
grace period.
|
||||
|
||||
Plumbing this into the full grace-period execution is described
|
||||
`below <#Forcing%20Quiescent%20States>`__.
|
||||
`below <Forcing Quiescent States_>`__.
|
||||
|
||||
Forcing Quiescent States
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -532,7 +532,7 @@ from other CPUs.
|
||||
| RCU. But this diagram is complex enough as it is, so simplicity |
|
||||
| overrode accuracy. You can think of it as poetic license, or you can |
|
||||
| think of it as misdirection that is resolved in the |
|
||||
| `stitched-together diagram <#Putting%20It%20All%20Together>`__. |
|
||||
| `stitched-together diagram <Putting It All Together_>`__. |
|
||||
+-----------------------------------------------------------------------+
|
||||
|
||||
Grace-Period Cleanup
|
||||
@ -596,7 +596,7 @@ maintain ordering. For example, if the callback function wakes up a task
|
||||
that runs on some other CPU, proper ordering must in place in both the
|
||||
callback function and the task being awakened. To see why this is
|
||||
important, consider the top half of the `grace-period
|
||||
cleanup <#Grace-Period%20Cleanup>`__ diagram. The callback might be
|
||||
cleanup`_ diagram. The callback might be
|
||||
running on a CPU corresponding to the leftmost leaf ``rcu_node``
|
||||
structure, and awaken a task that is to run on a CPU corresponding to
|
||||
the rightmost leaf ``rcu_node`` structure, and the grace-period kernel
|
||||
|
||||
@ -45,7 +45,7 @@ requirements:
|
||||
#. `Other RCU Flavors`_
|
||||
#. `Possible Future Changes`_
|
||||
|
||||
This is followed by a `summary <#Summary>`__, however, the answers to
|
||||
This is followed by a summary_, however, the answers to
|
||||
each quick quiz immediately follows the quiz. Select the big white space
|
||||
with your mouse to see the answer.
|
||||
|
||||
@ -1096,7 +1096,7 @@ memory barriers.
|
||||
| case, voluntary context switch) within an RCU read-side critical |
|
||||
| section. However, sleeping locks may be used within userspace RCU |
|
||||
| read-side critical sections, and also within Linux-kernel sleepable |
|
||||
| RCU `(SRCU) <#Sleepable%20RCU>`__ read-side critical sections. In |
|
||||
| RCU `(SRCU) <Sleepable RCU_>`__ read-side critical sections. In |
|
||||
| addition, the -rt patchset turns spinlocks into a sleeping locks so |
|
||||
| that the corresponding critical sections can be preempted, which also |
|
||||
| means that these sleeplockified spinlocks (but not other sleeping |
|
||||
@ -1186,7 +1186,7 @@ non-preemptible (``CONFIG_PREEMPT=n``) kernels, and thus `tiny
|
||||
RCU <https://lkml.kernel.org/g/20090113221724.GA15307@linux.vnet.ibm.com>`__
|
||||
was born. Josh Triplett has since taken over the small-memory banner
|
||||
with his `Linux kernel tinification <https://tiny.wiki.kernel.org/>`__
|
||||
project, which resulted in `SRCU <#Sleepable%20RCU>`__ becoming optional
|
||||
project, which resulted in `SRCU <Sleepable RCU_>`__ becoming optional
|
||||
for those kernels not needing it.
|
||||
|
||||
The remaining performance requirements are, for the most part,
|
||||
@ -1457,8 +1457,8 @@ will vary as the value of ``HZ`` varies, and can also be changed using
|
||||
the relevant Kconfig options and kernel boot parameters. RCU currently
|
||||
does not do much sanity checking of these parameters, so please use
|
||||
caution when changing them. Note that these forward-progress measures
|
||||
are provided only for RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks
|
||||
RCU <#Tasks%20RCU>`__.
|
||||
are provided only for RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks
|
||||
RCU`_.
|
||||
|
||||
RCU takes the following steps in ``call_rcu()`` to encourage timely
|
||||
invocation of callbacks when any given non-\ ``rcu_nocbs`` CPU has
|
||||
@ -1477,8 +1477,8 @@ encouragement was provided:
|
||||
|
||||
Again, these are default values when running at ``HZ=1000``, and can be
|
||||
overridden. Again, these forward-progress measures are provided only for
|
||||
RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks
|
||||
RCU <#Tasks%20RCU>`__. Even for RCU, callback-invocation forward
|
||||
RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks
|
||||
RCU`_. Even for RCU, callback-invocation forward
|
||||
progress for ``rcu_nocbs`` CPUs is much less well-developed, in part
|
||||
because workloads benefiting from ``rcu_nocbs`` CPUs tend to invoke
|
||||
``call_rcu()`` relatively infrequently. If workloads emerge that need
|
||||
@ -1920,7 +1920,7 @@ Hotplug CPU
|
||||
|
||||
The Linux kernel supports CPU hotplug, which means that CPUs can come
|
||||
and go. It is of course illegal to use any RCU API member from an
|
||||
offline CPU, with the exception of `SRCU <#Sleepable%20RCU>`__ read-side
|
||||
offline CPU, with the exception of `SRCU <Sleepable RCU_>`__ read-side
|
||||
critical sections. This requirement was present from day one in
|
||||
DYNIX/ptx, but on the other hand, the Linux kernel's CPU-hotplug
|
||||
implementation is “interesting.”
|
||||
@ -2177,7 +2177,7 @@ handles these states differently:
|
||||
However, RCU must be reliably informed as to whether any given CPU is
|
||||
currently in the idle loop, and, for ``NO_HZ_FULL``, also whether that
|
||||
CPU is executing in usermode, as discussed
|
||||
`earlier <#Energy%20Efficiency>`__. It also requires that the
|
||||
`earlier <Energy Efficiency_>`__. It also requires that the
|
||||
scheduling-clock interrupt be enabled when RCU needs it to be:
|
||||
|
||||
#. If a CPU is either idle or executing in usermode, and RCU believes it
|
||||
@ -2294,7 +2294,7 @@ Performance, Scalability, Response Time, and Reliability
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Expanding on the `earlier
|
||||
discussion <#Performance%20and%20Scalability>`__, RCU is used heavily by
|
||||
discussion <Performance and Scalability_>`__, RCU is used heavily by
|
||||
hot code paths in performance-critical portions of the Linux kernel's
|
||||
networking, security, virtualization, and scheduling code paths. RCU
|
||||
must therefore use efficient implementations, especially in its
|
||||
|
||||
@ -23,7 +23,7 @@ Here is what the fields mean:
|
||||
|
||||
- ``name``
|
||||
is an identifier string. A new /proc file will be created with this
|
||||
``name below /proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for
|
||||
name below ``/proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for
|
||||
obvious reasons.
|
||||
- ``type``
|
||||
is the type of recognition. Give ``M`` for magic and ``E`` for extension.
|
||||
@ -83,7 +83,7 @@ Here is what the fields mean:
|
||||
``F`` - fix binary
|
||||
The usual behaviour of binfmt_misc is to spawn the
|
||||
binary lazily when the misc format file is invoked. However,
|
||||
this doesn``t work very well in the face of mount namespaces and
|
||||
this doesn't work very well in the face of mount namespaces and
|
||||
changeroots, so the ``F`` mode opens the binary as soon as the
|
||||
emulation is installed and uses the opened image to spawn the
|
||||
emulator, meaning it is always available once installed,
|
||||
|
||||
@ -154,7 +154,7 @@ get the boot configuration data.
|
||||
Because of this "piggyback" method, there is no need to change or
|
||||
update the boot loader and the kernel image itself as long as the boot
|
||||
loader passes the correct initrd file size. If by any chance, the boot
|
||||
loader passes a longer size, the kernel feils to find the bootconfig data.
|
||||
loader passes a longer size, the kernel fails to find the bootconfig data.
|
||||
|
||||
To do this operation, Linux kernel provides "bootconfig" command under
|
||||
tools/bootconfig, which allows admin to apply or delete the config file
|
||||
|
||||
@ -3,8 +3,8 @@
|
||||
The kernel's command-line parameters
|
||||
====================================
|
||||
|
||||
The following is a consolidated list of the kernel parameters as
|
||||
implemented by the __setup(), core_param() and module_param() macros
|
||||
The following is a consolidated list of the kernel parameters as implemented
|
||||
by the __setup(), early_param(), core_param() and module_param() macros
|
||||
and sorted into English Dictionary order (defined as ignoring all
|
||||
punctuation and sorting digits before letters in a case insensitive
|
||||
manner), and with descriptions where known.
|
||||
|
||||
@ -1385,7 +1385,7 @@
|
||||
|
||||
ftrace_filter=[function-list]
|
||||
[FTRACE] Limit the functions traced by the function
|
||||
tracer at boot up. function-list is a comma separated
|
||||
tracer at boot up. function-list is a comma-separated
|
||||
list of functions. This list can be changed at run
|
||||
time by the set_ftrace_filter file in the debugfs
|
||||
tracing directory.
|
||||
@ -1399,13 +1399,13 @@
|
||||
ftrace_graph_filter=[function-list]
|
||||
[FTRACE] Limit the top level callers functions traced
|
||||
by the function graph tracer at boot up.
|
||||
function-list is a comma separated list of functions
|
||||
function-list is a comma-separated list of functions
|
||||
that can be changed at run time by the
|
||||
set_graph_function file in the debugfs tracing directory.
|
||||
|
||||
ftrace_graph_notrace=[function-list]
|
||||
[FTRACE] Do not trace from the functions specified in
|
||||
function-list. This list is a comma separated list of
|
||||
function-list. This list is a comma-separated list of
|
||||
functions that can be changed at run time by the
|
||||
set_graph_notrace file in the debugfs tracing directory.
|
||||
|
||||
@ -2421,7 +2421,7 @@
|
||||
when set.
|
||||
Format: <int>
|
||||
|
||||
libata.force= [LIBATA] Force configurations. The format is comma
|
||||
libata.force= [LIBATA] Force configurations. The format is comma-
|
||||
separated list of "[ID:]VAL" where ID is
|
||||
PORT[.DEVICE]. PORT and DEVICE are decimal numbers
|
||||
matching port, link or device. Basically, it matches
|
||||
@ -5145,7 +5145,7 @@
|
||||
|
||||
stacktrace_filter=[function-list]
|
||||
[FTRACE] Limit the functions that the stack tracer
|
||||
will trace at boot up. function-list is a comma separated
|
||||
will trace at boot up. function-list is a comma-separated
|
||||
list of functions. This list can be changed at run
|
||||
time by the stack_trace_filter file in the debugfs
|
||||
tracing directory. Note, this enables stack tracing
|
||||
@ -5348,7 +5348,7 @@
|
||||
trace_event=[event-list]
|
||||
[FTRACE] Set and start specified trace events in order
|
||||
to facilitate early boot debugging. The event-list is a
|
||||
comma separated list of trace events to enable. See
|
||||
comma-separated list of trace events to enable. See
|
||||
also Documentation/trace/events.rst
|
||||
|
||||
trace_options=[option-list]
|
||||
|
||||
@ -184,7 +184,7 @@ pages either asynchronously or synchronously, depending on the state
|
||||
of the system. When the system is not loaded, most of the memory is free
|
||||
and allocation requests will be satisfied immediately from the free
|
||||
pages supply. As the load increases, the amount of the free pages goes
|
||||
down and when it reaches a certain threshold (high watermark), an
|
||||
down and when it reaches a certain threshold (low watermark), an
|
||||
allocation request will awaken the ``kswapd`` daemon. It will
|
||||
asynchronously scan memory pages and either just free them if the data
|
||||
they contain is available elsewhere, or evict to the backing storage
|
||||
|
||||
@ -53,7 +53,6 @@ How Linux keeps everything from happening at the same time. See
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
atomic_ops
|
||||
refcount-vs-atomic
|
||||
irq/index
|
||||
local_ops
|
||||
|
||||
@ -48,12 +48,12 @@ or ``virtualenv``, depending on how your distribution packaged Python 3.
|
||||
those versions, you should run ``pip install 'docutils==0.12'``.
|
||||
|
||||
#) It is recommended to use the RTD theme for html output. Depending
|
||||
on the Sphinx version, it should be installed in separate,
|
||||
on the Sphinx version, it should be installed separately,
|
||||
with ``pip install sphinx_rtd_theme``.
|
||||
|
||||
#) Some ReST pages contain math expressions. Due to the way Sphinx work,
|
||||
#) Some ReST pages contain math expressions. Due to the way Sphinx works,
|
||||
those expressions are written using LaTeX notation. It needs texlive
|
||||
installed with amdfonts and amsmath in order to evaluate them.
|
||||
installed with amsfonts and amsmath in order to evaluate them.
|
||||
|
||||
In summary, if you want to install Sphinx version 1.7.9, you should do::
|
||||
|
||||
@ -128,7 +128,7 @@ Sphinx Build
|
||||
============
|
||||
|
||||
The usual way to generate the documentation is to run ``make htmldocs`` or
|
||||
``make pdfdocs``. There are also other formats available, see the documentation
|
||||
``make pdfdocs``. There are also other formats available: see the documentation
|
||||
section of ``make help``. The generated documentation is placed in
|
||||
format-specific subdirectories under ``Documentation/output``.
|
||||
|
||||
@ -303,17 +303,17 @@ and *targets* (e.g. a ref to ``:ref:`last row <last row>``` / :ref:`last row
|
||||
- head col 3
|
||||
- head col 4
|
||||
|
||||
* - column 1
|
||||
* - row 1
|
||||
- field 1.1
|
||||
- field 1.2 with autospan
|
||||
|
||||
* - column 2
|
||||
* - row 2
|
||||
- field 2.1
|
||||
- :rspan:`1` :cspan:`1` field 2.2 - 3.3
|
||||
|
||||
* .. _`last row`:
|
||||
|
||||
- column 3
|
||||
- row 3
|
||||
|
||||
Rendered as:
|
||||
|
||||
@ -325,17 +325,17 @@ Rendered as:
|
||||
- head col 3
|
||||
- head col 4
|
||||
|
||||
* - column 1
|
||||
* - row 1
|
||||
- field 1.1
|
||||
- field 1.2 with autospan
|
||||
|
||||
* - column 2
|
||||
* - row 2
|
||||
- field 2.1
|
||||
- :rspan:`1` :cspan:`1` field 2.2 - 3.3
|
||||
|
||||
* .. _`last row`:
|
||||
|
||||
- column 3
|
||||
- row 3
|
||||
|
||||
Cross-referencing
|
||||
-----------------
|
||||
@ -361,7 +361,7 @@ Figures & Images
|
||||
|
||||
If you want to add an image, you should use the ``kernel-figure`` and
|
||||
``kernel-image`` directives. E.g. to insert a figure with a scalable
|
||||
image format use SVG (:ref:`svg_image_example`)::
|
||||
image format, use SVG (:ref:`svg_image_example`)::
|
||||
|
||||
.. kernel-figure:: svg_image.svg
|
||||
:alt: simple SVG image
|
||||
@ -375,7 +375,7 @@ image format use SVG (:ref:`svg_image_example`)::
|
||||
|
||||
SVG image example
|
||||
|
||||
The kernel figure (and image) directive support **DOT** formatted files, see
|
||||
The kernel figure (and image) directive supports **DOT** formatted files, see
|
||||
|
||||
* DOT: http://graphviz.org/pdf/dotguide.pdf
|
||||
* Graphviz: http://www.graphviz.org/content/dot-language
|
||||
@ -394,7 +394,7 @@ A simple example (:ref:`hello_dot_file`)::
|
||||
|
||||
DOT's hello world example
|
||||
|
||||
Embed *render* markups (or languages) like Graphviz's **DOT** is provided by the
|
||||
Embedded *render* markups (or languages) like Graphviz's **DOT** are provided by the
|
||||
``kernel-render`` directives.::
|
||||
|
||||
.. kernel-render:: DOT
|
||||
@ -406,7 +406,7 @@ Embed *render* markups (or languages) like Graphviz's **DOT** is provided by the
|
||||
}
|
||||
|
||||
How this will be rendered depends on the installed tools. If Graphviz is
|
||||
installed, you will see an vector image. If not the raw markup is inserted as
|
||||
installed, you will see a vector image. If not, the raw markup is inserted as
|
||||
*literal-block* (:ref:`hello_dot_render`).
|
||||
|
||||
.. _hello_dot_render:
|
||||
@ -421,8 +421,8 @@ installed, you will see an vector image. If not the raw markup is inserted as
|
||||
|
||||
The *render* directive has all the options known from the *figure* directive,
|
||||
plus option ``caption``. If ``caption`` has a value, a *figure* node is
|
||||
inserted. If not, a *image* node is inserted. A ``caption`` is also needed, if
|
||||
you want to refer it (:ref:`hello_svg_render`).
|
||||
inserted. If not, an *image* node is inserted. A ``caption`` is also needed, if
|
||||
you want to refer to it (:ref:`hello_svg_render`).
|
||||
|
||||
Embedded **SVG**::
|
||||
|
||||
|
||||
@ -118,11 +118,11 @@ spinlock, but you may block holding a mutex. If you can't lock a mutex,
|
||||
your task will suspend itself, and be woken up when the mutex is
|
||||
released. This means the CPU can do something else while you are
|
||||
waiting. There are many cases when you simply can't sleep (see
|
||||
`What Functions Are Safe To Call From Interrupts? <#sleeping-things>`__),
|
||||
`What Functions Are Safe To Call From Interrupts?`_),
|
||||
and so have to use a spinlock instead.
|
||||
|
||||
Neither type of lock is recursive: see
|
||||
`Deadlock: Simple and Advanced <#deadlock>`__.
|
||||
`Deadlock: Simple and Advanced`_.
|
||||
|
||||
Locks and Uniprocessor Kernels
|
||||
------------------------------
|
||||
@ -179,7 +179,7 @@ perfect world).
|
||||
|
||||
Note that you can also use spin_lock_irq() or
|
||||
spin_lock_irqsave() here, which stop hardware interrupts
|
||||
as well: see `Hard IRQ Context <#hard-irq-context>`__.
|
||||
as well: see `Hard IRQ Context`_.
|
||||
|
||||
This works perfectly for UP as well: the spin lock vanishes, and this
|
||||
macro simply becomes local_bh_disable()
|
||||
@ -230,7 +230,7 @@ The Same Softirq
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The same softirq can run on the other CPUs: you can use a per-CPU array
|
||||
(see `Per-CPU Data <#per-cpu-data>`__) for better performance. If you're
|
||||
(see `Per-CPU Data`_) for better performance. If you're
|
||||
going so far as to use a softirq, you probably care about scalable
|
||||
performance enough to justify the extra complexity.
|
||||
|
||||
|
||||
@ -249,10 +249,8 @@ features; most of these are found in the "kernel hacking" submenu. Several
|
||||
of these options should be turned on for any kernel used for development or
|
||||
testing purposes. In particular, you should turn on:
|
||||
|
||||
- ENABLE_MUST_CHECK and FRAME_WARN to get an
|
||||
extra set of warnings for problems like the use of deprecated interfaces
|
||||
or ignoring an important return value from a function. The output
|
||||
generated by these warnings can be verbose, but one need not worry about
|
||||
- FRAME_WARN to get warnings for stack frames larger than a given amount.
|
||||
The output generated can be verbose, but one need not worry about
|
||||
warnings from other parts of the kernel.
|
||||
|
||||
- DEBUG_OBJECTS will add code to track the lifetime of various objects
|
||||
|
||||
@ -71,7 +71,7 @@ core/oss
|
||||
The codes for PCM and mixer OSS emulation modules are stored in this
|
||||
directory. The rawmidi OSS emulation is included in the ALSA rawmidi
|
||||
code since it's quite small. The sequencer code is stored in
|
||||
``core/seq/oss`` directory (see `below <#core-seq-oss>`__).
|
||||
``core/seq/oss`` directory (see `below <core/seq/oss_>`__).
|
||||
|
||||
core/seq
|
||||
~~~~~~~~
|
||||
@ -382,7 +382,7 @@ where ``enable[dev]`` is the module option.
|
||||
Each time the ``probe`` callback is called, check the availability of
|
||||
the device. If not available, simply increment the device index and
|
||||
returns. dev will be incremented also later (`step 7
|
||||
<#set-the-pci-driver-data-and-return-zero>`__).
|
||||
<7) Set the PCI driver data and return zero._>`__).
|
||||
|
||||
2) Create a card instance
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -450,10 +450,10 @@ field contains the information shown in ``/proc/asound/cards``.
|
||||
5) Create other components, such as mixer, MIDI, etc.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Here you define the basic components such as `PCM <#PCM-Interface>`__,
|
||||
mixer (e.g. `AC97 <#API-for-AC97-Codec>`__), MIDI (e.g.
|
||||
`MPU-401 <#MIDI-MPU401-UART-Interface>`__), and other interfaces.
|
||||
Also, if you want a `proc file <#Proc-Interface>`__, define it here,
|
||||
Here you define the basic components such as `PCM <PCM Interface_>`__,
|
||||
mixer (e.g. `AC97 <API for AC97 Codec_>`__), MIDI (e.g.
|
||||
`MPU-401 <MIDI (MPU401-UART) Interface_>`__), and other interfaces.
|
||||
Also, if you want a `proc file <Proc Interface_>`__, define it here,
|
||||
too.
|
||||
|
||||
6) Register the card instance.
|
||||
@ -941,7 +941,7 @@ The allocation of an interrupt source is done like this:
|
||||
chip->irq = pci->irq;
|
||||
|
||||
where :c:func:`snd_mychip_interrupt()` is the interrupt handler
|
||||
defined `later <#pcm-interface-interrupt-handler>`__. Note that
|
||||
defined `later <PCM Interrupt Handler_>`__. Note that
|
||||
``chip->irq`` should be defined only when :c:func:`request_irq()`
|
||||
succeeded.
|
||||
|
||||
@ -3104,7 +3104,7 @@ processing the output stream in the irq handler.
|
||||
|
||||
If the MPU-401 interface shares its interrupt with the other logical
|
||||
devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see
|
||||
`below <#MIDI-Interrupt-Handler>`__).
|
||||
`below <MIDI Interrupt Handler_>`__).
|
||||
|
||||
Usually, the port address corresponds to the command port and port + 1
|
||||
corresponds to the data port. If not, you may change the ``cport``
|
||||
|
||||
@ -10260,7 +10260,6 @@ S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev
|
||||
F: Documentation/atomic_bitops.txt
|
||||
F: Documentation/atomic_t.txt
|
||||
F: Documentation/core-api/atomic_ops.rst
|
||||
F: Documentation/core-api/refcount-vs-atomic.rst
|
||||
F: Documentation/litmus-tests/
|
||||
F: Documentation/memory-barriers.txt
|
||||
|
||||
Loading…
Reference in New Issue
Block a user