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.0' of git://git.lwn.net/linux
Pull documentation updates from Jonathan Corbet:
"This was a moderately busy cycle for documentation, but nothing
all that earth-shaking:
- More Chinese translations, and an update to the Italian
translations.
The Japanese, Korean, and traditional Chinese translations
are more-or-less unmaintained at this point, instead.
- Some build-system performance improvements.
- The removal of the archaic submitting-drivers.rst document,
with the movement of what useful material that remained into
other docs.
- Improvements to sphinx-pre-install to, hopefully, give more
useful suggestions.
- A number of build-warning fixes
Plus the usual collection of typo fixes, updates, and more"
* tag 'docs-6.0' of git://git.lwn.net/linux: (92 commits)
docs: efi-stub: Fix paths for x86 / arm stubs
Docs/zh_CN: Update the translation of sched-stats to 5.19-rc8
Docs/zh_CN: Update the translation of pci to 5.19-rc8
Docs/zh_CN: Update the translation of pci-iov-howto to 5.19-rc8
Docs/zh_CN: Update the translation of usage to 5.19-rc8
Docs/zh_CN: Update the translation of testing-overview to 5.19-rc8
Docs/zh_CN: Update the translation of sparse to 5.19-rc8
Docs/zh_CN: Update the translation of kasan to 5.19-rc8
Docs/zh_CN: Update the translation of iio_configfs to 5.19-rc8
doc:it_IT: align Italian documentation
docs: Remove spurious tag from admin-guide/mm/overcommit-accounting.rst
Documentation: process: Update email client instructions for Thunderbird
docs: ABI: correct QEMU fw_cfg spec path
doc/zh_CN: remove submitting-driver reference from docs
docs: zh_TW: align to submitting-drivers removal
docs: zh_CN: align to submitting-drivers removal
docs: ko_KR: howto: remove reference to removed submitting-drivers
docs: ja_JP: howto: remove reference to removed submitting-drivers
docs: it_IT: align to submitting-drivers removal
docs: process: remove outdated submitting-drivers.rst
...
This commit is contained in:
@@ -12,8 +12,9 @@ Description:
|
||||
configuration data to the guest userspace.
|
||||
|
||||
The authoritative guest-side hardware interface documentation
|
||||
to the fw_cfg device can be found in "docs/specs/fw_cfg.txt"
|
||||
in the QEMU source tree.
|
||||
to the fw_cfg device can be found in "docs/specs/fw_cfg.rst"
|
||||
in the QEMU source tree, or online at:
|
||||
https://qemu-project.gitlab.io/qemu/specs/fw_cfg.html
|
||||
|
||||
**SysFS fw_cfg Interface**
|
||||
|
||||
|
||||
@@ -1,23 +1,22 @@
|
||||
config WARN_MISSING_DOCUMENTS
|
||||
|
||||
bool "Warn if there's a missing documentation file"
|
||||
depends on COMPILE_TEST
|
||||
help
|
||||
It is not uncommon that a document gets renamed.
|
||||
This option makes the Kernel to check for missing dependencies,
|
||||
warning when something is missing. Works only if the Kernel
|
||||
is built from a git tree.
|
||||
It is not uncommon that a document gets renamed.
|
||||
This option makes the Kernel to check for missing dependencies,
|
||||
warning when something is missing. Works only if the Kernel
|
||||
is built from a git tree.
|
||||
|
||||
If unsure, select 'N'.
|
||||
If unsure, select 'N'.
|
||||
|
||||
config WARN_ABI_ERRORS
|
||||
bool "Warn if there are errors at ABI files"
|
||||
depends on COMPILE_TEST
|
||||
help
|
||||
The files under Documentation/ABI should follow what's
|
||||
described at Documentation/ABI/README. Yet, as they're manually
|
||||
written, it would be possible that some of those files would
|
||||
have errors that would break them for being parsed by
|
||||
scripts/get_abi.pl. Add a check to verify them.
|
||||
The files under Documentation/ABI should follow what's
|
||||
described at Documentation/ABI/README. Yet, as they're manually
|
||||
written, it would be possible that some of those files would
|
||||
have errors that would break them for being parsed by
|
||||
scripts/get_abi.pl. Add a check to verify them.
|
||||
|
||||
If unsure, select 'N'.
|
||||
If unsure, select 'N'.
|
||||
|
||||
@@ -7,10 +7,9 @@ This list is the Linux Device List, the official registry of allocated
|
||||
device numbers and ``/dev`` directory nodes for the Linux operating
|
||||
system.
|
||||
|
||||
The LaTeX version of this document is no longer maintained, nor is
|
||||
the document that used to reside at lanana.org. This version in the
|
||||
mainline Linux kernel is the master document. Updates shall be sent
|
||||
as patches to the kernel maintainers (see the
|
||||
The version of this document at lanana.org is no longer maintained. This
|
||||
version in the mainline Linux kernel is the master document. Updates
|
||||
shall be sent as patches to the kernel maintainers (see the
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` document).
|
||||
Specifically explore the sections titled "CHAR and MISC DRIVERS", and
|
||||
"BLOCK LAYER" in the MAINTAINERS file to find the right maintainers
|
||||
|
||||
@@ -7,10 +7,10 @@ as a PE/COFF image, thereby convincing EFI firmware loaders to load
|
||||
it as an EFI executable. The code that modifies the bzImage header,
|
||||
along with the EFI-specific entry point that the firmware loader
|
||||
jumps to are collectively known as the "EFI boot stub", and live in
|
||||
arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
|
||||
arch/x86/boot/header.S and drivers/firmware/efi/libstub/x86-stub.c,
|
||||
respectively. For ARM the EFI stub is implemented in
|
||||
arch/arm/boot/compressed/efi-header.S and
|
||||
arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared
|
||||
drivers/firmware/efi/libstub/arm32-stub.c. EFI stub code that is shared
|
||||
between architectures is in drivers/firmware/efi/libstub.
|
||||
|
||||
For arm64, there is no compressed kernel support, so the Image itself
|
||||
|
||||
@@ -3109,7 +3109,7 @@
|
||||
mem_encrypt=on: Activate SME
|
||||
mem_encrypt=off: Do not activate SME
|
||||
|
||||
Refer to Documentation/virt/kvm/amd-memory-encryption.rst
|
||||
Refer to Documentation/virt/kvm/x86/amd-memory-encryption.rst
|
||||
for details on when memory encryption can be activated.
|
||||
|
||||
mem_sleep_default= [SUSPEND] Default system suspend mode:
|
||||
|
||||
@@ -38,8 +38,8 @@ acct
|
||||
|
||||
If BSD-style process accounting is enabled these values control
|
||||
its behaviour. If free space on filesystem where the log lives
|
||||
goes below ``lowwater``% accounting suspends. If free space gets
|
||||
above ``highwater``% accounting resumes. ``frequency`` determines
|
||||
goes below ``lowwater``\ % accounting suspends. If free space gets
|
||||
above ``highwater``\ % accounting resumes. ``frequency`` determines
|
||||
how often do we check the amount of free space (value is in
|
||||
seconds). Default:
|
||||
|
||||
|
||||
@@ -171,96 +171,73 @@ HWCAP_PACG
|
||||
Documentation/arm64/pointer-authentication.rst.
|
||||
|
||||
HWCAP2_DCPODP
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
|
||||
|
||||
HWCAP2_SVE2
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
|
||||
|
||||
HWCAP2_SVEAES
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
|
||||
|
||||
HWCAP2_SVEPMULL
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010.
|
||||
|
||||
HWCAP2_SVEBITPERM
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001.
|
||||
|
||||
HWCAP2_SVESHA3
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001.
|
||||
|
||||
HWCAP2_SVESM4
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001.
|
||||
|
||||
HWCAP2_FLAGM2
|
||||
|
||||
Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
|
||||
|
||||
HWCAP2_FRINT
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001.
|
||||
|
||||
HWCAP2_SVEI8MM
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.I8MM == 0b0001.
|
||||
|
||||
HWCAP2_SVEF32MM
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.F32MM == 0b0001.
|
||||
|
||||
HWCAP2_SVEF64MM
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.F64MM == 0b0001.
|
||||
|
||||
HWCAP2_SVEBF16
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001.
|
||||
|
||||
HWCAP2_I8MM
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001.
|
||||
|
||||
HWCAP2_BF16
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0001.
|
||||
|
||||
HWCAP2_DGH
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.DGH == 0b0001.
|
||||
|
||||
HWCAP2_RNG
|
||||
|
||||
Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
|
||||
|
||||
HWCAP2_BTI
|
||||
|
||||
Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001.
|
||||
|
||||
HWCAP2_MTE
|
||||
|
||||
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
|
||||
by Documentation/arm64/memory-tagging-extension.rst.
|
||||
|
||||
HWCAP2_ECV
|
||||
|
||||
Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
|
||||
|
||||
HWCAP2_AFP
|
||||
|
||||
Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
|
||||
|
||||
HWCAP2_RPRES
|
||||
|
||||
Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
|
||||
|
||||
HWCAP2_MTE3
|
||||
|
||||
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described
|
||||
by Documentation/arm64/memory-tagging-extension.rst.
|
||||
|
||||
|
||||
@@ -66,7 +66,7 @@ The wiki documentation always refers to the linux-next version of the script.
|
||||
|
||||
For Semantic Patch Language(SmPL) grammar documentation refer to:
|
||||
|
||||
http://coccinelle.lip6.fr/documentation.php
|
||||
https://coccinelle.gitlabpages.inria.fr/website/docs/main_grammar.html
|
||||
|
||||
Using Coccinelle on the Linux kernel
|
||||
------------------------------------
|
||||
|
||||
@@ -208,6 +208,14 @@ In general, the rules for selftests are
|
||||
Contributing new tests (details)
|
||||
================================
|
||||
|
||||
* In your Makefile, use facilities from lib.mk by including it instead of
|
||||
reinventing the wheel. Specify flags and binaries generation flags on
|
||||
need basis before including lib.mk. ::
|
||||
|
||||
CFLAGS = $(KHDR_INCLUDES)
|
||||
TEST_GEN_PROGS := close_range_test
|
||||
include ../lib.mk
|
||||
|
||||
* Use TEST_GEN_XXX if such binaries or files are generated during
|
||||
compiling.
|
||||
|
||||
@@ -230,13 +238,30 @@ Contributing new tests (details)
|
||||
* First use the headers inside the kernel source and/or git repo, and then the
|
||||
system headers. Headers for the kernel release as opposed to headers
|
||||
installed by the distro on the system should be the primary focus to be able
|
||||
to find regressions.
|
||||
to find regressions. Use KHDR_INCLUDES in Makefile to include headers from
|
||||
the kernel source.
|
||||
|
||||
* If a test needs specific kernel config options enabled, add a config file in
|
||||
the test directory to enable them.
|
||||
|
||||
e.g: tools/testing/selftests/android/config
|
||||
|
||||
* Create a .gitignore file inside test directory and add all generated objects
|
||||
in it.
|
||||
|
||||
* Add new test name in TARGETS in selftests/Makefile::
|
||||
|
||||
TARGETS += android
|
||||
|
||||
* All changes should pass::
|
||||
|
||||
kselftest-{all,install,clean,gen_tar}
|
||||
kselftest-{all,install,clean,gen_tar} O=abo_path
|
||||
kselftest-{all,install,clean,gen_tar} O=rel_path
|
||||
make -C tools/testing/selftests {all,install,clean,gen_tar}
|
||||
make -C tools/testing/selftests {all,install,clean,gen_tar} O=abs_path
|
||||
make -C tools/testing/selftests {all,install,clean,gen_tar} O=rel_path
|
||||
|
||||
Test Module
|
||||
===========
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
This module is part of the DA9061/DA9062/DA9063. For more details about entire
|
||||
DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
|
||||
For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt
|
||||
For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
|
||||
|
||||
This module provides the KEY_POWER event.
|
||||
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
.. title:: Kernel-doc comments
|
||||
|
||||
===========================
|
||||
Writing kernel-doc comments
|
||||
===========================
|
||||
|
||||
@@ -132,7 +132,8 @@ format-specific subdirectories under ``Documentation/output``.
|
||||
To generate documentation, Sphinx (``sphinx-build``) must obviously be
|
||||
installed. For prettier HTML output, the Read the Docs Sphinx theme
|
||||
(``sphinx_rtd_theme``) is used if available. For PDF output you'll also need
|
||||
``XeLaTeX`` and ``convert(1)`` from ImageMagick (https://www.imagemagick.org).
|
||||
``XeLaTeX`` and ``convert(1)`` from ImageMagick
|
||||
(https://www.imagemagick.org).\ [#ink]_
|
||||
All of these are widely available and packaged in distributions.
|
||||
|
||||
To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make
|
||||
@@ -150,8 +151,19 @@ If the theme is not available, it will fall-back to the classic one.
|
||||
|
||||
The Sphinx theme can be overridden by using the ``DOCS_THEME`` make variable.
|
||||
|
||||
There is another make variable ``SPHINXDIRS``, which is useful when test
|
||||
building a subset of documentation. For example, you can build documents
|
||||
under ``Documentation/doc-guide`` by running
|
||||
``make SPHINXDIRS=doc-guide htmldocs``.
|
||||
The documentation section of ``make help`` will show you the list of
|
||||
subdirectories you can specify.
|
||||
|
||||
To remove the generated documentation, run ``make cleandocs``.
|
||||
|
||||
.. [#ink] Having ``inkscape(1)`` from Inkscape (https://inkscape.org)
|
||||
as well would improve the quality of images embedded in PDF
|
||||
documents, especially for kernel releases 5.18 and later.
|
||||
|
||||
Writing Documentation
|
||||
=====================
|
||||
|
||||
|
||||
@@ -114,7 +114,7 @@ For a function using multiple GPIOs all of those can be obtained with one call::
|
||||
|
||||
This function returns a struct gpio_descs which contains an array of
|
||||
descriptors. It also contains a pointer to a gpiolib private structure which,
|
||||
if passed back to get/set array functions, may speed up I/O proocessing::
|
||||
if passed back to get/set array functions, may speed up I/O processing::
|
||||
|
||||
struct gpio_descs {
|
||||
struct gpio_array *info;
|
||||
|
||||
@@ -119,7 +119,7 @@ GPIO lines with debounce support
|
||||
Debouncing is a configuration set to a pin indicating that it is connected to
|
||||
a mechanical switch or button, or similar that may bounce. Bouncing means the
|
||||
line is pulled high/low quickly at very short intervals for mechanical
|
||||
reasons. This can result in the value being unstable or irqs fireing repeatedly
|
||||
reasons. This can result in the value being unstable or irqs firing repeatedly
|
||||
unless the line is debounced.
|
||||
|
||||
Debouncing in practice involves setting up a timer when something happens on
|
||||
@@ -219,7 +219,7 @@ use a trick: when a line is set as output, if the line is flagged as open
|
||||
drain, and the IN output value is low, it will be driven low as usual. But
|
||||
if the IN output value is set to high, it will instead *NOT* be driven high,
|
||||
instead it will be switched to input, as input mode is high impedance, thus
|
||||
achieveing an "open drain emulation" of sorts: electrically the behaviour will
|
||||
achieving an "open drain emulation" of sorts: electrically the behaviour will
|
||||
be identical, with the exception of possible hardware glitches when switching
|
||||
the mode of the line.
|
||||
|
||||
@@ -642,7 +642,7 @@ In this case the typical set-up will look like this:
|
||||
|
||||
As you can see pretty similar, but you do not supply a parent handler for
|
||||
the IRQ, instead a parent irqdomain, an fwnode for the hardware and
|
||||
a funcion .child_to_parent_hwirq() that has the purpose of looking up
|
||||
a function .child_to_parent_hwirq() that has the purpose of looking up
|
||||
the parent hardware irq from a child (i.e. this gpio chip) hardware irq.
|
||||
As always it is good to look at examples in the kernel tree for advice
|
||||
on how to find the required pieces.
|
||||
|
||||
@@ -44,7 +44,7 @@ These devices will appear on the system as ``/dev/gpiochip0`` thru
|
||||
found in the kernel tree ``tools/gpio`` subdirectory.
|
||||
|
||||
For structured and managed applications, we recommend that you make use of the
|
||||
libgpiod_ library. This provides helper abstractions, command line utlities
|
||||
libgpiod_ library. This provides helper abstractions, command line utilities
|
||||
and arbitration for multiple simultaneous consumers on the same GPIO chip.
|
||||
|
||||
.. _libgpiod: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
|
||||
|
||||
@@ -25,8 +25,7 @@ and userspace consumers. The kernel space consumers can directly talk to HTE
|
||||
subsystem while userspace consumers timestamp requests go through GPIOLIB CDEV
|
||||
framework to HTE subsystem.
|
||||
|
||||
.. kernel-doc:: drivers/gpio/gpiolib.c
|
||||
:functions: gpiod_enable_hw_timestamp_ns gpiod_disable_hw_timestamp_ns
|
||||
See gpiod_enable_hw_timestamp_ns() and gpiod_disable_hw_timestamp_ns().
|
||||
|
||||
For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be
|
||||
specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c``, which
|
||||
@@ -37,7 +36,7 @@ LIC (Legacy Interrupt Controller) IRQ GTE
|
||||
|
||||
This GTE instance timestamps LIC IRQ lines in real time. There are 352 IRQ
|
||||
lines which this instance can add timestamps to in real time. The hte
|
||||
devicetree binding described at ``Documentation/devicetree/bindings/hte/``
|
||||
devicetree binding described at ``Documentation/devicetree/bindings/timestamp``
|
||||
provides an example of how a consumer can request an IRQ line. Since it is a
|
||||
one-to-one mapping with IRQ GTE provider, consumers can simply specify the IRQ
|
||||
number that they are interested in. There is no userspace consumer support for
|
||||
|
||||
@@ -818,10 +818,11 @@ Compression implementation
|
||||
Instead, the main goal is to reduce data writes to flash disk as much as
|
||||
possible, resulting in extending disk life time as well as relaxing IO
|
||||
congestion. Alternatively, we've added ioctl(F2FS_IOC_RELEASE_COMPRESS_BLOCKS)
|
||||
interface to reclaim compressed space and show it to user after putting the
|
||||
immutable bit. Immutable bit, after release, it doesn't allow writing/mmaping
|
||||
on the file, until reserving compressed space via
|
||||
ioctl(F2FS_IOC_RESERVE_COMPRESS_BLOCKS) or truncating filesize to zero.
|
||||
interface to reclaim compressed space and show it to user after setting a
|
||||
special flag to the inode. Once the compressed space is released, the flag
|
||||
will block writing data to the file until either the compressed space is
|
||||
reserved via ioctl(F2FS_IOC_RESERVE_COMPRESS_BLOCKS) or the file size is
|
||||
truncated to zero.
|
||||
|
||||
Compress metadata layout::
|
||||
|
||||
@@ -830,12 +831,12 @@ Compress metadata layout::
|
||||
| cluster 1 | cluster 2 | ......... | cluster N |
|
||||
+-----------------------------------------------+
|
||||
. . . .
|
||||
. . . .
|
||||
. . . .
|
||||
. Compressed Cluster . . Normal Cluster .
|
||||
+----------+---------+---------+---------+ +---------+---------+---------+---------+
|
||||
|compr flag| block 1 | block 2 | block 3 | | block 1 | block 2 | block 3 | block 4 |
|
||||
+----------+---------+---------+---------+ +---------+---------+---------+---------+
|
||||
. .
|
||||
. .
|
||||
. .
|
||||
. .
|
||||
+-------------+-------------+----------+----------------------------+
|
||||
|
||||
@@ -607,7 +607,7 @@ can be removed.
|
||||
User xattr
|
||||
----------
|
||||
|
||||
The the "-o userxattr" mount option forces overlayfs to use the
|
||||
The "-o userxattr" mount option forces overlayfs to use the
|
||||
"user.overlay." xattr namespace instead of "trusted.overlay.". This is
|
||||
useful for unprivileged mounting of overlayfs.
|
||||
|
||||
|
||||
@@ -12,7 +12,6 @@ increase the chances of your change being accepted.
|
||||
* It should be unnecessary to mention, but please read and follow:
|
||||
|
||||
- Documentation/process/submit-checklist.rst
|
||||
- Documentation/process/submitting-drivers.rst
|
||||
- Documentation/process/submitting-patches.rst
|
||||
- Documentation/process/coding-style.rst
|
||||
|
||||
|
||||
@@ -755,8 +755,7 @@ make a neat patch, there's administrative work to be done:
|
||||
it implies a more-than-passing commitment to some part of the code.
|
||||
|
||||
- Finally, don't forget to read
|
||||
``Documentation/process/submitting-patches.rst`` and possibly
|
||||
``Documentation/process/submitting-drivers.rst``.
|
||||
``Documentation/process/submitting-patches.rst``
|
||||
|
||||
Kernel Cantrips
|
||||
===============
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user