mirror of https://gitee.com/openkylin/linux.git
A much quieter cycle for documentation (happily), with, one hopes, the bulk
of the churn behind us. Significant stuff in this pull includes: - A set of new Chinese translations - Italian translation updates - A mechanism from Mauro to automatically format Documentation/features for the built docs - Automatic cross references without explicit :ref: markup - A new reset-controller document - An extensive new document on reporting problems from Thorsten That last patch also adds the CC-BY-4.0 license to LICENSES/dual; there was some discussion on this, but we seem to have consensus and an ack from Greg for that addition. -----BEGIN PGP SIGNATURE----- iQFDBAABCAAtFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAl/XyewPHGNvcmJldEBs d24ubmV0AAoJEBdDWhNsDH5YUeYH/AiNNlVIF/80T45TAkm+1kpy2Fb+d/5wbtGK PB7OTXPyDmmqwZNldlF9IsRhp5W+wYC3PNlulYMG44hT7/Jqf2CMFw8SOZqGLmBV LhWwoS+TAWLB19IOOMrVXbhAlNsX01NwBDY/dwONjW1Jcu+tuAsBR47T9lKjw4kJ qGFGMQTvZG9Ig1x7E6X38mAd7W3SD1viNuUePS2YcoB15GAocWfVVHvu1r+RHUTS 27ET8tWzMMuiaCAD6toVY9L4T7iCI7YSPXQm8BOkf/f4LXDnpo8Fo11LE5ozTAh3 +avnNt8vnrRXc06MnzwsvNHm2TqN97B4shkeDiPAV3ySXI8Zu/w= =HScX -----END PGP SIGNATURE----- Merge tag 'docs-5.11' of git://git.lwn.net/linux Pull documentation updates from Jonathan Corbet: "A much quieter cycle for documentation (happily), with, one hopes, the bulk of the churn behind us. Significant stuff in this pull includes: - A set of new Chinese translations - Italian translation updates - A mechanism from Mauro to automatically format Documentation/features for the built docs - Automatic cross references without explicit :ref: markup - A new reset-controller document - An extensive new document on reporting problems from Thorsten That last patch also adds the CC-BY-4.0 license to LICENSES/dual; there was some discussion on this, but we seem to have consensus and an ack from Greg for that addition" * tag 'docs-5.11' of git://git.lwn.net/linux: (50 commits) docs: fix broken cross reference in translations/zh_CN docs: Note that sphinx 1.7 will be required soon docs: update requirements to install six module docs: reporting-issues: move 'outdated, need help' note to proper place docs: Update documentation to reflect what TAINT_CPU_OUT_OF_SPEC means docs: add a reset controller chapter to the driver API docs docs: make reporting-bugs.rst obsolete docs: Add a new text describing how to report bugs LICENSES: Add the CC-BY-4.0 license Documentation: fix multiple typos found in the admin-guide subdirectory Documentation: fix typos found in admin-guide subdirectory kernel-doc: Fix example in Nested structs/unions docs: clean up sysctl/kernel: titles, version docs: trace: fix event state structure name docs: nios2: add missing ReST file scripts: get_feat.pl: reduce table width for all features output scripts: get_feat.pl: change the group by order scripts: get_feat.pl: make complete table more coincise scripts: kernel-doc: fix parsing function-like typedefs Documentation: fix typos found in process, dev-tools, and doc-guide subdirectories ...
This commit is contained in:
commit
ff6135959a
|
@ -7,7 +7,7 @@ Description:
|
|||
ifname
|
||||
- network device interface name associated with
|
||||
this function instance
|
||||
qmult
|
||||
qmult
|
||||
- queue length multiplier for high and
|
||||
super speed
|
||||
host_addr
|
||||
|
|
|
@ -0,0 +1,20 @@
|
|||
What: /proc/*/attr/current
|
||||
Contact: linux-security-module@vger.kernel.org,
|
||||
selinux@vger.kernel.org,
|
||||
apparmor@lists.ubuntu.com
|
||||
Description: The current security information used by a Linux
|
||||
security module (LSM) that is active on the system.
|
||||
The details of permissions required to read from
|
||||
this interface and hence obtain the security state
|
||||
of the task identified is LSM dependent.
|
||||
A process cannot write to this interface unless it
|
||||
refers to itself.
|
||||
The other details of permissions required to write to
|
||||
this interface and hence change the security state of
|
||||
the task identified are LSM dependent.
|
||||
The format of the data used by this interface is LSM
|
||||
dependent.
|
||||
SELinux, Smack and AppArmor provide this interface.
|
||||
Users: SELinux user-space
|
||||
Smack user-space
|
||||
AppArmor user-space
|
|
@ -0,0 +1,20 @@
|
|||
What: /proc/*/attr/exec
|
||||
Contact: linux-security-module@vger.kernel.org,
|
||||
selinux@vger.kernel.org,
|
||||
apparmor@lists.ubuntu.com
|
||||
Description: The security information to be used on the process
|
||||
by a Linux security module (LSM) active on the system
|
||||
after a subsequent exec() call.
|
||||
The details of permissions required to read from
|
||||
this interface and hence obtain the security state
|
||||
of the task identified is LSM dependent.
|
||||
A process cannot write to this interface unless it
|
||||
refers to itself.
|
||||
The other details of permissions required to write to
|
||||
this interface and hence change the security state of
|
||||
the task identified are LSM dependent.
|
||||
The format of the data used by this interface is LSM
|
||||
dependent.
|
||||
SELinux and AppArmor provide this interface.
|
||||
Users: SELinux user-space
|
||||
AppArmor user-space
|
|
@ -0,0 +1,19 @@
|
|||
What: /proc/*/attr/prev
|
||||
Contact: linux-security-module@vger.kernel.org,
|
||||
selinux@vger.kernel.org,
|
||||
apparmor@lists.ubuntu.com
|
||||
Description: The security information used on the process by
|
||||
a Linux security module (LSM) active on the system
|
||||
prior to the most recent exec() call.
|
||||
The details of permissions required to read from
|
||||
this interface is LSM dependent.
|
||||
A process cannot write to this interface unless it
|
||||
refers to itself.
|
||||
The other details of permissions required to write to
|
||||
this interface are LSM dependent.
|
||||
The format of the data used by this interface is LSM
|
||||
dependent.
|
||||
SELinux and AppArmor provide this interface.
|
||||
Users: SELinux user-space
|
||||
AppArmor user-space
|
||||
|
|
@ -19,7 +19,7 @@ Description:
|
|||
identify removable sections of the memory before attempting
|
||||
potentially expensive hot-remove memory operation
|
||||
Users: hotplug memory remove tools
|
||||
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
|
||||
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/phys_device
|
||||
Date: September 2008
|
||||
|
|
|
@ -33,7 +33,7 @@ What: /sys/fs/ext4/<disk>/mb_order2_req
|
|||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
Tuning parameter which controls the minimum size for
|
||||
Tuning parameter which controls the minimum size for
|
||||
requests (as a power of 2) where the buddy cache is
|
||||
used
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ Description: Maximum time allowed for periodic transfers per microframe (μs)
|
|||
However there are cases, when 80% max isochronous bandwidth is
|
||||
too limiting. For example two video streams could require 110
|
||||
microseconds of isochronous bandwidth per microframe to work
|
||||
together.
|
||||
together.
|
||||
|
||||
Through this setting it is possible to raise the limit so that
|
||||
the host controller would allow allocating more than 100
|
||||
|
|
|
@ -12,6 +12,6 @@ Description:
|
|||
- "peripheral" - switching mode from host to peripheral.
|
||||
|
||||
Read the file, then it shows the following strings:
|
||||
|
||||
|
||||
- "host" - The mode is host now.
|
||||
- "peripheral" - The mode is peripheral now.
|
||||
|
|
|
@ -398,8 +398,8 @@ If something goes wrong
|
|||
|
||||
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 the :ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
|
||||
document for details.
|
||||
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
|
||||
|
|
|
@ -8,7 +8,7 @@ CPPC
|
|||
====
|
||||
|
||||
CPPC defined in the ACPI spec describes a mechanism for the OS to manage the
|
||||
performance of a logical processor on a contigious and abstract performance
|
||||
performance of a logical processor on a contiguous and abstract performance
|
||||
scale. CPPC exposes a set of registers to describe abstract performance scale,
|
||||
to request performance levels and to measure per-cpu delivered performance.
|
||||
|
||||
|
@ -45,7 +45,7 @@ for each cpu X::
|
|||
* lowest_freq : CPU frequency corresponding to lowest_perf (in MHz).
|
||||
* nominal_freq : CPU frequency corresponding to nominal_perf (in MHz).
|
||||
The above frequencies should only be used to report processor performance in
|
||||
freqency instead of abstract scale. These values should not be used for any
|
||||
frequency instead of abstract scale. These values should not be used for any
|
||||
functional decisions.
|
||||
|
||||
* feedback_ctrs : Includes both Reference and delivered performance counter.
|
||||
|
|
|
@ -70,5 +70,5 @@ Deleting binder Devices
|
|||
Binderfs binder devices can be deleted via `unlink() <unlink_>`_. This means
|
||||
that the `rm() <rm_>`_ tool can be used to delete them. Note that the
|
||||
``binder-control`` device cannot be deleted since this would make the binderfs
|
||||
instance unuseable. The ``binder-control`` device will be deleted when the
|
||||
instance unusable. The ``binder-control`` device will be deleted when the
|
||||
binderfs instance is unmounted and all references to it have been dropped.
|
||||
|
|
|
@ -220,7 +220,7 @@ example::
|
|||
Finally, you can load high-level drivers for each kind of device that
|
||||
you have connected. By default, each driver will autoprobe for a single
|
||||
device, but you can support up to four similar devices by giving their
|
||||
individual co-ordinates when you load the driver.
|
||||
individual coordinates when you load the driver.
|
||||
|
||||
For example, if you had two no-name CD-ROM drives both using the
|
||||
KingByte KBIC-951A adapter, one on port 0x378 and the other on 0x3bc
|
||||
|
|
|
@ -360,7 +360,7 @@ like below::
|
|||
/sys/block/zram0/writeback_limit.
|
||||
$ echo 1 > /sys/block/zram0/writeback_limit_enable
|
||||
|
||||
If admins want to allow further write again once the bugdet is exhausted,
|
||||
If admins want to allow further write again once the budget is exhausted,
|
||||
he could do it like below::
|
||||
|
||||
$ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \
|
||||
|
|
|
@ -15,7 +15,7 @@ give up. Report as much as you have found to the relevant maintainer. See
|
|||
MAINTAINERS for who that is for the subsystem you have worked on.
|
||||
|
||||
Before you submit a bug report read
|
||||
:ref:`Documentation/admin-guide/reporting-bugs.rst <reportingbugs>`.
|
||||
'Documentation/admin-guide/reporting-issues.rst'.
|
||||
|
||||
Devices not appearing
|
||||
=====================
|
||||
|
|
|
@ -263,7 +263,7 @@ Please notice that it will point to:
|
|||
|
||||
- The last developers that touched the source code (if this is done inside
|
||||
a git tree). On the above example, Tejun and Bhaktipriya (in this
|
||||
specific case, none really envolved on the development of this file);
|
||||
specific case, none really involved on the development of this file);
|
||||
- The driver maintainer (Hans Verkuil);
|
||||
- The subsystem maintainer (Mauro Carvalho Chehab);
|
||||
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);
|
||||
|
|
|
@ -9,7 +9,7 @@ Introduction
|
|||
PC operating systems. New and improved versions of CIFS are now
|
||||
called SMB2 and SMB3. Use of SMB3 (and later, including SMB3.1.1)
|
||||
is strongly preferred over using older dialects like CIFS due to
|
||||
security reaasons. All modern dialects, including the most recent,
|
||||
security reasons. All modern dialects, including the most recent,
|
||||
SMB3.1.1 are supported by the CIFS VFS module. The SMB3 protocol
|
||||
is implemented and supported by all major file servers
|
||||
such as all modern versions of Windows (including Windows 2016
|
||||
|
|
|
@ -115,7 +115,7 @@ later source tree in docs/manpages/mount.cifs.8
|
|||
Allowing User Unmounts
|
||||
======================
|
||||
|
||||
To permit users to ummount directories that they have user mounted (see above),
|
||||
To permit users to unmount directories that they have user mounted (see above),
|
||||
the utility umount.cifs may be used. It may be invoked directly, or if
|
||||
umount.cifs is placed in /sbin, umount can invoke the cifs umount helper
|
||||
(at least for most versions of the umount utility) for umount of cifs
|
||||
|
@ -197,7 +197,7 @@ that is ignored by local server applications and non-cifs clients and that will
|
|||
not be traversed by the Samba server). This is opaque to the Linux client
|
||||
application using the cifs vfs. Absolute symlinks will work to Samba 3.0.5 or
|
||||
later, but only for remote clients using the CIFS Unix extensions, and will
|
||||
be invisbile to Windows clients and typically will not affect local
|
||||
be invisible to Windows clients and typically will not affect local
|
||||
applications running on the same server as Samba.
|
||||
|
||||
Use instructions
|
||||
|
@ -267,7 +267,7 @@ would be forbidden for Windows/CIFS semantics) as long as the server is
|
|||
configured for Unix Extensions (and the client has not disabled
|
||||
/proc/fs/cifs/LinuxExtensionsEnabled). In addition the mount option
|
||||
``mapposix`` can be used on CIFS (vers=1.0) to force the mapping of
|
||||
illegal Windows/NTFS/SMB characters to a remap range (this mount parm
|
||||
illegal Windows/NTFS/SMB characters to a remap range (this mount parameter
|
||||
is the default for SMB3). This remap (``mapposix``) range is also
|
||||
compatible with Mac (and "Services for Mac" on some older Windows).
|
||||
|
||||
|
|
|
@ -46,7 +46,7 @@ Parameters::
|
|||
capi:authenc(hmac(sha256),xts(aes))-random
|
||||
capi:rfc7539(chacha20,poly1305)-random
|
||||
|
||||
The /proc/crypto contains a list of curently loaded crypto modes.
|
||||
The /proc/crypto contains a list of currently loaded crypto modes.
|
||||
|
||||
<key>
|
||||
Key used for encryption. It is encoded either as a hexadecimal number
|
||||
|
@ -92,7 +92,7 @@ Parameters::
|
|||
|
||||
<#opt_params>
|
||||
Number of optional parameters. If there are no optional parameters,
|
||||
the optional paramaters section can be skipped or #opt_params can be zero.
|
||||
the optional parameters section can be skipped or #opt_params can be zero.
|
||||
Otherwise #opt_params is the number of following arguments.
|
||||
|
||||
Example of optional parameters section:
|
||||
|
|
|
@ -117,7 +117,7 @@ journal_watermark:number
|
|||
|
||||
commit_time:number
|
||||
Commit time in milliseconds. When this time passes, the journal is
|
||||
written. The journal is also written immediatelly if the FLUSH
|
||||
written. The journal is also written immediately if the FLUSH
|
||||
request is received.
|
||||
|
||||
internal_hash:algorithm(:key) (the key is optional)
|
||||
|
@ -147,7 +147,7 @@ journal_crypt:algorithm(:key) (the key is optional)
|
|||
"salsa20" or "ctr(aes)").
|
||||
|
||||
The journal contains history of last writes to the block device,
|
||||
an attacker reading the journal could see the last sector nubmers
|
||||
an attacker reading the journal could see the last sector numbers
|
||||
that were written. From the sector numbers, the attacker can infer
|
||||
the size of files that were written. To protect against this
|
||||
situation, you can encrypt the journal.
|
||||
|
|
|
@ -418,6 +418,6 @@ Version History
|
|||
specific devices are requested via rebuild. Fix RAID leg
|
||||
rebuild errors.
|
||||
1.15.0 Fix size extensions not being synchronized in case of new MD bitmap
|
||||
pages allocated; also fix those not occuring after previous reductions
|
||||
pages allocated; also fix those not occurring after previous reductions
|
||||
1.15.1 Fix argument count and arguments for rebuild/write_mostly/journal_(dev|mode)
|
||||
on the status line.
|
||||
|
|
|
@ -24,7 +24,7 @@ The dm-zoned implementation is simple and minimizes system overhead (CPU
|
|||
and memory usage as well as storage capacity loss). For a 10TB
|
||||
host-managed disk with 256 MB zones, dm-zoned memory usage per disk
|
||||
instance is at most 4.5 MB and as little as 5 zones will be used
|
||||
internally for storing metadata and performaing reclaim operations.
|
||||
internally for storing metadata and performing reclaim operations.
|
||||
|
||||
dm-zoned target devices are formatted and checked using the dmzadm
|
||||
utility available at:
|
||||
|
@ -102,7 +102,7 @@ the buffer zone assigned. If the accessed chunk has no mapping, or the
|
|||
accessed blocks are invalid, the read buffer is zeroed and the read
|
||||
operation terminated.
|
||||
|
||||
After some time, the limited number of convnetional zones available may
|
||||
After some time, the limited number of conventional zones available may
|
||||
be exhausted (all used to map chunks or buffer sequential zones) and
|
||||
unaligned writes to unbuffered chunks become impossible. To avoid this
|
||||
situation, a reclaim process regularly scans used conventional zones and
|
||||
|
@ -158,7 +158,7 @@ Ex::
|
|||
dmzadm --format /dev/sdxx /dev/sdyy
|
||||
|
||||
|
||||
Fomatted device(s) can be started with the dmzadm utility, too.:
|
||||
Formatted device(s) can be started with the dmzadm utility, too.:
|
||||
|
||||
Ex::
|
||||
|
||||
|
|
|
@ -69,7 +69,7 @@ Construction Parameters
|
|||
|
||||
<#opt_params>
|
||||
Number of optional parameters. If there are no optional parameters,
|
||||
the optional paramaters section can be skipped or #opt_params can be zero.
|
||||
the optional parameters section can be skipped or #opt_params can be zero.
|
||||
Otherwise #opt_params is the number of following arguments.
|
||||
|
||||
Example of optional parameters section:
|
||||
|
|
|
@ -37,10 +37,10 @@ Constructor parameters:
|
|||
autocommit_blocks n (default: 64 for pmem, 65536 for ssd)
|
||||
when the application writes this amount of blocks without
|
||||
issuing the FLUSH request, the blocks are automatically
|
||||
commited
|
||||
committed
|
||||
autocommit_time ms (default: 1000)
|
||||
autocommit time in milliseconds. The data is automatically
|
||||
commited if this time passes and no FLUSH request is
|
||||
committed if this time passes and no FLUSH request is
|
||||
received
|
||||
fua (by default on)
|
||||
applicable only to persistent memory - use the FUA flag
|
||||
|
|
|
@ -0,0 +1,3 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. kernel-feat:: $srctree/Documentation/features
|
|
@ -60,7 +60,7 @@ Hyper-Thread attacks are possible.
|
|||
|
||||
The victim of a malicious actor does not need to make use of TSX. Only the
|
||||
attacker needs to begin a TSX transaction and raise an asynchronous abort
|
||||
which in turn potenitally leaks data stored in the buffers.
|
||||
which in turn potentially leaks data stored in the buffers.
|
||||
|
||||
More detailed technical information is available in the TAA specific x86
|
||||
architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`.
|
||||
|
|
|
@ -19,6 +19,7 @@ etc.
|
|||
sysctl/index
|
||||
|
||||
abi
|
||||
features
|
||||
|
||||
This section describes CPU vulnerabilities and their mitigations.
|
||||
|
||||
|
@ -33,7 +34,8 @@ problems and bugs in particular.
|
|||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
reporting-bugs
|
||||
reporting-issues
|
||||
Reporting bugs (obsolete) <reporting-bugs>
|
||||
security-bugs
|
||||
bug-hunting
|
||||
bug-bisect
|
||||
|
|
|
@ -172,6 +172,7 @@ parameter is applicable::
|
|||
X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
|
||||
X86_UV SGI UV support is enabled.
|
||||
XEN Xen support is enabled
|
||||
XTENSA xtensa architecture is enabled.
|
||||
|
||||
In addition, the following text indicates that the option::
|
||||
|
||||
|
|
|
@ -2709,7 +2709,7 @@
|
|||
option description.
|
||||
|
||||
memmap=nn[KMG]@ss[KMG]
|
||||
[KNL] Force usage of a specific region of memory.
|
||||
[KNL, X86, MIPS, XTENSA] Force usage of a specific region of memory.
|
||||
Region of memory to be used is from ss to ss+nn.
|
||||
If @ss[KMG] is omitted, it is equivalent to mem=nn[KMG],
|
||||
which limits max address to nn[KMG].
|
||||
|
|
|
@ -221,7 +221,7 @@ All md devices contain:
|
|||
|
||||
layout
|
||||
The ``layout`` for the array for the particular level. This is
|
||||
simply a number that is interpretted differently by different
|
||||
simply a number that is interpreted differently by different
|
||||
levels. It can be written while assembling an array.
|
||||
|
||||
array_size
|
||||
|
|
|
@ -77,7 +77,7 @@ the Subsystem ID in the second line, looks like this:
|
|||
only bt878-based cards can have a subsystem ID (which does not mean
|
||||
that every card really has one). bt848 cards can't have a Subsystem
|
||||
ID and therefore can't be autodetected. There is a list with the ID's
|
||||
at :doc:`bttv-cardlist` (in case you are intrested or want to mail
|
||||
at :doc:`bttv-cardlist` (in case you are interested or want to mail
|
||||
patches with updates).
|
||||
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ The DVB mailing list linux-dvb is hosted at vger. Please see
|
|||
http://vger.kernel.org/vger-lists.html#linux-media for details.
|
||||
|
||||
There are also some other old lists hosted at:
|
||||
https://linuxtv.org/lists.php. If you're insterested on that for historic
|
||||
https://linuxtv.org/lists.php. If you're interested on that for historic
|
||||
reasons, please check the archive at https://linuxtv.org/pipermail/linux-dvb/.
|
||||
|
||||
The media subsystem Wiki is hosted at https://linuxtv.org/wiki/.
|
||||
|
|
|
@ -68,7 +68,7 @@ cx24116 Conexant CX24116 based
|
|||
cx24117 Conexant CX24117 based
|
||||
cx24120 Conexant CX24120 based
|
||||
cx24123 Conexant CX24123 based
|
||||
ds3000 Montage Tehnology DS3000 based
|
||||
ds3000 Montage Technology DS3000 based
|
||||
mb86a16 Fujitsu MB86A16 based
|
||||
mt312 Zarlink VP310/MT312/ZL10313 based
|
||||
s5h1420 Samsung S5H1420 based
|
||||
|
@ -83,7 +83,7 @@ tda10086 Philips TDA10086 based
|
|||
tda8083 Philips TDA8083 based
|
||||
tda8261 Philips TDA8261 based
|
||||
tda826x Philips TDA826X silicon tuner
|
||||
ts2020 Montage Tehnology TS2020 based tuners
|
||||
ts2020 Montage Technology TS2020 based tuners
|
||||
tua6100 Infineon TUA6100 PLL
|
||||
cx24113 Conexant CX24113/CX24128 tuner for DVB-S/DSS
|
||||
itd1000 Integrant ITD1000 Zero IF tuner for DVB-S/DSS
|
||||
|
|
|
@ -305,7 +305,7 @@ pac7302 093a:2625 Genius iSlim 310
|
|||
pac7302 093a:2626 Labtec 2200
|
||||
pac7302 093a:2627 Genius FaceCam 300
|
||||
pac7302 093a:2628 Genius iLook 300
|
||||
pac7302 093a:2629 Genious iSlim 300
|
||||
pac7302 093a:2629 Genius iSlim 300
|
||||
pac7302 093a:262a Webcam 300k
|
||||
pac7302 093a:262c Philips SPC 230 NC
|
||||
jl2005bcd 0979:0227 Various brands, 19 known cameras supported
|
||||
|
|
|
@ -86,7 +86,7 @@ raw Bayer format that is specific to IPU3.
|
|||
Let us take the example of ov5670 sensor connected to CSI2 port 0, for a
|
||||
2592x1944 image capture.
|
||||
|
||||
Using the media contorller APIs, the ov5670 sensor is configured to send
|
||||
Using the media controller APIs, the ov5670 sensor is configured to send
|
||||
frames in packed raw Bayer format to IPU3 CSI2 receiver.
|
||||
|
||||
.. code-block:: none
|
||||
|
@ -313,8 +313,8 @@ configuration steps of 0.03125 (1/32).
|
|||
|
||||
**Geometric Distortion Correction**
|
||||
|
||||
Geometric Distortion Correction is used to performe correction of distortions
|
||||
and image filtering. It needs some extra filter and envelop padding pixels to
|
||||
Geometric Distortion Correction is used to perform correction of distortions
|
||||
and image filtering. It needs some extra filter and envelope padding pixels to
|
||||
work, so the input resolution of GDC should be larger than the output
|
||||
resolution.
|
||||
|
||||
|
|
|
@ -68,7 +68,7 @@ Using without lircd
|
|||
|
||||
Xorg recognizes several IR keycodes that have its numerical value lower
|
||||
than 247. With the advent of Wayland, the input driver got updated too,
|
||||
and should now accept all keycodes. Yet, you may want to just reasign
|
||||
and should now accept all keycodes. Yet, you may want to just reassign
|
||||
the keycodes to something that your favorite media application likes.
|
||||
|
||||
This can be done by setting
|
||||
|
|
|
@ -3,9 +3,9 @@ Memory Management
|
|||
=================
|
||||
|
||||
Linux memory management subsystem is responsible, as the name implies,
|
||||
for managing the memory in the system. This includes implemnetation of
|
||||
for managing the memory in the system. This includes implementation of
|
||||
virtual memory and demand paging, memory allocation both for kernel
|
||||
internal structures and user space programms, mapping of files into
|
||||
internal structures and user space programs, mapping of files into
|
||||
processes address space and many other cool things.
|
||||
|
||||
Linux memory management is a complex system with many configurable
|
||||
|
|
|
@ -74,7 +74,7 @@ memory node's access class 0 initiators as follows::
|
|||
/sys/devices/system/node/nodeY/access0/initiators/
|
||||
|
||||
These attributes apply only when accessed from nodes that have the
|
||||
are linked under the this access's inititiators.
|
||||
are linked under the this access's initiators.
|
||||
|
||||
The performance characteristics the kernel provides for the local initiators
|
||||
are exported are as follows::
|
||||
|
|
|
@ -114,7 +114,7 @@ Notes:
|
|||
you must provide some kind of page in your thread after reading from
|
||||
the uffd. You must provide either ``UFFDIO_COPY`` or ``UFFDIO_ZEROPAGE``.
|
||||
The normal behavior of the OS automatically providing a zero page on
|
||||
an annonymous mmaping is not in place.
|
||||
an anonymous mmaping is not in place.
|
||||
|
||||
- None of the page-delivering ioctls default to the range that you
|
||||
registered with. You must fill in all fields for the appropriate
|
||||
|
|
|
@ -106,7 +106,7 @@ This has a number of options available:
|
|||
certificate and a private key.
|
||||
|
||||
If the PEM file containing the private key is encrypted, or if the
|
||||
PKCS#11 token requries a PIN, this can be provided at build time by
|
||||
PKCS#11 token requires a PIN, this can be provided at build time by
|
||||
means of the ``KBUILD_SIGN_PIN`` variable.
|
||||
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
|
|||
|
||||
There are no performance counters inside the DRAM controller, so performance
|
||||
signals are brought out to the edge of the controller where a set of 4 x 32 bit
|
||||
counters is implemented. This is controlled by the CSV modes programed in counter
|
||||
counters is implemented. This is controlled by the CSV modes programmed in counter
|
||||
control register which causes a large number of PERF signals to be generated.
|
||||
|
||||
Selection of the value for each counter is done via the config registers. There
|
||||
|
|
|
@ -57,7 +57,7 @@ To get help on a command, another level of help is provided. For example for the
|
|||
|
||||
Summary of platform capability
|
||||
------------------------------
|
||||
To check the current platform and driver capaibilities, execute::
|
||||
To check the current platform and driver capabilities, execute::
|
||||
|
||||
#intel-speed-select --info
|
||||
|
||||
|
@ -658,7 +658,7 @@ If -a option is not used, then the following steps are required before enabling
|
|||
Intel(R) SST-BF:
|
||||
|
||||
- Discover Intel(R) SST-BF and note low and high priority base frequency
|
||||
- Note the high prioity CPU list
|
||||
- Note the high priority CPU list
|
||||
- Enable CLOS using core-power feature set
|
||||
- Configure CLOS parameters. Use CLOS.min to set to minimum performance
|
||||
- Subscribe desired CPUs to CLOS groups
|
||||
|
|
|
@ -56,7 +56,7 @@ Operation Modes
|
|||
|
||||
``intel_pstate`` can operate in two different modes, active or passive. In the
|
||||
active mode, it uses its own internal performance scaling governor algorithm or
|
||||
allows the hardware to do preformance scaling by itself, while in the passive
|
||||
allows the hardware to do performance scaling by itself, while in the passive
|
||||
mode it responds to requests made by a generic ``CPUFreq`` governor implementing
|
||||
a certain performance scaling algorithm. Which of them will be in effect
|
||||
depends on what kernel command line options are used and on the capabilities of
|
||||
|
@ -380,13 +380,13 @@ argument is passed to the kernel in the command line.
|
|||
|
||||
``no_turbo``
|
||||
If set (equal to 1), the driver is not allowed to set any turbo P-states
|
||||
(see `Turbo P-states Support`_). If unset (equalt to 0, which is the
|
||||
(see `Turbo P-states Support`_). If unset (equal to 0, which is the
|
||||
default), turbo P-states can be set by the driver.
|
||||
[Note that ``intel_pstate`` does not support the general ``boost``
|
||||
attribute (supported by some other scaling drivers) which is replaced
|
||||
by this one.]
|
||||
|
||||
This attrubute does not affect the maximum supported frequency value
|
||||
This attribute does not affect the maximum supported frequency value
|
||||
supplied to the ``CPUFreq`` core and exposed via the policy interface,
|
||||
but it affects the maximum possible value of per-policy P-state limits
|
||||
(see `Interpretation of Policy Attributes`_ below for details).
|
||||
|
|
|
@ -22,7 +22,7 @@ and type of the memory area are set using three variables:
|
|||
* ``mem_address`` for the start
|
||||
* ``mem_size`` for the size. The memory size will be rounded down to a
|
||||
power of two.
|
||||
* ``mem_type`` to specifiy if the memory type (default is pgprot_writecombine).
|
||||
* ``mem_type`` to specify if the memory type (default is pgprot_writecombine).
|
||||
|
||||
Typically the default value of ``mem_type=0`` should be used as that sets the pstore
|
||||
mapping to pgprot_writecombine. Setting ``mem_type=1`` attempts to use
|
||||
|
|
|
@ -1,5 +1,10 @@
|
|||
.. _reportingbugs:
|
||||
|
||||
.. note::
|
||||
|
||||
This document is obsolete, and will be replaced by
|
||||
'Documentation/admin-guide/reporting-issues.rst' in the near future.
|
||||
|
||||
Reporting bugs
|
||||
++++++++++++++
|
||||
|
||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -21,7 +21,7 @@ understand and fix the security vulnerability.
|
|||
|
||||
As it is with any bug, the more information provided the easier it
|
||||
will be to diagnose and fix. Please review the procedure outlined in
|
||||
:doc:`reporting-bugs` if you are unclear about what
|
||||
'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
|
||||
information is helpful. Any exploit code is very helpful and will not
|
||||
be released without consent from the reporter unless it has already been
|
||||
made public.
|
||||
|
|
|
@ -28,7 +28,7 @@ vsyscall32 (x86)
|
|||
|
||||
Determines whether the kernels maps a vDSO page into 32-bit processes;
|
||||
can be set to 1 to enable, or 0 to disable. Defaults to enabled if
|
||||
``CONFIG_COMPAT_VDSO`` is set, disabled otherwide.
|
||||
``CONFIG_COMPAT_VDSO`` is set, disabled otherwise.
|
||||
|
||||
This controls the same setting as the ``vdso32`` kernel boot
|
||||
parameter.
|
||||
|
|
|
@ -14,7 +14,7 @@ For general info and legal blurb, please look in :doc:`index`.
|
|||
------------------------------------------------------------------------------
|
||||
|
||||
This file contains documentation for the sysctl files in
|
||||
``/proc/sys/kernel/`` and is valid for Linux kernel version 2.2.
|
||||
``/proc/sys/kernel/``.
|
||||
|
||||
The files in this directory can be used to tune and monitor
|
||||
miscellaneous and general things in the operation of the Linux
|
||||
|
@ -879,7 +879,7 @@ The default value is 127.
|
|||
perf_event_mlock_kb
|
||||
===================
|
||||
|
||||
Control size of per-cpu ring buffer not counted agains mlock limit.
|
||||
Control size of per-cpu ring buffer not counted against mlock limit.
|
||||
|
||||
The default value is 512 + 1 page
|
||||
|
||||
|
@ -1095,8 +1095,8 @@ Enables/disables scheduler statistics. Enabling this feature
|
|||
incurs a small amount of overhead in the scheduler but is
|
||||
useful for debugging and performance tuning.
|
||||
|
||||
sched_util_clamp_min:
|
||||
=====================
|
||||
sched_util_clamp_min
|
||||
====================
|
||||
|
||||
Max allowed *minimum* utilization.
|
||||
|
||||
|
@ -1106,8 +1106,8 @@ It means that any requested uclamp.min value cannot be greater than
|
|||
sched_util_clamp_min, i.e., it is restricted to the range
|
||||
[0:sched_util_clamp_min].
|
||||
|
||||
sched_util_clamp_max:
|
||||
=====================
|
||||
sched_util_clamp_max
|
||||
====================
|
||||
|
||||
Max allowed *maximum* utilization.
|
||||
|
||||
|
@ -1117,8 +1117,8 @@ It means that any requested uclamp.max value cannot be greater than
|
|||
sched_util_clamp_max, i.e., it is restricted to the range
|
||||
[0:sched_util_clamp_max].
|
||||
|
||||
sched_util_clamp_min_rt_default:
|
||||
================================
|
||||
sched_util_clamp_min_rt_default
|
||||
===============================
|
||||
|
||||
By default Linux is tuned for performance. Which means that RT tasks always run
|
||||
at the highest frequency and most capable (highest capacity) CPU (in
|
||||
|
@ -1336,7 +1336,7 @@ ORed together. The letters are seen in "Tainted" line of Oops reports.
|
|||
====== ===== ==============================================================
|
||||
1 `(P)` proprietary module was loaded
|
||||
2 `(F)` module was force loaded
|
||||
4 `(S)` SMP kernel oops on an officially SMP incapable processor
|
||||
4 `(S)` kernel running on an out of specification system
|
||||
8 `(R)` module was force unloaded
|
||||
16 `(M)` processor reported a Machine Check Exception (MCE)
|
||||
32 `(B)` bad page referenced or some unexpected page flags
|
||||
|
|
|
@ -146,7 +146,7 @@ This should be used on systems where stalls for minor page faults are an
|
|||
acceptable trade for large contiguous free memory. Set to 0 to prevent
|
||||
compaction from moving pages that are unevictable. Default value is 1.
|
||||
On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due
|
||||
to compaction, which would block the task from becomming active until the fault
|
||||
to compaction, which would block the task from becoming active until the fault
|
||||
is resolved.
|
||||
|
||||
|
||||
|
|
|
@ -84,7 +84,7 @@ Bit Log Number Reason that got the kernel tainted
|
|||
=== === ====== ========================================================
|
||||
0 G/P 1 proprietary module was loaded
|
||||
1 _/F 2 module was force loaded
|
||||
2 _/S 4 SMP kernel oops on an officially SMP incapable processor
|
||||
2 _/S 4 kernel running on an out of specification system
|
||||
3 _/R 8 module was force unloaded
|
||||
4 _/M 16 processor reported a Machine Check Exception (MCE)
|
||||
5 _/B 32 bad page referenced or some unexpected page flags
|
||||
|
@ -116,10 +116,23 @@ More detailed explanation for tainting
|
|||
1) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
|
||||
modules were loaded normally.
|
||||
|
||||
2) ``S`` if the oops occurred on an SMP kernel running on hardware that
|
||||
hasn't been certified as safe to run multiprocessor.
|
||||
Currently this occurs only on various Athlons that are not
|
||||
SMP capable.
|
||||
2) ``S`` if the kernel is running on a processor or system that is out of
|
||||
specification: hardware has been put into an unsupported configuration,
|
||||
therefore proper execution cannot be guaranteed.
|
||||
Kernel will be tainted if, for example:
|
||||
|
||||
- on x86: PAE is forced through forcepae on intel CPUs (such as Pentium M)
|
||||
which do not report PAE but may have a functional implementation, an SMP
|
||||
kernel is running on non officially capable SMP Athlon CPUs, MSRs are
|
||||
being poked at from userspace.
|
||||
- on arm: kernel running on certain CPUs (such as Keystone 2) without
|
||||
having certain kernel features enabled.
|
||||
- on arm64: there are mismatched hardware features between CPUs, the
|
||||
bootloader has booted CPUs in different modes.
|
||||
- certain drivers are being used on non supported architectures (such as
|
||||
scsi/snic on something else than x86_64, scsi/ips on non
|
||||
x86/x86_64/itanium, have broken firmware settings for the
|
||||
irqchip/irq-gic on arm64 ...).
|
||||
|
||||
3) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
|
||||
modules were unloaded normally.
|
||||
|
|
|
@ -0,0 +1,3 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. kernel-feat:: $srctree/Documentation/features arm
|
|
@ -23,6 +23,8 @@ ARM Architecture
|
|||
vlocks
|
||||
porting
|
||||
|
||||
features
|
||||
|
||||
SoC-specific documents
|
||||
======================
|
||||
|
||||
|
|
|
@ -158,3 +158,13 @@ SunXi family
|
|||
* User Manual
|
||||
|
||||
https://linux-sunxi.org/images/4/46/Allwinner_H6_V200_User_Manual_V1.1.pdf
|
||||
|
||||
- Allwinner H616
|
||||
|
||||
* Datasheet
|
||||
|
||||
https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf
|
||||
|
||||
* User Manual
|
||||
|
||||
https://linux-sunxi.org/images/2/24/H616_User_Manual_V1.0_cleaned.pdf
|
||||
|
|
|
@ -1,3 +1,5 @@
|
|||
.. _elf_hwcaps_index:
|
||||
|
||||
================
|
||||
ARM64 ELF hwcaps
|
||||
================
|
||||
|
|
|
@ -0,0 +1,3 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. kernel-feat:: $srctree/Documentation/features arm64
|
|
@ -24,6 +24,8 @@ ARM64 Architecture
|
|||
tagged-address-abi
|
||||
tagged-pointers
|
||||
|
||||
features
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
Indices
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. _perf_index:
|
||||
|
||||
=====================
|
||||
Perf Event Attributes
|
||||
=====================
|
||||
|
|
|
@ -39,7 +39,7 @@ needs_sphinx = '1.3'
|
|||
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
|
||||
'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
|
||||
'maintainers_include', 'sphinx.ext.autosectionlabel',
|
||||
'kernel_abi']
|
||||
'kernel_abi', 'kernel_feat']
|
||||
|
||||
#
|
||||
# cdomain is badly broken in Sphinx 3+. Leaving it out generates *most*
|
||||
|
@ -112,6 +112,9 @@ if major >= 3:
|
|||
|
||||
else:
|
||||
extensions.append('cdomain')
|
||||
if major == 1 and minor < 7:
|
||||
sys.stderr.write('WARNING: Sphinx 1.7 or greater will be required as of '
|
||||
'the 5.12 release\n')
|
||||
|
||||
# Ensure that autosectionlabel will produce unique names
|
||||
autosectionlabel_prefix_document = True
|
||||
|
|
|
@ -531,7 +531,9 @@ For printing bitmap and its derivatives such as cpumask and nodemask,
|
|||
%*pb outputs the bitmap with field width as the number of bits and %*pbl
|
||||
output the bitmap as range list with field width as the number of bits.
|
||||
|
||||
Passed by reference.
|
||||
The field width is passed by value, the bitmap is passed by reference.
|
||||
Helper macros cpumask_pr_args() and nodemask_pr_args() are available to ease
|
||||
printing cpumask and nodemask.
|
||||
|
||||
Flags bitfields such as page flags, gfp_flags
|
||||
---------------------------------------------
|
||||
|
|
|
@ -224,14 +224,21 @@ you may want to use::
|
|||
|
||||
rm -f err.log
|
||||
export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
|
||||
make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c
|
||||
make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd
|
||||
|
||||
err.log will now have the profiling information, while stdout will
|
||||
provide some progress information as Coccinelle moves forward with
|
||||
work.
|
||||
|
||||
NOTE:
|
||||
|
||||
DEBUG_FILE support is only supported when using coccinelle >= 1.0.2.
|
||||
|
||||
Currently, DEBUG_FILE support is only available to check folders, and
|
||||
not single files. This is because checking a single file requires spatch
|
||||
to be called twice leading to DEBUG_FILE being set both times to the same value,
|
||||
giving rise to an error.
|
||||
|
||||
.cocciconfig support
|
||||
--------------------
|
||||
|
||||
|
|
|
@ -330,7 +330,7 @@ using something like insmod or modprobe. The module is called ``test_kasan``.
|
|||
~~~~~~~~~~~~~
|
||||
|
||||
With ``CONFIG_KUNIT`` built-in, ``CONFIG_KASAN_KUNIT_TEST`` can be built-in
|
||||
on any architecure that supports KASAN. These and any other KUnit
|
||||
on any architecture that supports KASAN. These and any other KUnit
|
||||
tests enabled will run and print the results at boot as a late-init
|
||||
call.
|
||||
|
||||
|
@ -351,5 +351,5 @@ converted to KUnit. These tests can be run only as a module with
|
|||
``CONFIG_KASAN`` built-in. The type of error expected and the
|
||||
function being run is printed before the expression expected to give
|
||||
an error. Then the error is printed, if found, and that test
|
||||
should be interpretted to pass only if the error was the one expected
|
||||
should be interpreted to pass only if the error was the one expected
|
||||
by the test.
|
||||
|
|
|
@ -243,7 +243,7 @@ handles as they don't belong to a particular subsystem. The bytes 4-7 are
|
|||
currently reserved and must be zero. In the future the number of bytes
|
||||
used for the subsystem or handle ids might be increased.
|
||||
|
||||
When a particular userspace proccess collects coverage via a common
|
||||
When a particular userspace process collects coverage via a common
|
||||
handle, kcov will collect coverage for each code section that is annotated
|
||||
to use the common handle obtained as kcov_handle from the current
|
||||
task_struct. However non common handles allow to collect coverage
|
||||
|
|
|
@ -63,10 +63,9 @@ will want to turn on ``CONFIG_DEBUG_INFO`` which is called
|
|||
It is advised, but not required, that you turn on the
|
||||
``CONFIG_FRAME_POINTER`` kernel option which is called :menuselection:`Compile
|
||||
the kernel with frame pointers` in the config menu. This option inserts code
|
||||
to into the compiled executable which saves the frame information in
|
||||
registers or on the stack at different points which allows a debugger
|
||||
such as gdb to more accurately construct stack back traces while
|
||||
debugging the kernel.
|
||||
into the compiled executable which saves the frame information in registers
|
||||
or on the stack at different points which allows a debugger such as gdb to
|
||||
more accurately construct stack back traces while debugging the kernel.
|
||||
|
||||
If the architecture that you are using supports the kernel option
|
||||
``CONFIG_STRICT_KERNEL_RWX``, you should consider turning it off. This
|
||||
|
|
|
@ -25,7 +25,8 @@ I. For patch submitters
|
|||
|
||||
make dt_binding_check
|
||||
|
||||
See ../writing-schema.rst for more details about schema and tools setup.
|
||||
See Documentation/devicetree/writing-schema.rst for more details about
|
||||
schema and tools setup.
|
||||
|
||||
3) DT binding files should be dual licensed. The preferred license tag is
|
||||
(GPL-2.0-only OR BSD-2-Clause).
|
||||
|
|
|
@ -247,12 +247,12 @@ It is possible to document nested structs and unions, like::
|
|||
struct {
|
||||
int memb1;
|
||||
int memb2;
|
||||
}
|
||||
};
|
||||
struct {
|
||||
void *memb3;
|
||||
int memb4;
|
||||
}
|
||||
}
|
||||
};
|
||||
};
|
||||
union {
|
||||
struct {
|
||||
int memb1;
|
||||
|
|
|
@ -375,7 +375,7 @@ image format use SVG (:ref:`svg_image_example`)::
|
|||
|
||||
SVG image example
|
||||
|
||||
The kernel figure (and image) directive support **DOT** formated files, see
|
||||
The kernel figure (and image) directive support **DOT** formatted files, see
|
||||
|
||||
* DOT: http://graphviz.org/pdf/dotguide.pdf
|
||||
* Graphviz: http://www.graphviz.org/content/dot-language
|
||||
|
|
|
@ -29,6 +29,7 @@ available subsections can be seen below.
|
|||
infiniband
|
||||
frame-buffer
|
||||
regulator
|
||||
reset
|
||||
iio/index
|
||||
input
|
||||
usb/index
|
||||
|
|
|
@ -52,7 +52,7 @@ Linux.
|
|||
16384+0 records out
|
||||
8388608 bytes (8.4 MB) copied, 10.0269 s, 837 kB/s
|
||||
|
||||
6) Verify the backup:
|
||||
6) Verify the backup::
|
||||
|
||||
# sha1sum /dev/mtd0ro bios.bak
|
||||
fdbb011920572ca6c991377c4b418a0502668b73 /dev/mtd0ro
|
||||
|
@ -66,7 +66,7 @@ Linux.
|
|||
# flash_erase /dev/mtd0 0 0
|
||||
Erasing 4 Kibyte @ 7ff000 -- 100 % complete
|
||||
|
||||
8) Once completed without errors you can write the new BIOS image:
|
||||
8) Once completed without errors you can write the new BIOS image::
|
||||
|
||||
# dd if=MNW2MAX1.X64.0092.R01.1605221712.bin of=/dev/mtd0
|
||||
|
||||
|
|
|
@ -34,7 +34,8 @@ Before this framework, the layer is like::
|
|||
------------------------
|
||||
SPI NOR chip
|
||||
|
||||
After this framework, the layer is like:
|
||||
After this framework, the layer is like::
|
||||
|
||||
MTD
|
||||
------------------------
|
||||
SPI NOR framework
|
||||
|
@ -45,7 +46,8 @@ Before this framework, the layer is like::
|
|||
------------------------
|
||||
SPI NOR chip
|
||||
|
||||
With the SPI NOR controller driver (Freescale QuadSPI), it looks like:
|
||||
With the SPI NOR controller driver (Freescale QuadSPI), it looks like::
|
||||
|
||||
MTD
|
||||
------------------------
|
||||
SPI NOR framework
|
||||
|
|
|
@ -0,0 +1,221 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0-only
|
||||
|
||||
====================
|
||||
Reset controller API
|
||||
====================
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Reset controllers are central units that control the reset signals to multiple
|
||||
peripherals.
|
||||
The reset controller API is split into two parts:
|
||||
the `consumer driver interface <#consumer-driver-interface>`__ (`API reference
|
||||
<#reset-consumer-api>`__), which allows peripheral drivers to request control
|
||||
over their reset input signals, and the `reset controller driver interface
|
||||
<#reset-controller-driver-interface>`__ (`API reference
|
||||
<#reset-controller-driver-api>`__), which is used by drivers for reset
|
||||
controller devices to register their reset controls to provide them to the
|
||||
consumers.
|
||||
|
||||
While some reset controller hardware units also implement system restart
|
||||
functionality, restart handlers are out of scope for the reset controller API.
|
||||
|
||||
Glossary
|
||||
--------
|
||||
|
||||
The reset controller API uses these terms with a specific meaning:
|
||||
|
||||
Reset line
|
||||
|
||||
Physical reset line carrying a reset signal from a reset controller
|
||||
hardware unit to a peripheral module.
|
||||
|
||||
Reset control
|
||||
|
||||
Control method that determines the state of one or multiple reset lines.
|
||||
Most commonly this is a single bit in reset controller register space that
|
||||
either allows direct control over the physical state of the reset line, or
|
||||
is self-clearing and can be used to trigger a predetermined pulse on the
|
||||
reset line.
|
||||
In more complicated reset controls, a single trigger action can launch a
|
||||
carefully timed sequence of pulses on multiple reset lines.
|
||||
|
||||
Reset controller
|
||||
|
||||
A hardware module that provides a number of reset controls to control a
|
||||
number of reset lines.
|
||||
|
||||
Reset consumer
|
||||
|
||||
Peripheral module or external IC that is put into reset by the signal on a
|
||||
reset line.
|
||||
|
||||
Consumer driver interface
|
||||
=========================
|
||||
|
||||
This interface provides an API that is similar to the kernel clock framework.
|
||||
Consumer drivers use get and put operations to acquire and release reset
|
||||
controls.
|
||||
Functions are provided to assert and deassert the controlled reset lines,
|
||||
trigger reset pulses, or to query reset line status.
|
||||
|
||||
When requesting reset controls, consumers can use symbolic names for their
|
||||
reset inputs, which are mapped to an actual reset control on an existing reset
|
||||
controller device by the core.
|
||||
|
||||
A stub version of this API is provided when the reset controller framework is
|
||||
not in use in order to minimize the need to use ifdefs.
|
||||
|
||||
Shared and exclusive resets
|
||||
---------------------------
|
||||
|
||||
The reset controller API provides either reference counted deassertion and
|
||||
assertion or direct, exclusive control.
|
||||
The distinction between shared and exclusive reset controls is made at the time
|
||||
the reset control is requested, either via devm_reset_control_get_shared() or
|
||||
via devm_reset_control_get_exclusive().
|
||||
This choice determines the behavior of the API calls made with the reset
|
||||
control.
|
||||
|
||||
Shared resets behave similarly to clocks in the kernel clock framework.
|
||||
They provide reference counted deassertion, where only the first deassert,
|
||||
which increments the deassertion reference count to one, and the last assert
|
||||
which decrements the deassertion reference count back to zero, have a physical
|
||||
effect on the reset line.
|
||||
|
||||
Exclusive resets on the other hand guarantee direct control.
|
||||
That is, an assert causes the reset line to be asserted immediately, and a
|
||||
deassert causes the reset line to be deasserted immediately.
|
||||
|
||||
Assertion and deassertion
|
||||
-------------------------
|
||||
|
||||
Consumer drivers use the reset_control_assert() and reset_control_deassert()
|
||||
functions to assert and deassert reset lines.
|
||||
For shared reset controls, calls to the two functions must be balanced.
|
||||
|
||||
Note that since multiple consumers may be using a shared reset control, there
|
||||
is no guarantee that calling reset_control_assert() on a shared reset control
|
||||
will actually cause the reset line to be asserted.
|
||||
Consumer drivers using shared reset controls should assume that the reset line
|
||||
may be kept deasserted at all times.
|
||||
The API only guarantees that the reset line can not be asserted as long as any
|
||||
consumer has requested it to be deasserted.
|
||||
|
||||
Triggering
|
||||
----------
|
||||
|
||||
Consumer drivers use reset_control_reset() to trigger a reset pulse on a
|
||||
self-deasserting reset control.
|
||||
In general, these resets can not be shared between multiple consumers, since
|
||||
requesting a pulse from any consumer driver will reset all connected
|
||||
peripherals.
|
||||
|
||||
The reset controller API allows requesting self-deasserting reset controls as
|
||||
shared, but for those only the first trigger request causes an actual pulse to
|
||||
be issued on the reset line.
|
||||
All further calls to this function have no effect until all consumers have
|
||||
called reset_control_rearm().
|
||||
For shared reset controls, calls to the two functions must be balanced.
|
||||
This allows devices that only require an initial reset at any point before the
|
||||
driver is probed or resumed to share a pulsed reset line.
|
||||
|
||||
Querying
|
||||
--------
|
||||
|
||||
Only some reset controllers support querying the current status of a reset
|
||||
line, via reset_control_status().
|
||||
If supported, this function returns a positive non-zero value if the given
|
||||
reset line is asserted.
|
||||
The reset_control_status() function does not accept a
|
||||
`reset control array <#reset-control-arrays>`__ handle as its input parameter.
|
||||
|
||||
Optional resets
|
||||
---------------
|
||||
|
||||
Often peripherals require a reset line on some platforms but not on others.
|
||||
For this, reset controls can be requested as optional using
|
||||
devm_reset_control_get_optional_exclusive() or
|
||||
devm_reset_control_get_optional_shared().
|
||||
These functions return a NULL pointer instead of an error when the requested
|
||||
reset control is not specified in the device tree.
|
||||
Passing a NULL pointer to the reset_control functions causes them to return
|
||||
quietly without an error.
|
||||
|
||||
Reset control arrays
|
||||
--------------------
|
||||
|
||||
Some drivers need to assert a bunch of reset lines in no particular order.
|
||||
devm_reset_control_array_get() returns an opaque reset control handle that can
|
||||
be used to assert, deassert, or trigger all specified reset controls at once.
|
||||
The reset control API does not guarantee the order in which the individual
|
||||
controls therein are handled.
|
||||
|
||||
Reset controller driver interface
|
||||
=================================
|
||||
|
||||
Drivers for reset controller modules provide the functionality necessary to
|
||||
assert or deassert reset signals, to trigger a reset pulse on a reset line, or
|
||||
to query its current state.
|
||||
All functions are optional.
|
||||
|
||||
Initialization
|
||||
--------------
|
||||
|
||||
Drivers fill a struct :c:type:`reset_controller_dev` and register it with
|
||||
reset_controller_register() in their probe function.
|
||||
The actual functionality is implemented in callback functions via a struct
|
||||
:c:type:`reset_control_ops`.
|
||||
|
||||
API reference
|
||||
=============
|
||||
|
||||
The reset controller API is documented here in two parts:
|
||||
the `reset consumer API <#reset-consumer-api>`__ and the `reset controller
|
||||
driver API <#reset-controller-driver-api>`__.
|
||||
|
||||
Reset consumer API
|
||||
------------------
|
||||
|
||||
Reset consumers can control a reset line using an opaque reset control handle,
|
||||
which can be obtained from devm_reset_control_get_exclusive() or
|
||||
devm_reset_control_get_shared().
|
||||
Given the reset control, consumers can call reset_control_assert() and
|
||||
reset_control_deassert(), trigger a reset pulse using reset_control_reset(), or
|
||||
query the reset line status using reset_control_status().
|
||||
|
||||
.. kernel-doc:: include/linux/reset.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/reset/core.c
|
||||
:functions: reset_control_reset
|
||||
reset_control_assert
|
||||
reset_control_deassert
|
||||
reset_control_status
|
||||
reset_control_acquire
|
||||
reset_control_release
|
||||
reset_control_rearm
|
||||
reset_control_put
|
||||
of_reset_control_get_count
|
||||
of_reset_control_array_get
|
||||
devm_reset_control_array_get
|
||||
reset_control_get_count
|
||||
|
||||
Reset controller driver API
|
||||
---------------------------
|
||||
|
||||
Reset controller drivers are supposed to implement the necessary functions in
|
||||
a static constant structure :c:type:`reset_control_ops`, allocate and fill out
|
||||
a struct :c:type:`reset_controller_dev`, and register it using
|
||||
devm_reset_controller_register().
|
||||
|
||||
.. kernel-doc:: include/linux/reset-controller.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/reset/core.c
|
||||
:functions: of_reset_simple_xlate
|
||||
reset_controller_register
|
||||
reset_controller_unregister
|
||||
devm_reset_controller_register
|
||||
reset_controller_add_lookup
|
|
@ -1,3 +1,4 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
#
|
||||
# Small script that visualizes the kernel feature support status
|
||||
# of an architecture.
|
||||
|
@ -7,18 +8,4 @@
|
|||
|
||||
ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/')}
|
||||
|
||||
cd $(dirname $0)
|
||||
echo "#"
|
||||
echo "# Kernel feature support matrix of the '$ARCH' architecture:"
|
||||
echo "#"
|
||||
|
||||
for F in */*/arch-support.txt; do
|
||||
SUBSYS=$(echo $F | cut -d/ -f1)
|
||||
N=$(grep -h "^# Feature name:" $F | cut -c25-)
|
||||
C=$(grep -h "^# Kconfig:" $F | cut -c25-)
|
||||
D=$(grep -h "^# description:" $F | cut -c25-)
|
||||
S=$(grep -hv "^#" $F | grep -w $ARCH | cut -d\| -f3)
|
||||
|
||||
printf "%10s/%-22s:%s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$C" "$D"
|
||||
done
|
||||
|
||||
$(dirname $0)/../../scripts/get_feat.pl list --arch $ARCH
|
||||
|
|
|
@ -22,7 +22,7 @@
|
|||
| nios2: | TODO |
|
||||
| openrisc: | ok |
|
||||
| parisc: | TODO |
|
||||
| powerpc: | TODO |
|
||||
| powerpc: | ok |
|
||||
| riscv: | TODO |
|
||||
| s390: | TODO |
|
||||
| sh: | TODO |
|
||||
|
|
|
@ -22,7 +22,7 @@
|
|||
| nios2: | TODO |
|
||||
| openrisc: | ok |
|
||||
| parisc: | TODO |
|
||||
| powerpc: | TODO |
|
||||
| powerpc: | ok |
|
||||
| riscv: | TODO |
|
||||
| s390: | TODO |
|
||||
| sh: | TODO |
|
||||
|
|
|
@ -11,7 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| csky: | ok |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
@ -25,7 +25,7 @@
|
|||
| powerpc: | ok |
|
||||
| riscv: | ok |
|
||||
| s390: | ok |
|
||||
| sh: | TODO |
|
||||
| sh: | ok |
|
||||
| sparc: | TODO |
|
||||
| um: | ok |
|
||||
| x86: | ok |
|
||||
|
|
|
@ -11,7 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| csky: | ok |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
@ -11,7 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| csky: | ok |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | ok |
|
||||
|
|
|
@ -113,7 +113,7 @@ Documentation for filesystem implementations.
|
|||
sysv-fs
|
||||
tmpfs
|
||||
ubifs
|
||||
ubifs-authentication.rst
|
||||
ubifs-authentication
|
||||
udf
|
||||
virtiofs
|
||||
vfat
|
||||
|
|
|
@ -774,7 +774,7 @@ process the parameters it is given.
|
|||
should just be set to lie inside the low-to-high range.
|
||||
|
||||
If all is good, true is returned. If the table is invalid, errors are
|
||||
logged to dmesg and false is returned.
|
||||
logged to the kernel log buffer and false is returned.
|
||||
|
||||
* ::
|
||||
|
||||
|
@ -782,7 +782,7 @@ process the parameters it is given.
|
|||
|
||||
This performs some validation checks on a parameter description. It
|
||||
returns true if the description is good and false if it is not. It will
|
||||
log errors to dmesg if validation fails.
|
||||
log errors to the kernel log buffer if validation fails.
|
||||
|
||||
* ::
|
||||
|
||||
|
|
|
@ -546,6 +546,7 @@ encoded manner. The codes are the following:
|
|||
nh no huge page advise flag
|
||||
mg mergable advise flag
|
||||
bt arm64 BTI guarded page
|
||||
mt arm64 MTE allocation tags are enabled
|
||||
== =======================================
|
||||
|
||||
Note that there is no guarantee that every flag and associated mnemonic will
|
||||
|
|
|
@ -0,0 +1,3 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. kernel-feat:: $srctree/Documentation/features ia64
|
|
@ -15,3 +15,5 @@ IA-64 Architecture
|
|||
irq-redir
|
||||
mca
|
||||
serial
|
||||
|
||||
features
|
||||
|
|
|
@ -160,7 +160,7 @@ implementation.
|
|||
ia64/index
|
||||
m68k/index
|
||||
mips/index
|
||||
nios2/nios2
|
||||
nios2/index
|
||||
openrisc/index
|
||||
parisc/index
|
||||
powerpc/index
|
||||
|
|
|
@ -0,0 +1,3 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. kernel-feat:: $srctree/Documentation/features m68k
|
|
@ -10,6 +10,8 @@ m68k Architecture
|
|||
kernel-options
|
||||
buddha-driver
|
||||
|
||||
features
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
Indices
|
||||
|
|
|
@ -0,0 +1,3 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. kernel-feat:: $srctree/Documentation/features mips
|
|
@ -11,6 +11,8 @@ MIPS-specific Documentation
|
|||
booting
|
||||
ingenic-tcu
|
||||
|
||||
features
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
Indices
|
||||
|
|
|
@ -374,8 +374,8 @@ steps you should take:
|
|||
email address will be in the driver source or in the MAINTAINERS file.
|
||||
|
||||
- The contents of your report will vary a lot depending upon the
|
||||
problem. If it's a kernel crash then you should refer to the
|
||||
admin-guide/reporting-bugs.rst file.
|
||||
problem. If it's a kernel crash then you should refer to
|
||||
'Documentation/admin-guide/reporting-issues.rst'.
|
||||
|
||||
But for most problems it is useful to provide the following:
|
||||
|
||||
|
|
|
@ -0,0 +1,3 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. kernel-feat:: $srctree/Documentation/features nios2
|
|
@ -0,0 +1,12 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==============================
|
||||
Nios II Specific Documentation
|
||||
==============================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered:
|
||||
|
||||
nios2
|
||||
features
|
|
@ -0,0 +1,3 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. kernel-feat:: $srctree/Documentation/features openrisc
|
|
@ -10,6 +10,8 @@ OpenRISC Architecture
|
|||
openrisc_port
|
||||
todo
|
||||
|
||||
features
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
Indices
|
||||
|
|
|
@ -0,0 +1,3 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. kernel-feat:: $srctree/Documentation/features parisc
|
|
@ -10,6 +10,8 @@ PA-RISC Architecture
|
|||
debugging
|
||||
registers
|
||||
|
||||
features
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
Indices
|
||||
|
|
|
@ -0,0 +1,3 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. kernel-feat:: $srctree/Documentation/features powerpc
|
|
@ -34,6 +34,8 @@ powerpc
|
|||
vas-api
|
||||
vcpudispatch_stats
|
||||
|
||||
features
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
Indices
|
||||
|
|
|
@ -97,7 +97,7 @@ it can be very useful.
|
|||
|
||||
There are integrations for many popular text editors. For some of them,
|
||||
like vim, emacs, BBEdit and Visual Studio you can find support built-in.
|
||||
For instructions, read the appropiate section at:
|
||||
For instructions, read the appropriate section at:
|
||||
|
||||
https://clang.llvm.org/docs/ClangFormat.html
|
||||
|
||||
|
|
|
@ -152,7 +152,7 @@ The disclosing party should provide a list of contacts for all other
|
|||
entities who have already been, or should be, informed about the issue.
|
||||
This serves several purposes:
|
||||
|
||||
- The list of disclosed entities allows communication accross the
|
||||
- The list of disclosed entities allows communication across the
|
||||
industry, e.g. other OS vendors, HW vendors, etc.
|
||||
|
||||
- The disclosed entities can be contacted to name experts who should
|
||||
|
|
|
@ -348,11 +348,10 @@ tool. For details on how to use the kernel bugzilla, please see:
|
|||
|
||||
https://bugzilla.kernel.org/page.cgi?id=faq.html
|
||||
|
||||
The file :ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
|
||||
in the main kernel source directory has a good
|
||||
template for how to report a possible kernel bug, and details what kind
|
||||
of information is needed by the kernel developers to help track down the
|
||||
problem.
|
||||
The file 'Documentation/admin-guide/reporting-issues.rst' in the main kernel
|
||||
source directory has a good template for how to report a possible kernel bug,
|
||||
and details what kind of information is needed by the kernel developers to help
|
||||
track down the problem.
|
||||
|
||||
|
||||
Managing bug reports
|
||||
|
|
|
@ -90,7 +90,7 @@ On-line docs
|
|||
:Date: 2008
|
||||
:Keywords: patches, review process, types of submissions, basic rules, case studies
|
||||
:Description: This paper gives several experience values on what types of patches
|
||||
there are and how likley they get merged.
|
||||
there are and how likely they get merged.
|
||||
:Abstract:
|
||||
[...]. This paper examines some common problems for
|
||||
submitting larger changes and some strategies to avoid problems.
|
||||
|
@ -328,7 +328,7 @@ On-line docs
|
|||
block devices, hardware interrupts, scsi, DMA, access to user memory,
|
||||
memory allocation, timers.
|
||||
:Description: A guide designed to help you get up to speed on the
|
||||
concepts that are not intuitevly obvious, and to document the internal
|
||||
concepts that are not intuitively obvious, and to document the internal
|
||||
structures of Linux.
|
||||
|
||||
* Title: **Dynamic Kernels: Modularized Device Drivers**
|
||||
|
|
|
@ -404,6 +404,8 @@ then you just add a line saying::
|
|||
|
||||
using your real name (sorry, no pseudonyms or anonymous contributions.)
|
||||
This will be done for you automatically if you use ``git commit -s``.
|
||||
Reverts should also include "Signed-off-by". ``git revert -s`` does that
|
||||
for you.
|
||||
|
||||
Some people also put extra tags at the end. They'll just be ignored for
|
||||
now, but you can do this to mark internal company procedures or just
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue