You've already forked linux-rockchip
mirror of
https://github.com/armbian/linux-rockchip.git
synced 2026-01-06 11:08:10 -08:00
Merge tag 'docs-6.1' of git://git.lwn.net/linux
Pull documentation updates from Jonathan Corbet:
"There's not a huge amount of activity in the docs tree this time
around, but a few significant changes even so:
- A complete rewriting of the top-level index.rst file, which mostly
reflects itself in a redone top page in the HTML-rendered docs. The
hope is that the new organization will be a friendlier starting
point for both users and developers.
- Some math-rendering improvements.
- A coding-style.rst update on the use of BUG() and WARN()
- A big maintainer-PHP guide update.
- Some code-of-conduct updates
- More Chinese translation work
Plus the usual pile of typo fixes, corrections, and updates"
* tag 'docs-6.1' of git://git.lwn.net/linux: (66 commits)
checkpatch: warn on usage of VM_BUG_ON() and other BUG variants
coding-style.rst: document BUG() and WARN() rules ("do not crash the kernel")
Documentation: devres: add missing IO helper
Documentation: devres: update IRQ helper
Documentation/mm: modify page_referenced to folio_referenced
Documentation/CoC: Reflect current CoC interpretation and practices
docs/doc-guide: Add documentation on SPHINX_IMGMATH
docs: process/5.Posting.rst: clarify use of Reported-by: tag
docs, kprobes: Fix the wrong location of Kprobes
docs: add a man-pages link to the front page
docs: put atomic*.txt and memory-barriers.txt into the core-api book
docs: move asm-annotations.rst into core-api
docs: remove some index.rst cruft
docs: reconfigure the HTML left column
docs: Rewrite the front page
docs: promote the title of process/index.rst
Documentation: devres: add missing SPI helper
Documentation: devres: add missing PINCTRL helpers
docs: hugetlbpage.rst: fix a typo of hugepage size
docs/zh_CN: Add new translation of admin-guide/bootconfig.rst
...
This commit is contained in:
@@ -3,7 +3,7 @@ Date: May 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Rafał Miłecki <zajec5@gmail.com>
|
||||
Description:
|
||||
Each BCMA core has it's manufacturer id. See
|
||||
Each BCMA core has its manufacturer id. See
|
||||
include/linux/bcma/bcma.h for possible values.
|
||||
|
||||
What: /sys/bus/bcma/devices/.../id
|
||||
|
||||
@@ -31,7 +31,7 @@ Description: 'FCoE Controller' instances on the fcoe bus.
|
||||
1) Write interface name to ctlr_create 2) Configure the FCoE
|
||||
Controller (ctlr_X) 3) Enable the FCoE Controller to begin
|
||||
discovery and login. The FCoE Controller is destroyed by
|
||||
writing it's name, i.e. ctlr_X to the ctlr_delete file.
|
||||
writing its name, i.e. ctlr_X to the ctlr_delete file.
|
||||
|
||||
Attributes:
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ Description:
|
||||
on the signal from which time of flight measurements are
|
||||
taken.
|
||||
The appropriate values to take is dependent on both the
|
||||
sensor and it's operating environment:
|
||||
sensor and its operating environment:
|
||||
* as3935 (0-31 range)
|
||||
18 = indoors (default)
|
||||
14 = outdoors
|
||||
|
||||
@@ -296,7 +296,7 @@ Description: Processor frequency boosting control
|
||||
|
||||
This switch controls the boost setting for the whole system.
|
||||
Boosting allows the CPU and the firmware to run at a frequency
|
||||
beyond it's nominal limit.
|
||||
beyond its nominal limit.
|
||||
|
||||
More details can be found in
|
||||
Documentation/admin-guide/pm/cpufreq.rst
|
||||
|
||||
@@ -2,8 +2,8 @@ What: /sys/bus/platform/devices/ci_hdrc.0/role
|
||||
Date: Mar 2017
|
||||
Contact: Peter Chen <peter.chen@nxp.com>
|
||||
Description:
|
||||
It returns string "gadget" or "host" when read it, it indicates
|
||||
current controller role.
|
||||
When read, it returns string "gadget" or "host", indicating
|
||||
the current controller role.
|
||||
|
||||
It will do role switch when write "gadget" or "host" to it.
|
||||
It will do role switch when "gadget" or "host" is written to it.
|
||||
Only controller at dual-role configuration supports writing.
|
||||
|
||||
@@ -152,7 +152,7 @@ Description:
|
||||
case further investigation is required to determine which
|
||||
device is causing the problem. Note that genuine RTC clock
|
||||
values (such as when pm_trace has not been used), can still
|
||||
match a device and output it's name here.
|
||||
match a device and output its name here.
|
||||
|
||||
What: /sys/power/pm_async
|
||||
Date: January 2009
|
||||
|
||||
@@ -486,6 +486,6 @@ over a rather long period of time, but improvements are always welcome!
|
||||
So if you need to wait for both an RCU grace period and for
|
||||
all pre-existing call_rcu() callbacks, you will need to execute
|
||||
both rcu_barrier() and synchronize_rcu(), if necessary, using
|
||||
something like workqueues to to execute them concurrently.
|
||||
something like workqueues to execute them concurrently.
|
||||
|
||||
See rcubarrier.rst for more information.
|
||||
|
||||
@@ -61,7 +61,7 @@ checking of rcu_dereference() primitives:
|
||||
rcu_access_pointer(p):
|
||||
Return the value of the pointer and omit all barriers,
|
||||
but retain the compiler constraints that prevent duplicating
|
||||
or coalescsing. This is useful when when testing the
|
||||
or coalescsing. This is useful when testing the
|
||||
value of the pointer itself, for example, against NULL.
|
||||
|
||||
The rcu_dereference_check() check expression can be any boolean
|
||||
|
||||
@@ -262,8 +262,6 @@ Compiling the kernel
|
||||
- Make sure you have at least gcc 5.1 available.
|
||||
For more information, refer to :ref:`Documentation/process/changes.rst <changes>`.
|
||||
|
||||
Please note that you can still run a.out user programs with this kernel.
|
||||
|
||||
- Do a ``make`` to create a compressed kernel image. It is also
|
||||
possible to do ``make install`` if you have lilo installed to suit the
|
||||
kernel makefiles, but you may want to check your particular lilo setup first.
|
||||
@@ -332,85 +330,10 @@ Compiling the kernel
|
||||
If something goes wrong
|
||||
-----------------------
|
||||
|
||||
- If you have problems that seem to be due to kernel bugs, please check
|
||||
the file MAINTAINERS to see if there is a particular person associated
|
||||
with the part of the kernel that you are having trouble with. If there
|
||||
isn't anyone listed there, then the second best thing is to mail
|
||||
them to me (torvalds@linux-foundation.org), and possibly to any other
|
||||
relevant mailing-list or to the newsgroup.
|
||||
If you have problems that seem to be due to kernel bugs, please follow the
|
||||
instructions at 'Documentation/admin-guide/reporting-issues.rst'.
|
||||
|
||||
- In all bug-reports, *please* tell what kernel you are talking about,
|
||||
how to duplicate the problem, and what your setup is (use your common
|
||||
sense). If the problem is new, tell me so, and if the problem is
|
||||
old, please try to tell me when you first noticed it.
|
||||
|
||||
- If the bug results in a message like::
|
||||
|
||||
unable to handle kernel paging request at address C0000010
|
||||
Oops: 0002
|
||||
EIP: 0010:XXXXXXXX
|
||||
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx
|
||||
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx
|
||||
ds: xxxx es: xxxx fs: xxxx gs: xxxx
|
||||
Pid: xx, process nr: xx
|
||||
xx xx xx xx xx xx xx xx xx xx
|
||||
|
||||
or similar kernel debugging information on your screen or in your
|
||||
system log, please duplicate it *exactly*. The dump may look
|
||||
incomprehensible to you, but it does contain information that may
|
||||
help debugging the problem. The text above the dump is also
|
||||
important: it tells something about why the kernel dumped code (in
|
||||
the above example, it's due to a bad kernel pointer). More information
|
||||
on making sense of the dump is in Documentation/admin-guide/bug-hunting.rst
|
||||
|
||||
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
|
||||
as is, otherwise you will have to use the ``ksymoops`` program to make
|
||||
sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred).
|
||||
This utility can be downloaded from
|
||||
https://www.kernel.org/pub/linux/utils/kernel/ksymoops/ .
|
||||
Alternatively, you can do the dump lookup by hand:
|
||||
|
||||
- In debugging dumps like the above, it helps enormously if you can
|
||||
look up what the EIP value means. The hex value as such doesn't help
|
||||
me or anybody else very much: it will depend on your particular
|
||||
kernel setup. What you should do is take the hex value from the EIP
|
||||
line (ignore the ``0010:``), and look it up in the kernel namelist to
|
||||
see which kernel function contains the offending address.
|
||||
|
||||
To find out the kernel function name, you'll need to find the system
|
||||
binary associated with the kernel that exhibited the symptom. This is
|
||||
the file 'linux/vmlinux'. To extract the namelist and match it against
|
||||
the EIP from the kernel crash, do::
|
||||
|
||||
nm vmlinux | sort | less
|
||||
|
||||
This will give you a list of kernel addresses sorted in ascending
|
||||
order, from which it is simple to find the function that contains the
|
||||
offending address. Note that the address given by the kernel
|
||||
debugging messages will not necessarily match exactly with the
|
||||
function addresses (in fact, that is very unlikely), so you can't
|
||||
just 'grep' the list: the list will, however, give you the starting
|
||||
point of each kernel function, so by looking for the function that
|
||||
has a starting address lower than the one you are searching for but
|
||||
is followed by a function with a higher address you will find the one
|
||||
you want. In fact, it may be a good idea to include a bit of
|
||||
"context" in your problem report, giving a few lines around the
|
||||
interesting one.
|
||||
|
||||
If you for some reason cannot do the above (you have a pre-compiled
|
||||
kernel image or similar), telling me as much about your setup as
|
||||
possible will help. Please read
|
||||
'Documentation/admin-guide/reporting-issues.rst' for details.
|
||||
|
||||
- Alternatively, you can use gdb on a running kernel. (read-only; i.e. you
|
||||
cannot change values or set break points.) To do this, first compile the
|
||||
kernel with -g; edit arch/x86/Makefile appropriately, then do a ``make
|
||||
clean``. You'll also need to enable CONFIG_PROC_FS (via ``make config``).
|
||||
|
||||
After you've rebooted with the new kernel, do ``gdb vmlinux /proc/kcore``.
|
||||
You can now use all the usual gdb commands. The command to look up the
|
||||
point where your system crashed is ``l *0xXXXXXXXX``. (Replace the XXXes
|
||||
with the EIP value.)
|
||||
|
||||
gdb'ing a non-running kernel currently fails because ``gdb`` (wrongly)
|
||||
disregards the starting offset for which the kernel is compiled.
|
||||
Hints on understanding kernel bug reports are in
|
||||
'Documentation/admin-guide/bug-hunting.rst'. More on debugging the kernel
|
||||
with gdb is in 'Documentation/dev-tools/gdb-kernel-debugging.rst' and
|
||||
'Documentation/dev-tools/kgdb.rst'.
|
||||
|
||||
@@ -613,6 +613,7 @@ kernel command line.
|
||||
eibrs enhanced IBRS
|
||||
eibrs,retpoline enhanced IBRS + Retpolines
|
||||
eibrs,lfence enhanced IBRS + LFENCE
|
||||
ibrs use IBRS to protect kernel
|
||||
|
||||
Not specifying this option is equivalent to
|
||||
spectre_v2=auto.
|
||||
|
||||
@@ -200,7 +200,7 @@ prb
|
||||
|
||||
A pointer to the printk ringbuffer (struct printk_ringbuffer). This
|
||||
may be pointing to the static boot ringbuffer or the dynamically
|
||||
allocated ringbuffer, depending on when the the core dump occurred.
|
||||
allocated ringbuffer, depending on when the core dump occurred.
|
||||
Used by user-space tools to read the active kernel log buffer.
|
||||
|
||||
printk_rb_static
|
||||
|
||||
@@ -65,7 +65,7 @@ HugePages_Surp
|
||||
may be temporarily larger than the maximum number of surplus huge
|
||||
pages when the system is under memory pressure.
|
||||
Hugepagesize
|
||||
is the default hugepage size (in Kb).
|
||||
is the default hugepage size (in kB).
|
||||
Hugetlb
|
||||
is the total amount of memory (in kB), consumed by huge
|
||||
pages of all sizes.
|
||||
|
||||
@@ -133,7 +133,7 @@ code field of ``BPF_END``.
|
||||
The byte swap instructions operate on the destination register
|
||||
only and do not use a separate source register or immediate value.
|
||||
|
||||
The 1-bit source operand field in the opcode is used to to select what byte
|
||||
The 1-bit source operand field in the opcode is used to select what byte
|
||||
order the operation convert from or to:
|
||||
|
||||
========= ===== =================================================
|
||||
|
||||
@@ -31,7 +31,7 @@ The map uses key of type of either ``__u64 cgroup_inode_id`` or
|
||||
};
|
||||
|
||||
``cgroup_inode_id`` is the inode id of the cgroup directory.
|
||||
``attach_type`` is the the program's attach type.
|
||||
``attach_type`` is the program's attach type.
|
||||
|
||||
Linux 5.9 added support for type ``__u64 cgroup_inode_id`` as the key type.
|
||||
When this key type is used, then all attach types of the particular cgroup and
|
||||
@@ -155,7 +155,7 @@ However, the BPF program can still only associate with one map of each type
|
||||
``BPF_MAP_TYPE_CGROUP_STORAGE`` or more than one
|
||||
``BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE``.
|
||||
|
||||
In all versions, userspace may use the the attach parameters of cgroup and
|
||||
In all versions, userspace may use the attach parameters of cgroup and
|
||||
attach type pair in ``struct bpf_cgroup_storage_key`` as the key to the BPF map
|
||||
APIs to read or update the storage for a given attachment. For Linux 5.9
|
||||
attach type shared storages, only the first value in the struct, cgroup inode
|
||||
|
||||
@@ -15,6 +15,18 @@
|
||||
import sys
|
||||
import os
|
||||
import sphinx
|
||||
import shutil
|
||||
|
||||
# helper
|
||||
# ------
|
||||
|
||||
def have_command(cmd):
|
||||
"""Search ``cmd`` in the ``PATH`` environment.
|
||||
|
||||
If found, return True.
|
||||
If not found, return False.
|
||||
"""
|
||||
return shutil.which(cmd) is not None
|
||||
|
||||
# Get Sphinx version
|
||||
major, minor, patch = sphinx.version_info[:3]
|
||||
@@ -107,7 +119,32 @@ else:
|
||||
autosectionlabel_prefix_document = True
|
||||
autosectionlabel_maxdepth = 2
|
||||
|
||||
extensions.append("sphinx.ext.imgmath")
|
||||
# Load math renderer:
|
||||
# For html builder, load imgmath only when its dependencies are met.
|
||||
# mathjax is the default math renderer since Sphinx 1.8.
|
||||
have_latex = have_command('latex')
|
||||
have_dvipng = have_command('dvipng')
|
||||
load_imgmath = have_latex and have_dvipng
|
||||
|
||||
# Respect SPHINX_IMGMATH (for html docs only)
|
||||
if 'SPHINX_IMGMATH' in os.environ:
|
||||
env_sphinx_imgmath = os.environ['SPHINX_IMGMATH']
|
||||
if 'yes' in env_sphinx_imgmath:
|
||||
load_imgmath = True
|
||||
elif 'no' in env_sphinx_imgmath:
|
||||
load_imgmath = False
|
||||
else:
|
||||
sys.stderr.write("Unknown env SPHINX_IMGMATH=%s ignored.\n" % env_sphinx_imgmath)
|
||||
|
||||
# Always load imgmath for Sphinx <1.8 or for epub docs
|
||||
load_imgmath = (load_imgmath or (major == 1 and minor < 8)
|
||||
or 'epub' in sys.argv)
|
||||
|
||||
if load_imgmath:
|
||||
extensions.append("sphinx.ext.imgmath")
|
||||
math_renderer = 'imgmath'
|
||||
else:
|
||||
math_renderer = 'mathjax'
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
@@ -333,7 +370,8 @@ html_static_path = ['sphinx-static']
|
||||
html_use_smartypants = False
|
||||
|
||||
# Custom sidebar templates, maps document names to template names.
|
||||
#html_sidebars = {}
|
||||
# Note that the RTD theme ignores this.
|
||||
html_sidebars = { '**': ['searchbox.html', 'localtoc.html', 'sourcelink.html']}
|
||||
|
||||
# Additional templates that should be rendered to pages, maps page names to
|
||||
# template names.
|
||||
|
||||
@@ -43,10 +43,11 @@ annotated objects like this, tools can be run on them to generate more useful
|
||||
information. In particular, on properly annotated objects, ``objtool`` can be
|
||||
run to check and fix the object if needed. Currently, ``objtool`` can report
|
||||
missing frame pointer setup/destruction in functions. It can also
|
||||
automatically generate annotations for :doc:`ORC unwinder <x86/orc-unwinder>`
|
||||
automatically generate annotations for the ORC unwinder
|
||||
(Documentation/x86/orc-unwinder.rst)
|
||||
for most code. Both of these are especially important to support reliable
|
||||
stack traces which are in turn necessary for :doc:`Kernel live patching
|
||||
<livepatch/livepatch>`.
|
||||
stack traces which are in turn necessary for kernel live patching
|
||||
(Documentation/livepatch/livepatch.rst).
|
||||
|
||||
Caveat and Discussion
|
||||
---------------------
|
||||
@@ -560,7 +560,7 @@ available:
|
||||
* cpuhp_state_remove_instance(state, node)
|
||||
* cpuhp_state_remove_instance_nocalls(state, node)
|
||||
|
||||
The arguments are the same as for the the cpuhp_state_add_instance*()
|
||||
The arguments are the same as for the cpuhp_state_add_instance*()
|
||||
variants above.
|
||||
|
||||
The functions differ in the way how the installed callbacks are treated:
|
||||
|
||||
@@ -23,6 +23,7 @@ it.
|
||||
printk-formats
|
||||
printk-index
|
||||
symbol-namespaces
|
||||
asm-annotations
|
||||
|
||||
Data structures and low-level utilities
|
||||
=======================================
|
||||
@@ -44,6 +45,8 @@ Library functionality that is used throughout the kernel.
|
||||
this_cpu_ops
|
||||
timekeeping
|
||||
errseq
|
||||
wrappers/atomic_t
|
||||
wrappers/atomic_bitops
|
||||
|
||||
Low level entry and exit
|
||||
========================
|
||||
@@ -67,6 +70,7 @@ Documentation/locking/index.rst for more related documentation.
|
||||
local_ops
|
||||
padata
|
||||
../RCU/index
|
||||
wrappers/memory-barriers.rst
|
||||
|
||||
Low-level hardware management
|
||||
=============================
|
||||
|
||||
@@ -71,7 +71,7 @@ variety of methods:
|
||||
Note that irq domain lookups must happen in contexts that are
|
||||
compatible with a RCU read-side critical section.
|
||||
|
||||
The irq_create_mapping() function must be called *atleast once*
|
||||
The irq_create_mapping() function must be called *at least once*
|
||||
before any call to irq_find_mapping(), lest the descriptor will not
|
||||
be allocated.
|
||||
|
||||
|
||||
18
Documentation/core-api/wrappers/atomic_bitops.rst
Normal file
18
Documentation/core-api/wrappers/atomic_bitops.rst
Normal file
@@ -0,0 +1,18 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
This is a simple wrapper to bring atomic_bitops.txt into the RST world
|
||||
until such a time as that file can be converted directly.
|
||||
|
||||
=============
|
||||
Atomic bitops
|
||||
=============
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\footnotesize
|
||||
|
||||
.. include:: ../../atomic_bitops.txt
|
||||
:literal:
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\normalsize
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user