mirror of
https://github.com/a52xq-dev/kernel.git
synced 2026-10-18 21:58:11 +07:00
There is a nice new document from Neil on how pathname lookups work and
some new CAN driver documentation. Beyond that, we have kernel-doc fixes, a bit more work to support reproducible builds, and the usual collection of small fixes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJWO6HiAAoJEI3ONVYwIuV6ihwQAK0KC72h0706bdwDJ1p1/aJU QLuPeiKYWgGAXq2zgOyw3Povj4bkMwkiq1IGHLyK0Id4tg3ngxOXjimk4YKrqarI BD5HdpOm7IyQEe66ZU9b1RFDVst+bg3yp6ZIZsH5vQxl/KnyJ6AyaaDk8TPYId8S 1+CykJzxyi7GyT/jlLpHbKtBKrraoVke+cNPMAvOf0NjSyO7Ix5B+qH50sttG6Eu 9qcQ8hlKXOdZRTiGW6P+jeZNA+e5+CRpnG9VHBquHy4lI85kQThhWq41UMH690PP eRbLipeUybb0FwW2KwuMjGKEMDkMvrGJh0TzSXX9lGHd+5/41v7zcyKh8vJcpLjh bNQ2WOAKUBd2d15EP1MNoKXDLGJXusJczLwOjigWiSCQvgouAWwMrpWEw+Obv8Yl rdoH1oQqDFfDnk6mnKrSaqLWGNuLxDtkEl/1P0jsGSK6lM3FDkOgTuNPYXTJJgxN rXuGmPhyUlS2srERUeQJw2rISN0WRBvcKJGkMX6IpvrXHkItbelqK+yY1DeKPmcm qgbIx9ZWNqtltFpG22VVByqAVwucO5Nu8cAIQ2ysJsTnKOvQCQmhu5UKTjBCkEJM VpeMm32BfNiJFLuLTQGWBZ8bkRl2shQyXhOaR3uyqG4T+rpPD3qJi6dtFRpsAzOB q1nZuJCpOaxJFzjSKvpJ =emZ7 -----END PGP SIGNATURE----- Merge tag 'docs-for-linus' of git://git.lwn.net/linux Pull documentation update from Jon Corbet: "There is a nice new document from Neil on how pathname lookups work and some new CAN driver documentation. Beyond that, we have kernel-doc fixes, a bit more work to support reproducible builds, and the usual collection of small fixes" * tag 'docs-for-linus' of git://git.lwn.net/linux: (34 commits) Documentation: add new description of path-name lookup. Documentation/vm/slub.txt: document slabinfo-gnuplot.sh Doc: ABI/stable: Fix typo in ABI/stable doc: Clarify that nmi_watchdog param is for hardlockups Typo correction for description in gpio document. DocBook: Fix kernel-doc to be case-insensitive for private: kernel-docs.txt: update kernelnewbies reference Doc:kvm: Fix typo in Doc/virtual/kvm Documentation/Changes: Add bc in "Current Minimal Requirements" section Documentation/email-clients.txt: remove trailing whitespace DocBook: Use a fixed encoding for output MAINTAINERS: The docs tree has moved Docs/kernel-parameters: Add earlycon devicetree usage SubmittingPatches: make Subject examples match the de facto standard Documentation: gpio: mention that <function>-gpio has been deprecated Documentation: cgroups: just fix a few typos Documentation: Update kselftest.txt Documentation: DMA API: Be more explicit that nents is always the same Documentation: Update the default value of crashkernel low zram: update documentation ...
This commit is contained in:
commit
5ebe0ee802
39 changed files with 1658 additions and 133 deletions
|
|
@ -116,7 +116,7 @@ Description: The "pubek" property will return the TPM's public endorsement
|
|||
owner's authorization. Since the TPM driver doesn't store any
|
||||
secrets, it can't authorize its own request for the pubek,
|
||||
making it unaccessible. The public endorsement key is gener-
|
||||
ated at TPM menufacture time and exists for the life of the
|
||||
ated at TPM manufacture time and exists for the life of the
|
||||
chip.
|
||||
|
||||
Example output:
|
||||
|
|
@ -163,7 +163,7 @@ Date: April 2006
|
|||
KernelVersion: 2.6.17
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
Description: The "temp_deactivated" property returns a '1' if the chip has
|
||||
been temporarily dectivated, usually until the next power
|
||||
been temporarily deactivated, usually until the next power
|
||||
cycle. Whether a warm boot (reboot) will clear a TPM chip
|
||||
from a temp_deactivated state is platform specific.
|
||||
|
||||
|
|
|
|||
|
|
@ -57,4 +57,4 @@ Description:
|
|||
Shortly after acknowledging it, the log
|
||||
entry will be removed from sysfs.
|
||||
Reading this file will list the supported
|
||||
operations (curently just acknowledge).
|
||||
operations (currently just acknowledge).
|
||||
|
|
|
|||
|
|
@ -44,6 +44,7 @@ o grub 0.93 # grub --version || grub-insta
|
|||
o mcelog 0.6 # mcelog --version
|
||||
o iptables 1.4.2 # iptables -V
|
||||
o openssl & libcrypto 1.0.0 # openssl version
|
||||
o bc 1.06.95 # bc --version
|
||||
|
||||
|
||||
Kernel compilation
|
||||
|
|
|
|||
|
|
@ -681,6 +681,11 @@ or:
|
|||
|
||||
as appropriate.
|
||||
|
||||
PLEASE NOTE: The 'nents' argument to dma_sync_sg_for_cpu() and
|
||||
dma_sync_sg_for_device() must be the same passed to
|
||||
dma_map_sg(). It is _NOT_ the count returned by
|
||||
dma_map_sg().
|
||||
|
||||
After the last DMA transfer call one of the DMA unmap routines
|
||||
dma_unmap_{single,sg}(). If you don't touch the data from the first
|
||||
dma_map_*() call till dma_unmap_*(), then you don't have to call the
|
||||
|
|
|
|||
|
|
@ -340,7 +340,7 @@ accessed sg->address and sg->length as shown above.
|
|||
|
||||
void
|
||||
dma_unmap_sg(struct device *dev, struct scatterlist *sg,
|
||||
int nhwentries, enum dma_data_direction direction)
|
||||
int nents, enum dma_data_direction direction)
|
||||
|
||||
Unmap the previously mapped scatter/gather list. All the parameters
|
||||
must be the same as those and passed in to the scatter/gather mapping
|
||||
|
|
@ -356,10 +356,10 @@ void
|
|||
dma_sync_single_for_device(struct device *dev, dma_addr_t dma_handle, size_t size,
|
||||
enum dma_data_direction direction)
|
||||
void
|
||||
dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nelems,
|
||||
dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nents,
|
||||
enum dma_data_direction direction)
|
||||
void
|
||||
dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems,
|
||||
dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nents,
|
||||
enum dma_data_direction direction)
|
||||
|
||||
Synchronise a single contiguous or scatter/gather mapping for the CPU
|
||||
|
|
|
|||
2
Documentation/DocBook/.gitignore
vendored
2
Documentation/DocBook/.gitignore
vendored
|
|
@ -11,5 +11,7 @@
|
|||
*.png
|
||||
*.gif
|
||||
*.svg
|
||||
*.proc
|
||||
*.db
|
||||
media-indices.tmpl
|
||||
media-entities.tmpl
|
||||
|
|
|
|||
|
|
@ -69,6 +69,12 @@ installmandocs: mandocs
|
|||
KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
|
||||
KERNELDOC = $(srctree)/scripts/kernel-doc
|
||||
DOCPROC = $(objtree)/scripts/docproc
|
||||
CHECK_LC_CTYPE = $(objtree)/scripts/check-lc_ctype
|
||||
|
||||
# Use a fixed encoding - UTF-8 if the C library has support built-in
|
||||
# or ASCII if not
|
||||
LC_CTYPE := $(call try-run, LC_CTYPE=C.UTF-8 $(CHECK_LC_CTYPE),C.UTF-8,C)
|
||||
export LC_CTYPE
|
||||
|
||||
XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
|
||||
XMLTOFLAGS += --skip-validation
|
||||
|
|
|
|||
|
|
@ -659,8 +659,8 @@ succinct and descriptive, but that is what a well-written summary
|
|||
should do.
|
||||
|
||||
The "summary phrase" may be prefixed by tags enclosed in square
|
||||
brackets: "Subject: [PATCH tag] <summary phrase>". The tags are not
|
||||
considered part of the summary phrase, but describe how the patch
|
||||
brackets: "Subject: [PATCH <tag>...] <summary phrase>". The tags are
|
||||
not considered part of the summary phrase, but describe how the patch
|
||||
should be treated. Common tags might include a version descriptor if
|
||||
the multiple versions of the patch have been sent out in response to
|
||||
comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
|
||||
|
|
@ -672,8 +672,8 @@ the patch series.
|
|||
|
||||
A couple of example Subjects:
|
||||
|
||||
Subject: [patch 2/5] ext2: improve scalability of bitmap searching
|
||||
Subject: [PATCHv2 001/207] x86: fix eflags tracking
|
||||
Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
|
||||
Subject: [PATCH v2 01/27] x86: fix eflags tracking
|
||||
|
||||
The "from" line must be the very first line in the message body,
|
||||
and has the form:
|
||||
|
|
|
|||
|
|
@ -14,8 +14,43 @@ Statistics for individual zram devices are exported through sysfs nodes at
|
|||
|
||||
* Usage
|
||||
|
||||
There are several ways to configure and manage zram device(-s):
|
||||
a) using zram and zram_control sysfs attributes
|
||||
b) using zramctl utility, provided by util-linux (util-linux@vger.kernel.org).
|
||||
|
||||
In this document we will describe only 'manual' zram configuration steps,
|
||||
IOW, zram and zram_control sysfs attributes.
|
||||
|
||||
In order to get a better idea about zramctl please consult util-linux
|
||||
documentation, zramctl man-page or `zramctl --help'. Please be informed
|
||||
that zram maintainers do not develop/maintain util-linux or zramctl, should
|
||||
you have any questions please contact util-linux@vger.kernel.org
|
||||
|
||||
Following shows a typical sequence of steps for using zram.
|
||||
|
||||
WARNING
|
||||
=======
|
||||
For the sake of simplicity we skip error checking parts in most of the
|
||||
examples below. However, it is your sole responsibility to handle errors.
|
||||
|
||||
zram sysfs attributes always return negative values in case of errors.
|
||||
The list of possible return codes:
|
||||
-EBUSY -- an attempt to modify an attribute that cannot be changed once
|
||||
the device has been initialised. Please reset device first;
|
||||
-ENOMEM -- zram was not able to allocate enough memory to fulfil your
|
||||
needs;
|
||||
-EINVAL -- invalid input has been provided.
|
||||
|
||||
If you use 'echo', the returned value that is changed by 'echo' utility,
|
||||
and, in general case, something like:
|
||||
|
||||
echo 3 > /sys/block/zram0/max_comp_streams
|
||||
if [ $? -ne 0 ];
|
||||
handle_error
|
||||
fi
|
||||
|
||||
should suffice.
|
||||
|
||||
1) Load Module:
|
||||
modprobe zram num_devices=4
|
||||
This creates 4 devices: /dev/zram{0,1,2,3}
|
||||
|
|
@ -47,7 +82,7 @@ max_comp_streams adjustment.
|
|||
|
||||
3) Select compression algorithm
|
||||
Using comp_algorithm device attribute one can see available and
|
||||
currently selected (shown in square brackets) compression algortithms,
|
||||
currently selected (shown in square brackets) compression algorithms,
|
||||
change selected compression algorithm (once the device is initialised
|
||||
there is no way to change compression algorithm).
|
||||
|
||||
|
|
@ -119,7 +154,7 @@ execute
|
|||
8) Stats:
|
||||
Per-device statistics are exported as various nodes under /sys/block/zram<id>/
|
||||
|
||||
A brief description of exported device attritbutes. For more details please
|
||||
A brief description of exported device attributes. For more details please
|
||||
read Documentation/ABI/testing/sysfs-block-zram.
|
||||
|
||||
Name access description
|
||||
|
|
@ -140,8 +175,9 @@ zero_pages RO the number of zero filled pages written to this disk
|
|||
orig_data_size RO uncompressed size of data stored in this disk
|
||||
compr_data_size RO compressed size of data stored in this disk
|
||||
mem_used_total RO the amount of memory allocated for this disk
|
||||
mem_used_max RW the maximum amount memory zram have consumed to
|
||||
store compressed data
|
||||
mem_used_max RW the maximum amount of memory zram have consumed to
|
||||
store the data (to reset this counter to the actual
|
||||
current value, write 1 to this attribute)
|
||||
mem_limit RW the maximum amount of memory ZRAM can use to store
|
||||
the compressed data
|
||||
pages_compacted RO the number of pages freed during compaction
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ cgroups. Here is what you can do.
|
|||
- At macro level, first dd should finish first. To get more precise data, keep
|
||||
on looking at (with the help of script), at blkio.disk_time and
|
||||
blkio.disk_sectors files of both test1 and test2 groups. This will tell how
|
||||
much disk time (in milli seconds), each group got and how many secotors each
|
||||
much disk time (in milliseconds), each group got and how many sectors each
|
||||
group dispatched to the disk. We provide fairness in terms of disk time, so
|
||||
ideally io.disk_time of cgroups should be in proportion to the weight.
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ being frozen. This allows the bash example above and gdb to run as
|
|||
expected.
|
||||
|
||||
The cgroup freezer is hierarchical. Freezing a cgroup freezes all
|
||||
tasks beloning to the cgroup and all its descendant cgroups. Each
|
||||
tasks belonging to the cgroup and all its descendant cgroups. Each
|
||||
cgroup has its own state (self-state) and the state inherited from the
|
||||
parent (parent-state). Iff both states are THAWED, the cgroup is
|
||||
THAWED.
|
||||
|
|
|
|||
|
|
@ -494,7 +494,7 @@ may be specified in any order and not all pairs have to be specified.
|
|||
${R|W}BPS are read/write bytes per second and ${R|W}IOPS are
|
||||
read/write IOs per second. "max" indicates no limit. Writing
|
||||
to the file follows the same format but the individual
|
||||
settings may be ommitted or specified in any order.
|
||||
settings may be omitted or specified in any order.
|
||||
|
||||
This file is available only on non-root cgroups.
|
||||
|
||||
|
|
|
|||
|
|
@ -220,7 +220,7 @@ to coerce it into behaving.
|
|||
Compose dialog.
|
||||
|
||||
Please note that "external editor" requires that your editor must not
|
||||
fork, or in other words, the editor must not return before closing.
|
||||
fork, or in other words, the editor must not return before closing.
|
||||
You may have to pass additional flags or change the settings of your
|
||||
editor. Most notably if you are using gvim then you must pass the -f
|
||||
option to gvim by putting "/usr/bin/gvim -f" (if the binary is in
|
||||
|
|
|
|||
1297
Documentation/filesystems/path-lookup.md
Normal file
1297
Documentation/filesystems/path-lookup.md
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -379,4 +379,4 @@ Papers and other documentation on dcache locking
|
|||
|
||||
2. http://lse.sourceforge.net/locking/dcache/dcache.html
|
||||
|
||||
|
||||
3. path-lookup.md in this directory.
|
||||
|
|
|
|||
|
|
@ -17,13 +17,13 @@ the sysfs directory entries we ensure that we don't have conflicts
|
|||
in the directories and applications only see a limited set of
|
||||
the network devices.
|
||||
|
||||
Each sysfs directory entry may be tagged with zero or one
|
||||
namespaces. A sysfs_dirent is augmented with a void *s_ns. If a
|
||||
directory entry is tagged, then sysfs_dirent->s_flags will have a
|
||||
flag between KOBJ_NS_TYPE_NONE and KOBJ_NS_TYPES, and s_ns will
|
||||
point to the namespace to which it belongs.
|
||||
Each sysfs directory entry may be tagged with a namespace via the
|
||||
void *ns member of its kernfs_node. If a directory entry is tagged,
|
||||
then kernfs_node->flags will have a flag between KOBJ_NS_TYPE_NONE
|
||||
and KOBJ_NS_TYPES, and ns will point to the namespace to which it
|
||||
belongs.
|
||||
|
||||
Each sysfs superblock's sysfs_super_info contains an array void
|
||||
Each sysfs superblock's kernfs_super_info contains an array void
|
||||
*ns[KOBJ_NS_TYPES]. When a task in a tagging namespace
|
||||
kobj_nstype first mounts sysfs, a new superblock is created. It
|
||||
will be differentiated from other sysfs mounts by having its
|
||||
|
|
@ -31,7 +31,7 @@ s_fs_info->ns[kobj_nstype] set to the new namespace. Note that
|
|||
through bind mounting and mounts propagation, a task can easily view
|
||||
the contents of other namespaces' sysfs mounts. Therefore, when a
|
||||
namespace exits, it will call kobj_ns_exit() to invalidate any
|
||||
sysfs_dirent->s_ns pointers pointing to it.
|
||||
kernfs_node->ns pointers pointing to it.
|
||||
|
||||
Users of this interface:
|
||||
- define a type in the kobj_ns_type enumeration.
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ ancestors of object hierarchies; i.e. the subsystems the objects
|
|||
belong to.
|
||||
|
||||
Sysfs internally stores a pointer to the kobject that implements a
|
||||
directory in the sysfs_dirent object associated with the directory. In
|
||||
directory in the kernfs_node object associated with the directory. In
|
||||
the past this kobject pointer has been used by sysfs to do reference
|
||||
counting directly on the kobject whenever the file is opened or closed.
|
||||
With the current sysfs implementation the kobject reference count is
|
||||
|
|
@ -191,9 +191,10 @@ implementations:
|
|||
be called again, rearmed, to fill the buffer.
|
||||
|
||||
- On write(2), sysfs expects the entire buffer to be passed during the
|
||||
first write. Sysfs then passes the entire buffer to the store()
|
||||
method.
|
||||
|
||||
first write. Sysfs then passes the entire buffer to the store() method.
|
||||
A terminating null is added after the data on stores. This makes
|
||||
functions like sysfs_streq() safe to use.
|
||||
|
||||
When writing sysfs files, userspace processes should first read the
|
||||
entire file, modify the values it wishes to change, then write the
|
||||
entire buffer back.
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@ exact way to do it depends on the GPIO controller providing the GPIOs, see the
|
|||
device tree bindings for your controller.
|
||||
|
||||
GPIOs mappings are defined in the consumer device's node, in a property named
|
||||
either <function>-gpios or <function>-gpio, where <function> is the function
|
||||
the driver will request through gpiod_get(). For example:
|
||||
<function>-gpios, where <function> is the function the driver will request
|
||||
through gpiod_get(). For example:
|
||||
|
||||
foo_device {
|
||||
compatible = "acme,foo";
|
||||
|
|
@ -31,9 +31,13 @@ the driver will request through gpiod_get(). For example:
|
|||
<&gpio 16 GPIO_ACTIVE_HIGH>, /* green */
|
||||
<&gpio 17 GPIO_ACTIVE_HIGH>; /* blue */
|
||||
|
||||
power-gpio = <&gpio 1 GPIO_ACTIVE_LOW>;
|
||||
power-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
|
||||
};
|
||||
|
||||
Properties named <function>-gpio are also considered valid and old bindings use
|
||||
it but are only supported for compatibility reasons and should not be used for
|
||||
newer bindings since it has been deprecated.
|
||||
|
||||
This property will make GPIOs 15, 16 and 17 available to the driver under the
|
||||
"led" function, and GPIO 1 as the "power" GPIO:
|
||||
|
||||
|
|
|
|||
|
|
@ -20,14 +20,14 @@ userspace GPIO can be used to determine system configuration data that
|
|||
standard kernels won't know about. And for some tasks, simple userspace
|
||||
GPIO drivers could be all that the system really needs.
|
||||
|
||||
DO NOT ABUSE SYFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS.
|
||||
DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS.
|
||||
PLEASE READ THE DOCUMENT NAMED "drivers-on-gpio.txt" IN THIS DOCUMENTATION
|
||||
DIRECTORY TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT.
|
||||
REALLY.
|
||||
|
||||
Paths in Sysfs
|
||||
--------------
|
||||
There are three kinds of entry in /sys/class/gpio:
|
||||
There are three kinds of entries in /sys/class/gpio:
|
||||
|
||||
- Control interfaces used to get userspace control over GPIOs;
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ read-only attributes:
|
|||
|
||||
"label" ... provided for diagnostics (not always unique)
|
||||
|
||||
"ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)
|
||||
"ngpio" ... how many GPIOs this manages (N to N + ngpio - 1)
|
||||
|
||||
Board documentation should in most cases cover what GPIOs are used for
|
||||
what purposes. However, those numbers are not always stable; GPIOs on
|
||||
|
|
|
|||
|
|
@ -696,18 +696,18 @@
|
|||
Memory related patches, HOWTOs, links, mm developers... Don't miss
|
||||
it if you are interested in memory management development!
|
||||
|
||||
* Name: "Kernel Newbies IRC Channel"
|
||||
* Name: "Kernel Newbies IRC Channel and Website"
|
||||
URL: http://www.kernelnewbies.org
|
||||
Keywords: IRC, newbies, channel, asking doubts.
|
||||
Description: #kernelnewbies on irc.openprojects.net. From the web
|
||||
page: "#kernelnewbies is an IRC network dedicated to the 'newbie'
|
||||
Description: #kernelnewbies on irc.oftc.net.
|
||||
#kernelnewbies is an IRC network dedicated to the 'newbie'
|
||||
kernel hacker. The audience mostly consists of people who are
|
||||
learning about the kernel, working on kernel projects or
|
||||
professional kernel hackers that want to help less seasoned kernel
|
||||
people. [...] #kernelnewbies is on the Open Projects IRC Network,
|
||||
try irc.openprojects.net or irc.<country>.openprojects.net as your
|
||||
server and then /join #kernelnewbies". It also hosts articles,
|
||||
documents, FAQs...
|
||||
people.
|
||||
#kernelnewbies is on the OFTC IRC Network.
|
||||
Try irc.oftc.net as your server and then /join #kernelnewbies.
|
||||
The kernelnewbies website also hosts articles, documents, FAQs...
|
||||
|
||||
* Name: "linux-kernel mailing list archives and search engines"
|
||||
URL: http://vger.kernel.org/vger-lists.html
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue