anierin/msm-5.15
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Snap for 7546167 from 48874a284d to android-mainline-keystone-qcom-release

Browse Source 
Change-Id: Ia42a7979a29dcccb9b3c785d4228c1b4873396bb
This commit is contained in:
Android Build Coastguard Worker
2021-07-14 00:00:21 +00:00
parent 70b421823c 48874a284d
commit 7fcfb7b032
7754 changed files with 308917 additions and 120095 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
.clang-format
View File

@@ -109,8 +109,8 @@ ForEachMacros:
- 'css_for_each_child'
- 'css_for_each_descendant_post'
- 'css_for_each_descendant_pre'
- 'cxl_for_each_cmd'
- 'device_for_each_child_node'
- 'displayid_iter_for_each'
- 'dma_fence_chain_for_each'
- 'do_for_each_ftrace_op'
- 'drm_atomic_crtc_for_each_plane'
@@ -136,6 +136,7 @@ ForEachMacros:
- 'drm_mm_for_each_node_in_range'
- 'drm_mm_for_each_node_safe'
- 'flow_action_for_each'
- 'for_each_acpi_dev_match'
- 'for_each_active_dev_scope'
- 'for_each_active_drhd_unit'
- 'for_each_active_iommu'
@@ -171,7 +172,6 @@ ForEachMacros:
- 'for_each_dapm_widgets'
- 'for_each_dev_addr'
- 'for_each_dev_scope'
- 'for_each_displayid_db'
- 'for_each_dma_cap_mask'
- 'for_each_dpcm_be'
- 'for_each_dpcm_be_rollback'
@@ -179,6 +179,7 @@ ForEachMacros:
- 'for_each_dpcm_fe'
- 'for_each_drhd_unit'
- 'for_each_dss_dev'
- 'for_each_dtpm_table'
- 'for_each_efi_memory_desc'
- 'for_each_efi_memory_desc_in_map'
- 'for_each_element'
@@ -215,6 +216,7 @@ ForEachMacros:
- 'for_each_migratetype_order'
- 'for_each_msi_entry'
- 'for_each_msi_entry_safe'
- 'for_each_msi_vector'
- 'for_each_net'
- 'for_each_net_continue_reverse'
- 'for_each_netdev'
@@ -270,6 +272,12 @@ ForEachMacros:
- 'for_each_prime_number_from'
- 'for_each_process'
- 'for_each_process_thread'
- 'for_each_prop_codec_conf'
- 'for_each_prop_dai_codec'
- 'for_each_prop_dai_cpu'
- 'for_each_prop_dlc_codecs'
- 'for_each_prop_dlc_cpus'
- 'for_each_prop_dlc_platforms'
- 'for_each_property_of_node'
- 'for_each_registered_fb'
- 'for_each_requested_gpio'
@@ -430,6 +438,7 @@ ForEachMacros:
- 'queue_for_each_hw_ctx'
- 'radix_tree_for_each_slot'
- 'radix_tree_for_each_tagged'
- 'rb_for_each'
- 'rbtree_postorder_for_each_entry_safe'
- 'rdma_for_each_block'
- 'rdma_for_each_port'

10
.gitignore vendored
View File

@@ -48,22 +48,22 @@
*.xz
*.zst
Module.symvers
modules.builtin
modules.order
#
# Top-level generic files
#
/tags
/TAGS
/linux
/modules-only.symvers
/vmlinux
/vmlinux.32
/vmlinux.map
/vmlinux.symvers
/vmlinux-gdb.py
/vmlinuz
/System.map
/Module.markers
/modules.builtin
/modules.builtin.modinfo
/modules.nsdeps
@@ -112,6 +112,10 @@ patches-*
patches
series
# ctags files
tags
TAGS
# cscope files
cscope.*
ncscope.*

6
.mailmap
View File

@@ -160,6 +160,7 @@ Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
Jens Axboe <axboe@suse.de>
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
Jiri Slaby <jirislaby@kernel.org> <jirislaby@gmail.com>
Jiri Slaby <jirislaby@kernel.org> <jslaby@novell.com>
Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.com>
@@ -211,6 +212,8 @@ Manivannan Sadhasivam <mani@kernel.org> <manivannanece23@gmail.com>
Manivannan Sadhasivam <mani@kernel.org> <manivannan.sadhasivam@linaro.org>
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
Marek Behún <kabel@kernel.org> <marek.behun@nic.cz>
Marek Behún <kabel@kernel.org> Marek Behun <marek.behun@nic.cz>
Mark Brown <broonie@sirena.org.uk>
Mark Starovoytov <mstarovo@pm.me> <mstarovoitov@marvell.com>
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
@@ -242,6 +245,9 @@ Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
Mayuresh Janorkar <mayur@ti.com>
Michael Buesch <m@bues.ch>
Michel Dänzer <michel@tungstengraphics.com>
Michel Lespinasse <michel@lespinasse.org>
Michel Lespinasse <michel@lespinasse.org> <walken@google.com>
Michel Lespinasse <michel@lespinasse.org> <walken@zoy.org>
Miguel Ojeda <ojeda@kernel.org> <miguel.ojeda.sandonis@gmail.com>
Mike Rapoport <rppt@kernel.org> <mike@compulab.co.il>
Mike Rapoport <rppt@kernel.org> <mike.rapoport@gmail.com>

84
BUILD.bazel Normal file
View File

@@ -0,0 +1,84 @@
# Copyright (C) 2021 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
load("//build/kleaf:kernel.bzl", "kernel_build")
filegroup(
name = "build_configs",
srcs = glob(["build.config.*"]),
)
filegroup(
name = "sources",
srcs = glob(
["**"],
exclude = [
"build.config.*",
"android/*",
"BUILD.bazel",
"**/*.bzl",
],
),
)
common_outs = [
"System.map",
"modules.builtin",
"modules.builtin.modinfo",
"vmlinux",
"vmlinux.symvers",
"kernel-headers.tar.gz",
"kernel-uapi-headers.tar.gz",
]
aarch64_outs = common_outs + [
"Image",
"Image.lz4",
]
x86_64_outs = common_outs + ["bzImage"]
[kernel_build(
name = name,
outs = outs,
build_config = config,
build_configs = "//common:build_configs",
sources = "//common:sources",
) for name, config, outs in [
(
"kernel_aarch64",
"common/build.config.gki.aarch64",
aarch64_outs,
),
(
"kernel_aarch64_debug",
"common/build.config.gki-debug.aarch64",
aarch64_outs,
),
(
"kernel_x86_64",
"common/build.config.gki.x86_64",
x86_64_outs,
),
(
"kernel_x86_64_debug",
"common/build.config.gki-debug.x86_64",
x86_64_outs,
),
]]
alias(
name = "kernel",
actual = ":kernel_aarch64",
)

8
CREDITS
View File

@@ -1874,6 +1874,11 @@ S: Krosenska' 543
S: 181 00 Praha 8
S: Czech Republic
N: Murali Karicheri
E: m-karicheri2@ti.com
D: Keystone NetCP driver
D: Keystone PCIe host controller driver
N: Jan "Yenya" Kasprzak
E: kas@fi.muni.cz
D: Author of the COSA/SRP sync serial board driver.
@@ -1933,6 +1938,9 @@ N: Kukjin Kim
E: kgene@kernel.org
D: Samsung S3C, S5P and Exynos ARM architectures
N: Milo Kim
D: TI LP855x, LP8727 and LP8788 drivers
N: Sangbeom Kim
E: sbkim73@samsung.com
D: Samsung SoC Audio (ASoC) drivers

2
Documentation/ABI/obsolete/sysfs-class-dax
View File

@@ -1,7 +1,7 @@
What: /sys/class/dax/
Date: May, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description: Device DAX is the device-centric analogue of Filesystem
DAX (CONFIG_FS_DAX). It allows memory ranges to be
allocated and mapped without need of an intervening file

2
Documentation/ABI/obsolete/sysfs-kernel-fadump_registered
View File

@@ -1,4 +1,4 @@
This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.¬
This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.
What: /sys/kernel/fadump_registered
Date: Feb 2012

2
Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem
View File

@@ -1,4 +1,4 @@
This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.¬
This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.
What: /sys/kernel/fadump_release_mem
Date: Feb 2012

2
Documentation/ABI/removed/sysfs-bus-nfit
View File

@@ -1,7 +1,7 @@
What: /sys/bus/nd/devices/regionX/nfit/ecc_unit_size
Date: Aug, 2017
KernelVersion: v4.14 (Removed v4.18)
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Size of a write request to a DIMM that will not incur a
read-modify-write cycle at the memory controller.

1
Documentation/ABI/testing/OWNERS Normal file
View File

@@ -0,0 +1 @@
per-file sysfs-fs-f2fs=file:/fs/f2fs/OWNERS

18
Documentation/ABI/testing/sysfs-block-rnbd
View File

@@ -44,3 +44,21 @@ Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains the device access mode: ro, rw or migration.
What: /sys/block/rnbd<N>/rnbd/resize
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Write the number of sectors to change the size of the disk.
What: /sys/block/rnbd<N>/rnbd/remap_device
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Remap the disconnected device if the session is not destroyed yet.
What: /sys/block/rnbd<N>/rnbd/nr_poll_queues
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains the number of poll-mode queues

14
Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe Normal file
View File

@@ -0,0 +1,14 @@
What: /sys/bus/coresight/devices/trbe<cpu>/align
Date: March 2021
KernelVersion: 5.13
Contact: Anshuman Khandual <anshuman.khandual@arm.com>
Description: (Read) Shows the TRBE write pointer alignment. This value
is fetched from the TRBIDR register.
What: /sys/bus/coresight/devices/trbe<cpu>/flag
Date: March 2021
KernelVersion: 5.13
Contact: Anshuman Khandual <anshuman.khandual@arm.com>
Description: (Read) Shows if TRBE updates in the memory are with access
and dirty flag updates as well. This value is fetched from
the TRBIDR register.

30
Documentation/ABI/testing/sysfs-bus-event_source-devices-dsa Normal file
View File

@@ -0,0 +1,30 @@
What: /sys/bus/event_source/devices/dsa*/format
Date: April 2021
KernelVersion: 5.13
Contact: Tom Zanussi <tom.zanussi@linux.intel.com>
Description: Read-only. Attribute group to describe the magic bits
that go into perf_event_attr.config or
perf_event_attr.config1 for the IDXD DSA pmu. (See also
ABI/testing/sysfs-bus-event_source-devices-format).
Each attribute in this group defines a bit range in
perf_event_attr.config or perf_event_attr.config1.
All supported attributes are listed below (See the
IDXD DSA Spec for possible attribute values)::
event_category = "config:0-3" - event category
event = "config:4-31" - event ID
filter_wq = "config1:0-31" - workqueue filter
filter_tc = "config1:32-39" - traffic class filter
filter_pgsz = "config1:40-43" - page size filter
filter_sz = "config1:44-51" - transfer size filter
filter_eng = "config1:52-59" - engine filter
What: /sys/bus/event_source/devices/dsa*/cpumask
Date: April 2021
KernelVersion: 5.13
Contact: Tom Zanussi <tom.zanussi@linux.intel.com>
Description: Read-only. This file always returns the cpu to which the
IDXD DSA pmu is bound for access to all dsa pmu
performance monitoring events.

40
Documentation/ABI/testing/sysfs-bus-nfit
View File

@@ -5,7 +5,7 @@ Interface Table (NFIT)' section in the ACPI specification
What: /sys/bus/nd/devices/nmemX/nfit/serial
Date: Jun, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Serial number of the NVDIMM (non-volatile dual in-line
memory module), assigned by the module vendor.
@@ -14,7 +14,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/handle
Date: Apr, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) The address (given by the _ADR object) of the device on its
parent bus of the NVDIMM device containing the NVDIMM region.
@@ -23,7 +23,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/device
Date: Apr, 2015
KernelVersion: v4.1
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Device id for the NVDIMM, assigned by the module vendor.
@@ -31,7 +31,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/rev_id
Date: Jun, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Revision of the NVDIMM, assigned by the module vendor.
@@ -39,7 +39,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/phys_id
Date: Apr, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Handle (i.e., instance number) for the SMBIOS (system
management BIOS) Memory Device structure describing the NVDIMM
@@ -49,7 +49,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/flags
Date: Jun, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) The flags in the NFIT memory device sub-structure indicate
the state of the data on the nvdimm relative to its energy
@@ -68,7 +68,7 @@ What: /sys/bus/nd/devices/nmemX/nfit/format1
What: /sys/bus/nd/devices/nmemX/nfit/formats
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) The interface codes indicate support for persistent memory
mapped directly into system physical address space and / or a
@@ -84,7 +84,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/vendor
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Vendor id of the NVDIMM.
@@ -92,7 +92,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/dsm_mask
Date: May, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) The bitmask indicates the supported device specific control
functions relative to the NVDIMM command family supported by the
@@ -102,7 +102,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/family
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Displays the NVDIMM family command sets. Values
0, 1, 2 and 3 correspond to NVDIMM_FAMILY_INTEL,
@@ -118,7 +118,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/id
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) ACPI specification 6.2 section 5.2.25.9, defines an
identifier for an NVDIMM, which refelects the id attribute.
@@ -127,7 +127,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_vendor
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system vendor id of the NVDIMM non-volatile memory
subsystem controller.
@@ -136,7 +136,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_rev_id
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system revision id of the NVDIMM non-volatile memory subsystem
controller, assigned by the non-volatile memory subsystem
@@ -146,7 +146,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_device
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system device id for the NVDIMM non-volatile memory
subsystem controller, assigned by the non-volatile memory
@@ -156,7 +156,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/revision
Date: Jun, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) ACPI NFIT table revision number.
@@ -164,7 +164,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/scrub
Date: Sep, 2016
KernelVersion: v4.9
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RW) This shows the number of full Address Range Scrubs (ARS)
that have been completed since driver load time. Userspace can
@@ -177,7 +177,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/hw_error_scrub
Date: Sep, 2016
KernelVersion: v4.9
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RW) Provides a way to toggle the behavior between just adding
the address (cache line) where the MCE happened to the poison
@@ -196,7 +196,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/dsm_mask
Date: Jun, 2017
KernelVersion: v4.13
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) The bitmask indicates the supported bus specific control
functions. See the section named 'NVDIMM Root Device _DSMs' in
@@ -205,7 +205,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/firmware_activate_noidle
Date: Apr, 2020
KernelVersion: v5.8
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RW) The Intel platform implementation of firmware activate
support exposes an option let the platform force idle devices in
@@ -225,7 +225,7 @@ Description:
What: /sys/bus/nd/devices/regionX/nfit/range_index
Date: Jun, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) A unique number provided by the BIOS to identify an address
range. Used by NVDIMM Region Mapping Structure to uniquely refer

4
Documentation/ABI/testing/sysfs-bus-papr-pmem
View File

@@ -1,7 +1,7 @@
What: /sys/bus/nd/devices/nmemX/papr/flags
Date: Apr, 2020
KernelVersion: v5.8
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
Description:
(RO) Report flags indicating various states of a
papr-pmem NVDIMM device. Each flag maps to a one or
@@ -36,7 +36,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/papr/perf_stats
Date: May, 2020
KernelVersion: v5.9
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
Description:
(RO) Report various performance stats related to papr-scm NVDIMM
device. Each stat is reported on a new line with each line

29
Documentation/ABI/testing/sysfs-bus-pci
View File

@@ -378,3 +378,32 @@ Description:
The value comes from the PCI kernel device state and can be one
of: "unknown", "error", "D0", D1", "D2", "D3hot", "D3cold".
The file is read only.
What: /sys/bus/pci/devices/.../sriov_vf_total_msix
Date: January 2021
Contact: Leon Romanovsky <leonro@nvidia.com>
Description:
This file is associated with a SR-IOV physical function (PF).
It contains the total number of MSI-X vectors available for
assignment to all virtual functions (VFs) associated with PF.
The value will be zero if the device doesn't support this
functionality. For supported devices, the value will be
constant and won't be changed after MSI-X vectors assignment.
What: /sys/bus/pci/devices/.../sriov_vf_msix_count
Date: January 2021
Contact: Leon Romanovsky <leonro@nvidia.com>
Description:
This file is associated with a SR-IOV virtual function (VF).
It allows configuration of the number of MSI-X vectors for
the VF. This allows devices that have a global pool of MSI-X
vectors to optimally divide them between VFs based on VF usage.
The values accepted are:
* > 0 - this number will be reported as the Table Size in the
VF's MSI-X capability
* < 0 - not valid
* = 0 - will reset to the device default value
The file is writable if the PF is bound to a driver that
implements ->sriov_set_msix_vec_count().

12
Documentation/ABI/testing/sysfs-class-net-phydev
View File

@@ -51,3 +51,15 @@ Description:
Boolean value indicating whether the PHY device is used in
standalone mode, without a net_device associated, by PHYLINK.
Attribute created only when this is the case.
What: /sys/class/mdio_bus/<bus>/<device>/phy_dev_flags
Date: March 2021
KernelVersion: 5.13
Contact: netdev@vger.kernel.org
Description:
32-bit hexadecimal number representing a bit mask of the
configuration bits passed from the consumer of the PHY
(Ethernet MAC, switch, etc.) to the PHY driver. The flags are
only used internally by the kernel and their placement are
not meant to be stable across kernel versions. This is intended
for facilitating the debugging of PHY drivers.

16
Documentation/ABI/testing/sysfs-class-net-qmi
View File

@@ -58,3 +58,19 @@ Description:
Indicates the mux id associated to the qmimux network interface
during its creation.
What: /sys/class/net/<iface>/qmi/pass_through
Date: January 2021
KernelVersion: 5.12
Contact: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Description:
Boolean. Default: 'N'
Set this to 'Y' to enable 'pass-through' mode, allowing packets
in MAP format to be passed on to the stack.
Normally the rmnet driver (CONFIG_RMNET) is then used to process
and demultiplex these packets.
'Pass-through' mode can be enabled when the device is in
'raw-ip' mode only.

15
Documentation/ABI/testing/sysfs-class-power-surface Normal file
View File

@@ -0,0 +1,15 @@
What: /sys/class/power_supply/<supply_name>/alarm
Date: April 2021
KernelVersion: 5.13
Contact: Maximilian Luz <luzmaximilian@gmail.com>
Description:
Battery trip point. When the remaining battery capacity crosses this
value in either direction, the system will be notified and if
necessary woken.
Set to zero to clear/disable.
Access: Read, Write
Valid values: In micro-Wh or micro-Ah, depending on the power unit
of the battery

13
Documentation/ABI/testing/sysfs-class-rnbd-client
View File

@@ -85,6 +85,19 @@ Description: Expected format is the following::
By default "rw" is used.
nr_poll_queues
specifies the number of poll-mode queues. If the IO has HIPRI flag,
the block-layer will send the IO via the poll-mode queue.
For fast network and device the polling is faster than interrupt-base
IO handling because it saves time for context switching, switching to
another process, handling the interrupt and switching back to the
issuing process.
Set -1 if you want to set it as the number of CPUs
By default rnbd client creates only irq-mode queues.
NOTICE: MUST make a unique session for a device using the poll-mode queues.
Exit Codes:
If the device is already mapped it will fail with EEXIST. If the input

12
Documentation/ABI/testing/sysfs-class-rtrs-client
View File

@@ -34,6 +34,9 @@ Description: Multipath policy specifies which path should be selected on each IO
min-inflight (1):
select path with minimum inflights.
min-latency (2):
select path with minimum latency.
What: /sys/class/rtrs-client/<session-name>/paths/
Date: Feb 2020
KernelVersion: 5.7
@@ -95,6 +98,15 @@ KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the destination address of the path
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/cur_latency
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the latency time calculated by the heart-beat messages.
Whenever the client sends heart-beat message, it checks the time gap
between sending the heart-beat message and receiving the ACK.
This value can be changed regularly.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/reset_all
Date: Feb 2020
KernelVersion: 5.7

2
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@@ -285,7 +285,7 @@ Description: Disable L3 cache indices
All AMD processors with L3 caches provide this functionality.
For details, see BKDGs at
http://developer.amd.com/documentation/guides/Pages/default.aspx
https://www.amd.com/en/support/tech-docs?keyword=bios+kernel
What: /sys/devices/system/cpu/cpufreq/boost

9
Documentation/ABI/testing/sysfs-driver-input-exc3000
View File

@@ -15,3 +15,12 @@ Description: Reports the model identification provided by the touchscreen, fo
Access: Read
Valid values: Represented as string
What: /sys/bus/i2c/devices/xxx/type
Date: Jan 2021
Contact: linux-input@vger.kernel.org
Description: Reports the type identification provided by the touchscreen, for example "PCAP82H80 Series"
Access: Read
Valid values: Represented as string

31
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@@ -276,7 +276,7 @@ Date April 2019
Contact: "Daniel Rosenberg" <drosen@google.com>
Description: If checkpoint=disable, it displays the number of blocks that
are unusable.
If checkpoint=enable it displays the enumber of blocks that
If checkpoint=enable it displays the number of blocks that
would be unusable if checkpoint=disable were to be set.
What: /sys/fs/f2fs/<disk>/encoding
@@ -409,3 +409,32 @@ Description: Give a way to change checkpoint merge daemon's io priority.
I/O priority "3". We can select the class between "rt" and "be",
and set the I/O priority within valid range of it. "," delimiter
is necessary in between I/O class and priority number.
What: /sys/fs/f2fs/<disk>/ovp_segments
Date: March 2021
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Shows the number of overprovision segments.
What: /sys/fs/f2fs/<disk>/compr_written_block
Date: March 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the block count written after compression since mount. Note
that when the compressed blocks are deleted, this count doesn't
decrease. If you write "0" here, you can initialize
compr_written_block and compr_saved_block to "0".
What: /sys/fs/f2fs/<disk>/compr_saved_block
Date: March 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the saved block count with compression since mount. Note
that when the compressed blocks are deleted, this count doesn't
decrease. If you write "0" here, you can initialize
compr_written_block and compr_saved_block to "0".
What: /sys/fs/f2fs/<disk>/compr_new_inode
Date: March 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the count of inode newly enabled for compression since mount.
Note that when the compression is disabled for the files, this count
doesn't decrease. If you write "0" here, you can initialize
compr_new_inode to "0".

27
Documentation/ABI/testing/sysfs-kernel-ion
View File

@@ -1,27 +0,0 @@
What: /sys/kernel/ion
Date: Dec 2019
KernelVersion: 4.14.158
Contact: Suren Baghdasaryan <surenb@google.com>,
Sandeep Patil <sspatil@google.com>
Description:
The /sys/kernel/ion directory contains a snapshot of the
internal state of ION memory heaps and pools.
Users: kernel memory tuning tools
What: /sys/kernel/ion/total_heaps_kb
Date: Dec 2019
KernelVersion: 4.14.158
Contact: Suren Baghdasaryan <surenb@google.com>,
Sandeep Patil <sspatil@google.com>
Description:
The total_heaps_kb file is read-only and specifies how much
memory in Kb is allocated to ION heaps.
What: /sys/kernel/ion/total_pools_kb
Date: Dec 2019
KernelVersion: 4.14.158
Contact: Suren Baghdasaryan <surenb@google.com>,
Sandeep Patil <sspatil@google.com>
Description:
The total_pools_kb file is read-only and specifies how much
memory in Kb is allocated to ION pools.

25
Documentation/ABI/testing/sysfs-kernel-mm-cma Normal file
View File

@@ -0,0 +1,25 @@
What: /sys/kernel/mm/cma/
Date: Feb 2021
Contact: Minchan Kim <minchan@kernel.org>
Description:
/sys/kernel/mm/cma/ contains a subdirectory for each CMA
heap name (also sometimes called CMA areas).
Each CMA heap subdirectory (that is, each
/sys/kernel/mm/cma/<cma-heap-name> directory) contains the
following items:
alloc_pages_success
alloc_pages_fail
What: /sys/kernel/mm/cma/<cma-heap-name>/alloc_pages_success
Date: Feb 2021
Contact: Minchan Kim <minchan@kernel.org>
Description:
the number of pages CMA API succeeded to allocate
What: /sys/kernel/mm/cma/<cma-heap-name>/alloc_pages_fail
Date: Feb 2021
Contact: Minchan Kim <minchan@kernel.org>
Description:
the number of pages CMA API failed to allocate

4
Documentation/ABI/testing/sysfs-module
View File

@@ -37,13 +37,13 @@ Description: Maximum time allowed for periodic transfers per microframe (μs)
What: /sys/module/*/{coresize,initsize}
Date: Jan 2012
KernelVersion:»·3.3
KernelVersion: 3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description: Module size in bytes.
What: /sys/module/*/taint
Date: Jan 2012
KernelVersion:»·3.3
KernelVersion: 3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description: Module taint flags:
== =====================

30
Documentation/admin-guide/bootconfig.rst
View File

@@ -89,13 +89,35 @@ you can use ``+=`` operator. For example::
In this case, the key ``foo`` has ``bar``, ``baz`` and ``qux``.
However, a sub-key and a value can not co-exist under a parent key.
For example, following config is NOT allowed.::
Moreover, sub-keys and a value can coexist under a parent key.
For example, following config is allowed.::
foo = value1
foo.bar = value2 # !ERROR! subkey "bar" and value "value1" can NOT co-exist
foo.bar := value2 # !ERROR! even with the override operator, this is NOT allowed.
foo.bar = value2
foo := value3 # This will update foo's value.
Note, since there is no syntax to put a raw value directly under a
structured key, you have to define it outside of the brace. For example::
foo {
bar = value1
bar {
baz = value2
qux = value3
}
}
Also, the order of the value node under a key is fixed. If there
are a value and subkeys, the value is always the first child node
of the key. Thus if user specifies subkeys first, e.g.::
foo.bar = value1
foo = value2
In the program (and /proc/bootconfig), it will be shown as below::
foo = value2
foo.bar = value1
Comments
--------

2
Documentation/admin-guide/devices.txt
View File

@@ -4,7 +4,7 @@
1 char Memory devices
1 = /dev/mem Physical memory access
2 = /dev/kmem Kernel virtual memory access
2 = /dev/kmem OBSOLETE - replaced by /proc/kcore
3 = /dev/null Null device
4 = /dev/port I/O port access
5 = /dev/zero Null byte source

11
Documentation/admin-guide/gpio/gpio-mockup.rst
View File

@@ -17,17 +17,18 @@ module.
gpio_mockup_ranges
This parameter takes an argument in the form of an array of integer
pairs. Each pair defines the base GPIO number (if any) and the number
of lines exposed by the chip. If the base GPIO is -1, the gpiolib
will assign it automatically.
pairs. Each pair defines the base GPIO number (non-negative integer)
and the first number after the last of this chip. If the base GPIO
is -1, the gpiolib will assign it automatically. while the following
parameter is the number of lines exposed by the chip.
Example: gpio_mockup_ranges=-1,8,-1,16,405,4
Example: gpio_mockup_ranges=-1,8,-1,16,405,409
The line above creates three chips. The first one will expose 8 lines,
the second 16 and the third 4. The base GPIO for the third chip is set
to 405 while for two first chips it will be assigned automatically.
gpio_named_lines
gpio_mockup_named_lines
This parameter doesn't take any arguments. It lets the driver know that
GPIO lines exposed by it should be named.

164
Documentation/admin-guide/kernel-parameters.txt
View File

@@ -497,16 +497,21 @@
ccw_timeout_log [S390]
See Documentation/s390/common_io.rst for details.
cgroup_disable= [KNL] Disable a particular controller
Format: {name of the controller(s) to disable}
cgroup_disable= [KNL] Disable a particular controller or optional feature
Format: {name of the controller(s) or feature(s) to disable}
The effects of cgroup_disable=foo are:
- foo isn't auto-mounted if you mount all cgroups in
a single hierarchy
- foo isn't visible as an individually mountable
subsystem
- if foo is an optional feature then the feature is
disabled and corresponding cgroup files are not
created
{Currently only "memory" controller deal with this and
cut the overhead, others just disable the usage. So
only cgroup_disable=memory is actually worthy}
Specifying "pressure" disables per-cgroup pressure
stall information accounting feature
cgroup_no_v1= [KNL] Disable cgroup controllers and named hierarchies in v1
Format: { { controller | "all" | "named" }
@@ -1469,6 +1474,12 @@
Don't use this when you are not running on the
android emulator
gpio-mockup.gpio_mockup_ranges
[HW] Sets the ranges of gpiochip of for this device.
Format: <start1>,<end1>,<start2>,<end2>...
gpio-mockup.gpio_mockup_named_lines
[HW] Let the driver know GPIO lines should be named.
gpt [EFI] Forces disk with valid GPT signature but
invalid Protective MBR to be treated as GPT. If the
primary GPT is corrupted, it enables the backup/alternate
@@ -1492,10 +1503,6 @@
Format: <unsigned int> such that (rxsize & ~0x1fffc0) == 0.
Default: 1024
gpio-mockup.gpio_mockup_ranges
[HW] Sets the ranges of gpiochip of for this device.
Format: <start1>,<end1>,<start2>,<end2>...
hardlockup_all_cpu_backtrace=
[KNL] Should the hard-lockup detector generate
backtraces on all cpus.
@@ -1837,6 +1844,18 @@
initcall functions. Useful for debugging built-in
modules and initcalls.
initramfs_async= [KNL]
Format: <bool>
Default: 1
This parameter controls whether the initramfs
image is unpacked asynchronously, concurrently
with devices being probed and
initialized. This should normally just work,
but as a debugging aid, one can get the
historical behaviour of the initramfs
unpacking being completed before device_ and
late_ initcalls.
initrd= [BOOT] Specify the location of the initial ramdisk
initrdmem= [KNL] Specify a physical address and size from which to
@@ -1881,13 +1900,6 @@
bypassed by not enabling DMAR with this option. In
this case, gfx device will use physical address for
DMA.
forcedac [X86-64]
With this option iommu will not optimize to look
for io virtual address below 32-bit forcing dual
address cycle on pci bus for cards supporting greater
than 32-bit addressing. The default is to look
for translation below 32-bit and if not available
then look in the higher range.
strict [Default Off]
With this option on every unmap_single operation will
result in a hardware IOTLB flush operation as opposed
@@ -1976,6 +1988,14 @@
nobypass [PPC/POWERNV]
Disable IOMMU bypass, using IOMMU for PCI devices.
iommu.forcedac= [ARM64, X86] Control IOVA allocation for PCI devices.
Format: { "0" | "1" }
0 - Try to allocate a 32-bit DMA address first, before
falling back to the full range if needed.
1 - Allocate directly from the full usable range,
forcing Dual Address Cycle for PCI cards supporting
greater than 32-bit addressing.
iommu.strict= [ARM64] Configure TLB invalidation behaviour
Format: { "0" | "1" }
0 - Lazy mode.
@@ -2805,7 +2825,24 @@
seconds. Use this parameter to check at some
other rate. 0 disables periodic checking.
memtest= [KNL,X86,ARM,PPC] Enable memtest
memory_hotplug.memmap_on_memory
[KNL,X86,ARM] Boolean flag to enable this feature.
Format: {on | off (default)}
When enabled, runtime hotplugged memory will
allocate its internal metadata (struct pages)
from the hotadded memory which will allow to
hotadd a lot of memory without requiring
additional memory to do so.
This feature is disabled by default because it
has some implication on large (e.g. GB)
allocations in some configurations (e.g. small
memory blocks).
The state of the flag can be read in
/sys/module/memory_hotplug/parameters/memmap_on_memory.
Note that even when enabled, there are a few cases where
the feature is not effective.
memtest= [KNL,X86,ARM,PPC,RISCV] Enable memtest
Format: <integer>
default : 0 <disable>
Specifies the number of memtest passes to be
@@ -3254,6 +3291,8 @@
nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
nohugevmalloc [PPC] Disable kernel huge vmalloc mappings.
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
@@ -3604,6 +3643,96 @@
Currently this function knows 686a and 8231 chips.
Format: [spp|ps2|epp|ecp|ecpepp]
pata_legacy.all= [HW,LIBATA]
Format: <int>
Set to non-zero to probe primary and secondary ISA
port ranges on PCI systems where no PCI PATA device
has been found at either range. Disabled by default.
pata_legacy.autospeed= [HW,LIBATA]
Format: <int>
Set to non-zero if a chip is present that snoops speed
changes. Disabled by default.
pata_legacy.ht6560a= [HW,LIBATA]
Format: <int>
Set to 1, 2, or 3 for HT 6560A on the primary channel,
the secondary channel, or both channels respectively.
Disabled by default.
pata_legacy.ht6560b= [HW,LIBATA]
Format: <int>
Set to 1, 2, or 3 for HT 6560B on the primary channel,
the secondary channel, or both channels respectively.
Disabled by default.
pata_legacy.iordy_mask= [HW,LIBATA]
Format: <int>
IORDY enable mask. Set individual bits to allow IORDY
for the respective channel. Bit 0 is for the first
legacy channel handled by this driver, bit 1 is for
the second channel, and so on. The sequence will often
correspond to the primary legacy channel, the secondary
legacy channel, and so on, but the handling of a PCI
bus and the use of other driver options may interfere
with the sequence. By default IORDY is allowed across
all channels.
pata_legacy.opti82c46x= [HW,LIBATA]
Format: <int>
Set to 1, 2, or 3 for Opti 82c611A on the primary
channel, the secondary channel, or both channels
respectively. Disabled by default.
pata_legacy.opti82c611a= [HW,LIBATA]
Format: <int>
Set to 1, 2, or 3 for Opti 82c465MV on the primary
channel, the secondary channel, or both channels
respectively. Disabled by default.
pata_legacy.pio_mask= [HW,LIBATA]
Format: <int>
PIO mode mask for autospeed devices. Set individual
bits to allow the use of the respective PIO modes.
Bit 0 is for mode 0, bit 1 is for mode 1, and so on.
All modes allowed by default.
pata_legacy.probe_all= [HW,LIBATA]
Format: <int>
Set to non-zero to probe tertiary and further ISA
port ranges on PCI systems. Disabled by default.
pata_legacy.probe_mask= [HW,LIBATA]
Format: <int>
Probe mask for legacy ISA PATA ports. Depending on
platform configuration and the use of other driver
options up to 6 legacy ports are supported: 0x1f0,
0x170, 0x1e8, 0x168, 0x1e0, 0x160, however probing
of individual ports can be disabled by setting the
corresponding bits in the mask to 1. Bit 0 is for
the first port in the list above (0x1f0), and so on.
By default all supported ports are probed.
pata_legacy.qdi= [HW,LIBATA]
Format: <int>
Set to non-zero to probe QDI controllers. By default
set to 1 if CONFIG_PATA_QDI_MODULE, 0 otherwise.
pata_legacy.winbond= [HW,LIBATA]
Format: <int>
Set to non-zero to probe Winbond controllers. Use
the standard I/O port (0x130) if 1, otherwise the
value given is the I/O port to use (typically 0x1b0).
By default set to 1 if CONFIG_PATA_WINBOND_VLB_MODULE,
0 otherwise.
pata_platform.pio_mask= [HW,LIBATA]
Format: <int>
Supported PIO mode mask. Set individual bits to allow
the use of the respective PIO modes. Bit 0 is for
mode 0, bit 1 is for mode 1, and so on. Mode 0 only
allowed by default.
pause_on_oops=
Halt all CPUs after the first oops has been printed for
the specified number of seconds. This is to be used if
@@ -4910,6 +5039,10 @@
slram= [HW,MTD]
slab_merge [MM]
Enable merging of slabs with similar size when the
kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
slab_nomerge [MM]
Disable merging of slabs with similar size. May be
necessary if there is some reason to distinguish
@@ -4957,6 +5090,9 @@
lower than slub_max_order.
For more information see Documentation/vm/slub.rst.
slub_merge [MM, SLUB]
Same with slab_merge.
slub_nomerge [MM, SLUB]
Same with slab_nomerge. This is supported for legacy.
See slab_nomerge for more information.

9
Documentation/admin-guide/mm/memory-hotplug.rst
View File

@@ -357,6 +357,15 @@ creates ZONE_MOVABLE as following.
Unfortunately, there is no information to show which memory block belongs
to ZONE_MOVABLE. This is TBD.
.. note::
Techniques that rely on long-term pinnings of memory (especially, RDMA and
vfio) are fundamentally problematic with ZONE_MOVABLE and, therefore, memory
hot remove. Pinned pages cannot reside on ZONE_MOVABLE, to guarantee that
memory can still get hot removed - be aware that pinning can fail even if
there is plenty of free memory in ZONE_MOVABLE. In addition, using
ZONE_MOVABLE might make page pinning more expensive, because pages have to be
migrated off that zone first.
.. _memory_hotplug_how_to_offline_memory:
How to offline memory

2
Documentation/admin-guide/mm/transhuge.rst
View File

@@ -402,7 +402,7 @@ compact_fail
but failed.
It is possible to establish how long the stalls were using the function
tracer to record how long was spent in __alloc_pages_nodemask and
tracer to record how long was spent in __alloc_pages() and
using the mm_page_alloc tracepoint to identify which allocations were
for huge pages.

99
Documentation/admin-guide/mm/userfaultfd.rst
View File

@@ -63,36 +63,36 @@ the generic ioctl available.
The ``uffdio_api.features`` bitmask returned by the ``UFFDIO_API`` ioctl
defines what memory types are supported by the ``userfaultfd`` and what
events, except page fault notifications, may be generated.
events, except page fault notifications, may be generated:
If the kernel supports registering ``userfaultfd`` ranges on hugetlbfs
virtual memory areas, ``UFFD_FEATURE_MISSING_HUGETLBFS`` will be set in
``uffdio_api.features``. Similarly, ``UFFD_FEATURE_MISSING_SHMEM`` will be
set if the kernel supports registering ``userfaultfd`` ranges on shared
memory (covering all shmem APIs, i.e. tmpfs, ``IPCSHM``, ``/dev/zero``,
``MAP_SHARED``, ``memfd_create``, etc).
- The ``UFFD_FEATURE_EVENT_*`` flags indicate that various other events
other than page faults are supported. These events are described in more
detail below in the `Non-cooperative userfaultfd`_ section.
The userland application that wants to use ``userfaultfd`` with hugetlbfs
or shared memory need to set the corresponding flag in
``uffdio_api.features`` to enable those features.
- ``UFFD_FEATURE_MISSING_HUGETLBFS`` and ``UFFD_FEATURE_MISSING_SHMEM``
indicate that the kernel supports ``UFFDIO_REGISTER_MODE_MISSING``
registrations for hugetlbfs and shared memory (covering all shmem APIs,
i.e. tmpfs, ``IPCSHM``, ``/dev/zero``, ``MAP_SHARED``, ``memfd_create``,
etc) virtual memory areas, respectively.
If the userland desires to receive notifications for events other than
page faults, it has to verify that ``uffdio_api.features`` has appropriate
``UFFD_FEATURE_EVENT_*`` bits set. These events are described in more
detail below in `Non-cooperative userfaultfd`_ section.
- ``UFFD_FEATURE_MINOR_HUGETLBFS`` indicates that the kernel supports
``UFFDIO_REGISTER_MODE_MINOR`` registration for hugetlbfs virtual memory
areas.
Once the ``userfaultfd`` has been enabled the ``UFFDIO_REGISTER`` ioctl should
be invoked (if present in the returned ``uffdio_api.ioctls`` bitmask) to
register a memory range in the ``userfaultfd`` by setting the
The userland application should set the feature flags it intends to use
when invoking the ``UFFDIO_API`` ioctl, to request that those features be
enabled if supported.
Once the ``userfaultfd`` API has been enabled the ``UFFDIO_REGISTER``
ioctl should be invoked (if present in the returned ``uffdio_api.ioctls``
bitmask) to register a memory range in the ``userfaultfd`` by setting the
uffdio_register structure accordingly. The ``uffdio_register.mode``
bitmask will specify to the kernel which kind of faults to track for
the range (``UFFDIO_REGISTER_MODE_MISSING`` would track missing
pages). The ``UFFDIO_REGISTER`` ioctl will return the
the range. The ``UFFDIO_REGISTER`` ioctl will return the
``uffdio_register.ioctls`` bitmask of ioctls that are suitable to resolve
userfaults on the range registered. Not all ioctls will necessarily be
supported for all memory types depending on the underlying virtual
memory backend (anonymous memory vs tmpfs vs real filebacked
mappings).
supported for all memory types (e.g. anonymous memory vs. shmem vs.
hugetlbfs), or all types of intercepted faults.
Userland can use the ``uffdio_register.ioctls`` to manage the virtual
address space in the background (to add or potentially also remove
@@ -100,21 +100,46 @@ memory from the ``userfaultfd`` registered range). This means a userfault
could be triggering just before userland maps in the background the
user-faulted page.
The primary ioctl to resolve userfaults is ``UFFDIO_COPY``. That
atomically copies a page into the userfault registered range and wakes
up the blocked userfaults
(unless ``uffdio_copy.mode & UFFDIO_COPY_MODE_DONTWAKE`` is set).
Other ioctl works similarly to ``UFFDIO_COPY``. They're atomic as in
guaranteeing that nothing can see an half copied page since it'll
keep userfaulting until the copy has finished.
Resolving Userfaults
--------------------
There are three basic ways to resolve userfaults:
- ``UFFDIO_COPY`` atomically copies some existing page contents from
userspace.
- ``UFFDIO_ZEROPAGE`` atomically zeros the new page.
- ``UFFDIO_CONTINUE`` maps an existing, previously-populated page.
These operations are atomic in the sense that they guarantee nothing can
see a half-populated page, since readers will keep userfaulting until the
operation has finished.
By default, these wake up userfaults blocked on the range in question.
They support a ``UFFDIO_*_MODE_DONTWAKE`` ``mode`` flag, which indicates
that waking will be done separately at some later time.
Which ioctl to choose depends on the kind of page fault, and what we'd
like to do to resolve it:
- For ``UFFDIO_REGISTER_MODE_MISSING`` faults, the fault needs to be
resolved by either providing a new page (``UFFDIO_COPY``), or mapping
the zero page (``UFFDIO_ZEROPAGE``). By default, the kernel would map
the zero page for a missing fault. With userfaultfd, userspace can
decide what content to provide before the faulting thread continues.
- For ``UFFDIO_REGISTER_MODE_MINOR`` faults, there is an existing page (in
the page cache). Userspace has the option of modifying the page's
contents before resolving the fault. Once the contents are correct
(modified or not), userspace asks the kernel to map the page and let the
faulting thread continue with ``UFFDIO_CONTINUE``.
Notes:
- If you requested ``UFFDIO_REGISTER_MODE_MISSING`` when registering then
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 anonymous mmaping is not in place.
- You can tell which kind of fault occurred by examining
``pagefault.flags`` within the ``uffd_msg``, checking for the
``UFFD_PAGEFAULT_FLAG_*`` flags.
- None of the page-delivering ioctls default to the range that you
registered with. You must fill in all fields for the appropriate
@@ -122,9 +147,9 @@ Notes:
- You get the address of the access that triggered the missing page
event out of a struct uffd_msg that you read in the thread from the
uffd. You can supply as many pages as you want with ``UFFDIO_COPY`` or
``UFFDIO_ZEROPAGE``. Keep in mind that unless you used DONTWAKE then
the first of any of those IOCTLs wakes up the faulting thread.
uffd. You can supply as many pages as you want with these IOCTLs.
Keep in mind that unless you used DONTWAKE then the first of any of
those IOCTLs wakes up the faulting thread.
- Be sure to test for all errors including
(``pollfd[0].revents & POLLERR``). This can happen, e.g. when ranges

49
Documentation/admin-guide/reporting-issues.rst
View File

@@ -24,7 +24,8 @@ longterm series? One still supported? Then search the `LKML
you don't find any, install `the latest release from that series
<https://kernel.org/>`_. If it still shows the issue, report it to the stable
mailing list (stable@vger.kernel.org) and CC the regressions list
(regressions@lists.linux.dev).
(regressions@lists.linux.dev); ideally also CC the maintainer and the mailing
list for the subsystem in question.
In all other cases try your best guess which kernel part might be causing the
issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
@@ -48,8 +49,9 @@ before the issue occurs.
If you are facing multiple issues with the Linux kernel at once, report each
separately. While writing your report, include all information relevant to the
issue, like the kernel and the distro used. In case of a regression, CC the
regressions mailing list (regressions@lists.linux.dev) to your report; also try
to include the commit-id of the change causing it, which a bisection can find.
regressions mailing list (regressions@lists.linux.dev) to your report. Also try
to pin-point the culprit with a bisection; if you succeed, include its
commit-id and CC everyone in the sign-off-by chain.
Once the report is out, answer any questions that come up and help where you
can. That includes keeping the ball rolling by occasionally retesting with newer
@@ -198,10 +200,11 @@ report them:
* Send a short problem report to the Linux stable mailing list
(stable@vger.kernel.org) and CC the Linux regressions mailing list
(regressions@lists.linux.dev). Roughly describe the issue and ideally
explain how to reproduce it. Mention the first version that shows the
problem and the last version that's working fine. Then wait for further
instructions.
(regressions@lists.linux.dev); if you suspect the cause in a particular
subsystem, CC its maintainer and its mailing list. Roughly describe the
issue and ideally explain how to reproduce it. Mention the first version
that shows the problem and the last version that's working fine. Then
wait for further instructions.
The reference section below explains each of these steps in more detail.
@@ -768,7 +771,9 @@ regular internet search engine and add something like
the results to the archives at that URL.
It's also wise to check the internet, LKML and maybe bugzilla.kernel.org again
at this point.
at this point. If your report needs to be filed in a bug tracker, you may want
to check the mailing list archives for the subsystem as well, as someone might
have reported it only there.
For details how to search and what to do if you find matching reports see
"Search for existing reports, first run" above.
@@ -1249,9 +1254,10 @@ and the oldest where the issue occurs (say 5.8-rc1).
When sending the report by mail, CC the Linux regressions mailing list
(regressions@lists.linux.dev). In case the report needs to be filed to some web
tracker, proceed to do so; once filed, forward the report by mail to the
regressions list. Make sure to inline the forwarded report, hence do not attach
it. Also add a short note at the top where you mention the URL to the ticket.
tracker, proceed to do so. Once filed, forward the report by mail to the
regressions list; CC the maintainer and the mailing list for the subsystem in
question. Make sure to inline the forwarded report, hence do not attach it.
Also add a short note at the top where you mention the URL to the ticket.
When mailing or forwarding the report, in case of a successful bisection add the
author of the culprit to the recipients; also CC everyone in the signed-off-by
@@ -1536,17 +1542,20 @@ Report the regression
*Send a short problem report to the Linux stable mailing list
(stable@vger.kernel.org) and CC the Linux regressions mailing list
(regressions@lists.linux.dev). Roughly describe the issue and ideally
explain how to reproduce it. Mention the first version that shows the
problem and the last version that's working fine. Then wait for further
instructions.*
(regressions@lists.linux.dev); if you suspect the cause in a particular
subsystem, CC its maintainer and its mailing list. Roughly describe the
issue and ideally explain how to reproduce it. Mention the first version
that shows the problem and the last version that's working fine. Then
wait for further instructions.*
When reporting a regression that happens within a stable or longterm kernel
line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for
the start to get the issue reported quickly. Hence a rough description is all
it takes.
the start to get the issue reported quickly. Hence a rough description to the
stable and regressions mailing list is all it takes; but in case you suspect
the cause in a particular subsystem, CC its maintainers and its mailing list
as well, because that will speed things up.
But note, it helps developers a great deal if you can specify the exact version
And note, it helps developers a great deal if you can specify the exact version
that introduced the problem. Hence if possible within a reasonable time frame,
try to find that version using vanilla kernels. Lets assume something broke when
your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as
@@ -1563,7 +1572,9 @@ pinpoint the exact change that causes the issue (which then can easily get
reverted to fix the issue quickly). Hence consider to do a proper bisection
right away if time permits. See the section 'Special care for regressions' and
the document 'Documentation/admin-guide/bug-bisect.rst' for details how to
perform one.
perform one. In case of a successful bisection add the author of the culprit to
the recipients; also CC everyone in the signed-off-by chain, which you find at
the end of its commit message.
Reference for "Reporting issues only occurring in older kernel version lines"

26
Documentation/admin-guide/sysctl/kernel.rst
View File

@@ -483,10 +483,11 @@ modprobe
========
The full path to the usermode helper for autoloading kernel modules,
by default "/sbin/modprobe". This binary is executed when the kernel
requests a module. For example, if userspace passes an unknown
filesystem type to mount(), then the kernel will automatically request
the corresponding filesystem module by executing this usermode helper.
by default ``CONFIG_MODPROBE_PATH``, which in turn defaults to
"/sbin/modprobe". This binary is executed when the kernel requests a
module. For example, if userspace passes an unknown filesystem type
to mount(), then the kernel will automatically request the
corresponding filesystem module by executing this usermode helper.
This usermode helper should insert the needed module into the kernel.
This sysctl only affects module autoloading. It has no effect on the
@@ -1457,11 +1458,22 @@ unprivileged_bpf_disabled
=========================
Writing 1 to this entry will disable unprivileged calls to ``bpf()``;
once disabled, calling ``bpf()`` without ``CAP_SYS_ADMIN`` will return
``-EPERM``.
once disabled, calling ``bpf()`` without ``CAP_SYS_ADMIN`` or ``CAP_BPF``
will return ``-EPERM``. Once set to 1, this can't be cleared from the
running kernel anymore.
Once set, this can't be cleared.
Writing 2 to this entry will also disable unprivileged calls to ``bpf()``,
however, an admin can still change this setting later on, if needed, by
writing 0 or 1 to this entry.
If ``BPF_UNPRIV_DEFAULT_OFF`` is enabled in the kernel config, then this
entry will default to 2 instead of 0.
= =============================================================
0 Unprivileged calls to ``bpf()`` are enabled
1 Unprivileged calls to ``bpf()`` are disabled without recovery
2 Unprivileged calls to ``bpf()`` are disabled
= =============================================================
watchdog
========

13
Documentation/admin-guide/sysctl/net.rst
View File

@@ -64,6 +64,7 @@ two flavors of JITs, the newer eBPF JIT currently supported on:
- arm64
- arm32
- ppc64
- ppc32
- sparc64
- mips64
- s390x
@@ -73,7 +74,6 @@ two flavors of JITs, the newer eBPF JIT currently supported on:
And the older cBPF JIT supported on the following archs:
- mips
- ppc
- sparc
eBPF JITs are a superset of cBPF JITs, meaning the kernel will
@@ -311,6 +311,17 @@ permit to distribute the load on several cpus.
If set to 1 (default), timestamps are sampled as soon as possible, before
queueing.
netdev_unregister_timeout_secs
------------------------------
Unregister network device timeout in seconds.
This option controls the timeout (in seconds) used to issue a warning while
waiting for a network device refcount to drop to 0 during device
unregistration. A lower value may be useful during bisection to detect
a leaked reference faster. A larger value may be useful to prevent false
warnings on slow/loaded systems.
Default value is 10, minimum 1, maximum 3600.
optmem_max
----------

2
Documentation/admin-guide/xfs.rst
View File

@@ -522,7 +522,7 @@ and the short name of the data device. They all can be found in:
================ ===========
xfs_iwalk-$pid Inode scans of the entire filesystem. Currently limited to
mount time quotacheck.
xfs-blockgc Background garbage collection of disk space that have been
xfs-gc Background garbage collection of disk space that have been
speculatively allocated beyond EOF or for staging copy on
write operations.
================ ===========

33
Documentation/arm64/booting.rst
View File

@@ -277,9 +277,40 @@ Before jumping into the kernel, the following conditions must be met:
- SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
For CPUs with Advanced SIMD and floating point support:
- If EL3 is present:
- CPTR_EL3.TFP (bit 10) must be initialised to 0b0.
- If EL2 is present and the kernel is entered at EL1:
- CPTR_EL2.TFP (bit 10) must be initialised to 0b0.
For CPUs with the Scalable Vector Extension (FEAT_SVE) present:
- if EL3 is present:
- CPTR_EL3.EZ (bit 8) must be initialised to 0b1.
- ZCR_EL3.LEN must be initialised to the same value for all CPUs the
kernel is executed on.
- If the kernel is entered at EL1 and EL2 is present:
- CPTR_EL2.TZ (bit 8) must be initialised to 0b0.
- CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11.
- ZCR_EL2.LEN must be initialised to the same value for all CPUs the
kernel will execute on.
The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must
enter the kernel in the same exception level.
enter the kernel in the same exception level. Where the values documented
disable traps it is permissible for these traps to be enabled so long as
those traps are handled transparently by higher exception levels as though
the values documented were set.
The boot loader is expected to enter the kernel on each CPU in the
following manner:

2
Documentation/arm64/elf_hwcaps.rst
View File

@@ -74,7 +74,7 @@ HWCAP_ASIMD
HWCAP_EVTSTRM
The generic timer is configured to generate events at a frequency of
approximately 100KHz.
approximately 10KHz.
HWCAP_AES
Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001.

6
Documentation/arm64/tagged-address-abi.rst
View File

@@ -113,6 +113,12 @@ ABI relaxation:
- ``shmat()`` and ``shmdt()``.
- ``brk()`` (since kernel v5.6).
- ``mmap()`` (since kernel v5.6).
- ``mremap()``, the ``new_address`` argument (since kernel v5.6).
Any attempt to use non-zero tagged pointers may result in an error code
being returned, a (fatal) signal being raised, or other modes of
failure.

2
Documentation/block/data-integrity.rst
View File

@@ -1,4 +1,4 @@
==============
==============
Data Integrity
==============

15
Documentation/bpf/bpf_design_QA.rst
View File

@@ -258,3 +258,18 @@ Q: Can BPF functionality such as new program or map types, new
helpers, etc be added out of kernel module code?
A: NO.
Q: Directly calling kernel function is an ABI?
----------------------------------------------
Q: Some kernel functions (e.g. tcp_slow_start) can be called
by BPF programs. Do these kernel functions become an ABI?
A: NO.
The kernel function protos will change and the bpf programs will be
rejected by the verifier. Also, for example, some of the bpf-callable
kernel functions have already been used by other kernel tcp
cc (congestion-control) implementations. If any of these kernel
functions has changed, both the in-tree and out-of-tree kernel tcp cc
implementations have to be changed. The same goes for the bpf
programs and they have to be adjusted accordingly.

30
Documentation/bpf/bpf_devel_QA.rst
View File

@@ -29,7 +29,7 @@ list:
This may also include issues related to XDP, BPF tracing, etc.
Given netdev has a high volume of traffic, please also add the BPF
maintainers to Cc (from kernel MAINTAINERS_ file):
maintainers to Cc (from kernel ``MAINTAINERS`` file):
* Alexei Starovoitov <ast@kernel.org>
* Daniel Borkmann <daniel@iogearbox.net>
@@ -234,11 +234,11 @@ be subject to change.
Q: samples/bpf preference vs selftests?
---------------------------------------
Q: When should I add code to `samples/bpf/`_ and when to BPF kernel
selftests_ ?
Q: When should I add code to ``samples/bpf/`` and when to BPF kernel
selftests_?
A: In general, we prefer additions to BPF kernel selftests_ rather than
`samples/bpf/`_. The rationale is very simple: kernel selftests are
``samples/bpf/``. The rationale is very simple: kernel selftests are
regularly run by various bots to test for kernel regressions.
The more test cases we add to BPF selftests, the better the coverage
@@ -246,9 +246,9 @@ and the less likely it is that those could accidentally break. It is
not that BPF kernel selftests cannot demo how a specific feature can
be used.
That said, `samples/bpf/`_ may be a good place for people to get started,
That said, ``samples/bpf/`` may be a good place for people to get started,
so it might be advisable that simple demos of features could go into
`samples/bpf/`_, but advanced functional and corner-case testing rather
``samples/bpf/``, but advanced functional and corner-case testing rather
into kernel selftests.
If your sample looks like a test case, then go for BPF kernel selftests
@@ -449,6 +449,19 @@ from source at
https://github.com/acmel/dwarves
pahole starts to use libbpf definitions and APIs since v1.13 after the
commit 21507cd3e97b ("pahole: add libbpf as submodule under lib/bpf").
It works well with the git repository because the libbpf submodule will
use "git submodule update --init --recursive" to update.
Unfortunately, the default github release source code does not contain
libbpf submodule source code and this will cause build issues, the tarball
from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ is same with
github, you can get the source tarball with corresponding libbpf submodule
codes from
https://fedorapeople.org/~acme/dwarves
Some distros have pahole version 1.16 packaged already, e.g.
Fedora, Gentoo.
@@ -645,10 +658,9 @@ when:
.. Links
.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
.. _MAINTAINERS: ../../MAINTAINERS
.. _netdev-FAQ: ../networking/netdev-FAQ.rst
.. _samples/bpf/: ../../samples/bpf/
.. _selftests: ../../tools/testing/selftests/bpf/
.. _selftests:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
.. _Documentation/dev-tools/kselftest.rst:
https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
.. _Documentation/bpf/btf.rst: btf.rst

17
Documentation/bpf/btf.rst
View File

@@ -84,6 +84,7 @@ sequentially and type id is assigned to each recognized type starting from id
#define BTF_KIND_FUNC_PROTO 13 /* Function Proto */
#define BTF_KIND_VAR 14 /* Variable */
#define BTF_KIND_DATASEC 15 /* Section */
#define BTF_KIND_FLOAT 16 /* Floating point */
Note that the type section encodes debug info, not just pure types.
``BTF_KIND_FUNC`` is not a type, and it represents a defined subprogram.
@@ -95,8 +96,8 @@ Each type contains the following common data::
/* "info" bits arrangement
* bits 0-15: vlen (e.g. # of struct's members)
* bits 16-23: unused
* bits 24-27: kind (e.g. int, ptr, array...etc)
* bits 28-30: unused
* bits 24-28: kind (e.g. int, ptr, array...etc)
* bits 29-30: unused
* bit 31: kind_flag, currently used by
* struct, union and fwd
*/
@@ -452,6 +453,18 @@ map definition.
* ``offset``: the in-section offset of the variable
* ``size``: the size of the variable in bytes
2.2.16 BTF_KIND_FLOAT
~~~~~~~~~~~~~~~~~~~~~
``struct btf_type`` encoding requirement:
* ``name_off``: any valid offset
* ``info.kind_flag``: 0
* ``info.kind``: BTF_KIND_FLOAT
* ``info.vlen``: 0
* ``size``: the size of the float type in bytes: 2, 4, 8, 12 or 16.
No additional type data follow ``btf_type``.
3. BTF Kernel API
*****************

9
Documentation/bpf/index.rst
View File

@@ -12,9 +12,6 @@ BPF instruction-set.
The Cilium project also maintains a `BPF and XDP Reference Guide`_
that goes into great technical depth about the BPF Architecture.
The primary info for the bpf syscall is available in the `man-pages`_
for `bpf(2)`_.
BPF Type Format (BTF)
=====================
@@ -35,6 +32,12 @@ Two sets of Questions and Answers (Q&A) are maintained.
bpf_design_QA
bpf_devel_QA
Syscall API
===========
The primary info for the bpf syscall is available in the `man-pages`_
for `bpf(2)`_. For more information about the userspace API, see
Documentation/userspace-api/ebpf/index.rst.
Helper functions
================

30
Documentation/cdrom/cdrom-standard.rst
View File

@@ -146,18 +146,18 @@ with the kernel as a block device by registering the following general
*struct file_operations*::
struct file_operations cdrom_fops = {
NULL, /∗ lseek ∗/
block _read , /∗ read—general block-dev read ∗/
block _write, /∗ write—general block-dev write ∗/
NULL, /∗ readdir ∗/
NULL, /∗ select ∗/
cdrom_ioctl, /∗ ioctl ∗/
NULL, /∗ mmap ∗/
cdrom_open, /∗ open ∗/
cdrom_release, /∗ release ∗/
NULL, /∗ fsync ∗/
NULL, /∗ fasync ∗/
NULL /∗ revalidate ∗/
NULL, /* lseek */
block _read , /* read--general block-dev read */
block _write, /* write--general block-dev write */
NULL, /* readdir */
NULL, /* select */
cdrom_ioctl, /* ioctl */
NULL, /* mmap */
cdrom_open, /* open */
cdrom_release, /* release */
NULL, /* fsync */
NULL, /* fasync */
NULL /* revalidate */
};
Every active CD-ROM device shares this *struct*. The routines
@@ -250,12 +250,12 @@ The drive-specific, minor-like information that is registered with
`cdrom.c`, currently contains the following fields::
struct cdrom_device_info {
const struct cdrom_device_ops * ops; /* device operations for this major */
const struct cdrom_device_ops * ops; /* device operations for this major */
struct list_head list; /* linked list of all device_info */
struct gendisk * disk; /* matching block layer disk */
void * handle; /* driver-dependent data */
int mask; /* mask of capability: disables them */
int mask; /* mask of capability: disables them */
int speed; /* maximum speed for reading data */
int capacity; /* number of discs in a jukebox */
@@ -569,7 +569,7 @@ the *CDC_CLOSE_TRAY* bit in *mask*.
In the file `cdrom.c` you will encounter many constructions of the type::
if (cdo->capability & ∼cdi->mask & CDC _⟨capability⟩) ...
if (cdo->capability & ~cdi->mask & CDC _<capability>) ...
There is no *ioctl* to set the mask... The reason is that
I think it is better to control the **behavior** rather than the

4
Documentation/core-api/cachetlb.rst
View File

@@ -213,9 +213,9 @@ Here are the routines, one by one:
there will be no entries in the cache for the kernel address
space for virtual addresses in the range 'start' to 'end-1'.
The first of these two routines is invoked after map_kernel_range()
The first of these two routines is invoked after vmap_range()
has installed the page table entries. The second is invoked
before unmap_kernel_range() deletes the page table entries.
before vunmap_range() deletes the page table entries.
There exists another whole class of cpu cache issues which currently
require a whole different set of interfaces to handle properly.

88
Documentation/core-api/dma-api.rst
View File

@@ -563,6 +563,16 @@ Free a region of memory previously allocated using dma_alloc_pages().
dev, size, dma_handle and dir must all be the same as those passed into
dma_alloc_pages(). page must be the pointer returned by dma_alloc_pages().
::
int
dma_mmap_pages(struct device *dev, struct vm_area_struct *vma,
size_t size, struct page *page)
Map an allocation returned from dma_alloc_pages() into a user address space.
dev and size must be the same as those passed into dma_alloc_pages().
page must be the pointer returned by dma_alloc_pages().
::
void *
@@ -584,6 +594,84 @@ dev, size, dma_handle and dir must all be the same as those passed into
dma_alloc_noncoherent(). cpu_addr must be the virtual address returned by
dma_alloc_noncoherent().
::
struct sg_table *
dma_alloc_noncontiguous(struct device *dev, size_t size,
enum dma_data_direction dir, gfp_t gfp,
unsigned long attrs);
This routine allocates <size> bytes of non-coherent and possibly non-contiguous
memory. It returns a pointer to struct sg_table that describes the allocated
and DMA mapped memory, or NULL if the allocation failed. The resulting memory
can be used for struct page mapped into a scatterlist are suitable for.
The return sg_table is guaranteed to have 1 single DMA mapped segment as
indicated by sgt->nents, but it might have multiple CPU side segments as
indicated by sgt->orig_nents.
The dir parameter specified if data is read and/or written by the device,
see dma_map_single() for details.
The gfp parameter allows the caller to specify the ``GFP_`` flags (see
kmalloc()) for the allocation, but rejects flags used to specify a memory
zone such as GFP_DMA or GFP_HIGHMEM.
The attrs argument must be either 0 or DMA_ATTR_ALLOC_SINGLE_PAGES.
Before giving the memory to the device, dma_sync_sgtable_for_device() needs
to be called, and before reading memory written by the device,
dma_sync_sgtable_for_cpu(), just like for streaming DMA mappings that are
reused.
::
void
dma_free_noncontiguous(struct device *dev, size_t size,
struct sg_table *sgt,
enum dma_data_direction dir)
Free memory previously allocated using dma_alloc_noncontiguous(). dev, size,
and dir must all be the same as those passed into dma_alloc_noncontiguous().
sgt must be the pointer returned by dma_alloc_noncontiguous().
::
void *
dma_vmap_noncontiguous(struct device *dev, size_t size,
struct sg_table *sgt)
Return a contiguous kernel mapping for an allocation returned from
dma_alloc_noncontiguous(). dev and size must be the same as those passed into
dma_alloc_noncontiguous(). sgt must be the pointer returned by
dma_alloc_noncontiguous().
Once a non-contiguous allocation is mapped using this function, the
flush_kernel_vmap_range() and invalidate_kernel_vmap_range() APIs must be used
to manage the coherency between the kernel mapping, the device and user space
mappings (if any).
::
void
dma_vunmap_noncontiguous(struct device *dev, void *vaddr)
Unmap a kernel mapping returned by dma_vmap_noncontiguous(). dev must be the
same the one passed into dma_alloc_noncontiguous(). vaddr must be the pointer
returned by dma_vmap_noncontiguous().
::
int
dma_mmap_noncontiguous(struct device *dev, struct vm_area_struct *vma,
size_t size, struct sg_table *sgt)
Map an allocation returned from dma_alloc_noncontiguous() into a user address
space. dev and size must be the same as those passed into
dma_alloc_noncontiguous(). sgt must be the pointer returned by
dma_alloc_noncontiguous().
::
int

22
Documentation/core-api/irq/irq-domain.rst
View File

@@ -42,10 +42,10 @@ irq_domain usage
================
An interrupt controller driver creates and registers an irq_domain by
calling one of the irq_domain_add_*() functions (each mapping method
has a different allocator function, more on that later). The function
will return a pointer to the irq_domain on success. The caller must
provide the allocator function with an irq_domain_ops structure.
calling one of the irq_domain_add_*() or irq_domain_create_*() functions
(each mapping method has a different allocator function, more on that later).
The function will return a pointer to the irq_domain on success. The caller
must provide the allocator function with an irq_domain_ops structure.
In most cases, the irq_domain will begin empty without any mappings
between hwirq and IRQ numbers. Mappings are added to the irq_domain
@@ -147,6 +147,7 @@ Legacy
irq_domain_add_simple()
irq_domain_add_legacy()
irq_domain_add_legacy_isa()
irq_domain_create_simple()
irq_domain_create_legacy()
The Legacy mapping is a special case for drivers that already have a
@@ -169,13 +170,13 @@ supported. For example, ISA controllers would use the legacy map for
mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
numbers.
Most users of legacy mappings should use irq_domain_add_simple() which
will use a legacy domain only if an IRQ range is supplied by the
system and will otherwise use a linear domain mapping. The semantics
of this call are such that if an IRQ range is specified then
Most users of legacy mappings should use irq_domain_add_simple() or
irq_domain_create_simple() which will use a legacy domain only if an IRQ range
is supplied by the system and will otherwise use a linear domain mapping.
The semantics of this call are such that if an IRQ range is specified then
descriptors will be allocated on-the-fly for it, and if no range is
specified it will fall through to irq_domain_add_linear() which means
*no* irq descriptors will be allocated.
specified it will fall through to irq_domain_add_linear() or
irq_domain_create_linear() which means *no* irq descriptors will be allocated.
A typical use case for simple domains is where an irqchip provider
is supporting both dynamic and static IRQ assignments.
@@ -186,6 +187,7 @@ that the driver using the simple domain call irq_create_mapping()
before any irq_find_mapping() since the latter will actually work
for the static IRQ assignment case.
irq_domain_add_simple() and irq_domain_create_simple() as well as
irq_domain_add_legacy() and irq_domain_create_legacy() are functionally
equivalent, except for the first argument is different - the former
accepts an Open Firmware specific 'struct device_node', while the latter

6
Documentation/core-api/mm-api.rst
View File

@@ -92,3 +92,9 @@ More Memory Management Functions
:export:
.. kernel-doc:: mm/page_alloc.c
.. kernel-doc:: mm/mempolicy.c
.. kernel-doc:: include/linux/mm_types.h
:internal:
.. kernel-doc:: include/linux/mm.h
:internal:
.. kernel-doc:: include/linux/mmzone.h

26
Documentation/core-api/symbol-namespaces.rst
View File

@@ -43,14 +43,14 @@ exporting of kernel symbols to the kernel symbol table, variants of these are
available to export symbols into a certain namespace: EXPORT_SYMBOL_NS() and
EXPORT_SYMBOL_NS_GPL(). They take one additional argument: the namespace.
Please note that due to macro expansion that argument needs to be a
preprocessor symbol. E.g. to export the symbol `usb_stor_suspend` into the
namespace `USB_STORAGE`, use::
preprocessor symbol. E.g. to export the symbol ``usb_stor_suspend`` into the
namespace ``USB_STORAGE``, use::
EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE);
The corresponding ksymtab entry struct `kernel_symbol` will have the member
`namespace` set accordingly. A symbol that is exported without a namespace will
refer to `NULL`. There is no default namespace if none is defined. `modpost`
The corresponding ksymtab entry struct ``kernel_symbol`` will have the member
``namespace`` set accordingly. A symbol that is exported without a namespace will
refer to ``NULL``. There is no default namespace if none is defined. ``modpost``
and kernel/module.c make use the namespace at build time or module load time,
respectively.
@@ -64,7 +64,7 @@ and EXPORT_SYMBOL_GPL() macro expansions that do not specify a namespace.
There are multiple ways of specifying this define and it depends on the
subsystem and the maintainer's preference, which one to use. The first option
is to define the default namespace in the `Makefile` of the subsystem. E.g. to
is to define the default namespace in the ``Makefile`` of the subsystem. E.g. to
export all symbols defined in usb-common into the namespace USB_COMMON, add a
line like this to drivers/usb/common/Makefile::
@@ -96,7 +96,7 @@ using a statement like::
MODULE_IMPORT_NS(USB_STORAGE);
This will create a `modinfo` tag in the module for each imported namespace.
This will create a ``modinfo`` tag in the module for each imported namespace.
This has the side effect, that the imported namespaces of a module can be
inspected with modinfo::
@@ -113,7 +113,7 @@ metadata definitions like MODULE_AUTHOR() or MODULE_LICENSE(). Refer to section
4. Loading Modules that use namespaced Symbols
==============================================
At module loading time (e.g. `insmod`), the kernel will check each symbol
At module loading time (e.g. ``insmod``), the kernel will check each symbol
referenced from the module for its availability and whether the namespace it
might be exported to has been imported by the module. The default behaviour of
the kernel is to reject loading modules that don't specify sufficient imports.
@@ -138,19 +138,19 @@ missing imports. Fixing missing imports can be done with::
A typical scenario for module authors would be::
- write code that depends on a symbol from a not imported namespace
- `make`
- ``make``
- notice the warning of modpost telling about a missing import
- run `make nsdeps` to add the import to the correct code location
- run ``make nsdeps`` to add the import to the correct code location
For subsystem maintainers introducing a namespace, the steps are very similar.
Again, `make nsdeps` will eventually add the missing namespace imports for
Again, ``make nsdeps`` will eventually add the missing namespace imports for
in-tree modules::
- move or add symbols to a namespace (e.g. with EXPORT_SYMBOL_NS())
- `make` (preferably with an allmodconfig to cover all in-kernel
- ``make`` (preferably with an allmodconfig to cover all in-kernel
modules)
- notice the warning of modpost telling about a missing import
- run `make nsdeps` to add the import to the correct code location
- run ``make nsdeps`` to add the import to the correct code location
You can also run nsdeps for external module builds. A typical usage is::

2
Documentation/dev-tools/gdb-kernel-debugging.rst
View File

@@ -114,7 +114,7 @@ Examples of using the Linux-provided gdb helpers
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
....
- Examine fields of the current task struct::
- Examine fields of the current task struct(supported by x86 and arm64 only)::
(gdb) p $lx_current().pid
$1 = 4998

347
Documentation/dev-tools/kasan.rst
View File

@@ -11,46 +11,56 @@ designed to find out-of-bound and use-after-free bugs. KASAN has three modes:
2. software tag-based KASAN (similar to userspace HWASan),
3. hardware tag-based KASAN (based on hardware memory tagging).
Software KASAN modes (1 and 2) use compile-time instrumentation to insert
validity checks before every memory access, and therefore require a compiler
Generic KASAN is mainly used for debugging due to a large memory overhead.
Software tag-based KASAN can be used for dogfood testing as it has a lower
memory overhead that allows using it with real workloads. Hardware tag-based
KASAN comes with low memory and performance overheads and, therefore, can be
used in production. Either as an in-field memory bug detector or as a security
mitigation.
Software KASAN modes (#1 and #2) use compile-time instrumentation to insert
validity checks before every memory access and, therefore, require a compiler
version that supports that.
Generic KASAN is supported in both GCC and Clang. With GCC it requires version
Generic KASAN is supported in GCC and Clang. With GCC, it requires version
8.3.0 or later. Any supported Clang version is compatible, but detection of
out-of-bounds accesses for global variables is only supported since Clang 11.
Tag-based KASAN is only supported in Clang.
Software tag-based KASAN mode is only supported in Clang.
Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and
riscv architectures, and tag-based KASAN is supported only for arm64.
The hardware KASAN mode (#3) relies on hardware to perform the checks but
still requires a compiler version that supports memory tagging instructions.
This mode is supported in GCC 10+ and Clang 11+.
Both software KASAN modes work with SLUB and SLAB memory allocators,
while the hardware tag-based KASAN currently only supports SLUB.
Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390,
and riscv architectures, and tag-based KASAN is supported only for arm64.
Usage
-----
To enable KASAN configure kernel with::
To enable KASAN, configure the kernel with::
CONFIG_KASAN = y
CONFIG_KASAN=y
and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN),
CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN), and
CONFIG_KASAN_HW_TAGS (to enable hardware tag-based KASAN).
and choose between ``CONFIG_KASAN_GENERIC`` (to enable generic KASAN),
``CONFIG_KASAN_SW_TAGS`` (to enable software tag-based KASAN), and
``CONFIG_KASAN_HW_TAGS`` (to enable hardware tag-based KASAN).
For software modes, you also need to choose between CONFIG_KASAN_OUTLINE and
CONFIG_KASAN_INLINE. Outline and inline are compiler instrumentation types.
The former produces smaller binary while the latter is 1.1 - 2 times faster.
For software modes, also choose between ``CONFIG_KASAN_OUTLINE`` and
``CONFIG_KASAN_INLINE``. Outline and inline are compiler instrumentation types.
The former produces a smaller binary while the latter is 1.1-2 times faster.
Both software KASAN modes work with both SLUB and SLAB memory allocators,
while the hardware tag-based KASAN currently only support SLUB.
For better error reports that include stack traces, enable CONFIG_STACKTRACE.
To augment reports with last allocation and freeing stack of the physical page,
it is recommended to enable also CONFIG_PAGE_OWNER and boot with page_owner=on.
To include alloc and free stack traces of affected slab objects into reports,
enable ``CONFIG_STACKTRACE``. To include alloc and free stack traces of affected
physical pages, enable ``CONFIG_PAGE_OWNER`` and boot with ``page_owner=on``.
Error reports
~~~~~~~~~~~~~
A typical out-of-bounds access generic KASAN report looks like this::
A typical KASAN report looks like this::
==================================================================
BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan]
@@ -123,41 +133,57 @@ A typical out-of-bounds access generic KASAN report looks like this::
ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
==================================================================
The header of the report provides a short summary of what kind of bug happened
and what kind of access caused it. It's followed by a stack trace of the bad
access, a stack trace of where the accessed memory was allocated (in case bad
access happens on a slab object), and a stack trace of where the object was
freed (in case of a use-after-free bug report). Next comes a description of
the accessed slab object and information about the accessed memory page.
The report header summarizes what kind of bug happened and what kind of access
caused it. It is followed by a stack trace of the bad access, a stack trace of
where the accessed memory was allocated (in case a slab object was accessed),
and a stack trace of where the object was freed (in case of a use-after-free
bug report). Next comes a description of the accessed slab object and the
information about the accessed memory page.
In the last section the report shows memory state around the accessed address.
Internally KASAN tracks memory state separately for each memory granule, which
In the end, the report shows the memory state around the accessed address.
Internally, KASAN tracks memory state separately for each memory granule, which
is either 8 or 16 aligned bytes depending on KASAN mode. Each number in the
memory state section of the report shows the state of one of the memory
granules that surround the accessed address.
For generic KASAN the size of each memory granule is 8. The state of each
For generic KASAN, the size of each memory granule is 8. The state of each
granule is encoded in one shadow byte. Those 8 bytes can be accessible,
partially accessible, freed or be a part of a redzone. KASAN uses the following
encoding for each shadow byte: 0 means that all 8 bytes of the corresponding
partially accessible, freed, or be a part of a redzone. KASAN uses the following
encoding for each shadow byte: 00 means that all 8 bytes of the corresponding
memory region are accessible; number N (1 <= N <= 7) means that the first N
bytes are accessible, and other (8 - N) bytes are not; any negative value
indicates that the entire 8-byte word is inaccessible. KASAN uses different
negative values to distinguish between different kinds of inaccessible memory
like redzones or freed memory (see mm/kasan/kasan.h).
In the report above the arrows point to the shadow byte 03, which means that
the accessed address is partially accessible. For tag-based KASAN modes this
last report section shows the memory tags around the accessed address
(see the `Implementation details`_ section).
In the report above, the arrow points to the shadow byte ``03``, which means
that the accessed address is partially accessible.
For tag-based KASAN modes, this last report section shows the memory tags around
the accessed address (see the `Implementation details`_ section).
Note that KASAN bug titles (like ``slab-out-of-bounds`` or ``use-after-free``)
are best-effort: KASAN prints the most probable bug type based on the limited
information it has. The actual type of the bug might be different.
Generic KASAN also reports up to two auxiliary call stack traces. These stack
traces point to places in code that interacted with the object but that are not
directly present in the bad access stack trace. Currently, this includes
call_rcu() and workqueue queuing.
Boot parameters
~~~~~~~~~~~~~~~
KASAN is affected by the generic ``panic_on_warn`` command line parameter.
When it is enabled, KASAN panics the kernel after printing a bug report.
By default, KASAN prints a bug report only for the first invalid memory access.
With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This
effectively disables ``panic_on_warn`` for KASAN reports.
Hardware tag-based KASAN mode (see the section about various modes below) is
intended for use in production as a security mitigation. Therefore, it supports
boot parameters that allow to disable KASAN competely or otherwise control
particular KASAN features.
boot parameters that allow disabling KASAN or controlling its features.
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
@@ -174,26 +200,8 @@ particular KASAN features.
traces collection (default: ``on``).
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
report or also panic the kernel (default: ``report``). Note, that tag
checking gets disabled after the first reported bug.
For developers
~~~~~~~~~~~~~~
Software KASAN modes use compiler instrumentation to insert validity checks.
Such instrumentation might be incompatible with some part of the kernel, and
therefore needs to be disabled. To disable instrumentation for specific files
or directories, add a line similar to the following to the respective kernel
Makefile:
- For a single file (e.g. main.o)::
KASAN_SANITIZE_main.o := n
- For all files in one directory::
KASAN_SANITIZE := n
report or also panic the kernel (default: ``report``). The panic happens even
if ``kasan_multi_shot`` is enabled.
Implementation details
----------------------
@@ -201,12 +209,11 @@ Implementation details
Generic KASAN
~~~~~~~~~~~~~
From a high level perspective, KASAN's approach to memory error detection is
similar to that of kmemcheck: use shadow memory to record whether each byte of
memory is safe to access, and use compile-time instrumentation to insert checks
of shadow memory on each memory access.
Software KASAN modes use shadow memory to record whether each byte of memory is
safe to access and use compile-time instrumentation to insert shadow memory
checks before each memory access.
Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (e.g. 16TB
Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (16TB
to cover 128TB on x86_64) and uses direct mapping with a scale and offset to
translate a memory address to its corresponding shadow address.
@@ -215,113 +222,105 @@ address::
static inline void *kasan_mem_to_shadow(const void *addr)
{
return ((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
+ KASAN_SHADOW_OFFSET;
}
where ``KASAN_SHADOW_SCALE_SHIFT = 3``.
Compile-time instrumentation is used to insert memory access checks. Compiler
inserts function calls (__asan_load*(addr), __asan_store*(addr)) before each
memory access of size 1, 2, 4, 8 or 16. These functions check whether memory
access is valid or not by checking corresponding shadow memory.
inserts function calls (``__asan_load*(addr)``, ``__asan_store*(addr)``) before
each memory access of size 1, 2, 4, 8, or 16. These functions check whether
memory accesses are valid or not by checking corresponding shadow memory.
GCC 5.0 has possibility to perform inline instrumentation. Instead of making
function calls GCC directly inserts the code to check the shadow memory.
This option significantly enlarges kernel but it gives x1.1-x2 performance
boost over outline instrumented kernel.
With inline instrumentation, instead of making function calls, the compiler
directly inserts the code to check shadow memory. This option significantly
enlarges the kernel, but it gives an x1.1-x2 performance boost over the
outline-instrumented kernel.
Generic KASAN also reports the last 2 call stacks to creation of work that
potentially has access to an object. Call stacks for the following are shown:
call_rcu() and workqueue queuing.
Generic KASAN is the only mode that delays the reuse of freed object via
Generic KASAN is the only mode that delays the reuse of freed objects via
quarantine (see mm/kasan/quarantine.c for implementation).
Software tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Software tag-based KASAN requires software memory tagging support in the form
of HWASan-like compiler instrumentation (see HWASan documentation for details).
Software tag-based KASAN is currently only implemented for arm64 architecture.
Software tag-based KASAN uses a software memory tagging approach to checking
access validity. It is currently only implemented for the arm64 architecture.
Software tag-based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
to store a pointer tag in the top byte of kernel pointers. Like generic KASAN
it uses shadow memory to store memory tags associated with each 16-byte memory
cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).
to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
to store memory tags associated with each 16-byte memory cell (therefore, it
dedicates 1/16th of the kernel memory for shadow memory).
On each memory allocation software tag-based KASAN generates a random tag, tags
the allocated memory with this tag, and embeds this tag into the returned
On each memory allocation, software tag-based KASAN generates a random tag, tags
the allocated memory with this tag, and embeds the same tag into the returned
pointer.
Software tag-based KASAN uses compile-time instrumentation to insert checks
before each memory access. These checks make sure that tag of the memory that
is being accessed is equal to tag of the pointer that is used to access this
memory. In case of a tag mismatch software tag-based KASAN prints a bug report.
before each memory access. These checks make sure that the tag of the memory
that is being accessed is equal to the tag of the pointer that is used to access
this memory. In case of a tag mismatch, software tag-based KASAN prints a bug
report.
Software tag-based KASAN also has two instrumentation modes (outline, that
emits callbacks to check memory accesses; and inline, that performs the shadow
Software tag-based KASAN also has two instrumentation modes (outline, which
emits callbacks to check memory accesses; and inline, which performs the shadow
memory checks inline). With outline instrumentation mode, a bug report is
simply printed from the function that performs the access check. With inline
instrumentation a brk instruction is emitted by the compiler, and a dedicated
brk handler is used to print bug reports.
printed from the function that performs the access check. With inline
instrumentation, a ``brk`` instruction is emitted by the compiler, and a
dedicated ``brk`` handler is used to print bug reports.
Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with 0xFF pointer tag aren't checked). The value 0xFE is currently
pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
reserved to tag freed memory regions.
Software tag-based KASAN currently only supports tagging of
kmem_cache_alloc/kmalloc and page_alloc memory.
Software tag-based KASAN currently only supports tagging of slab and page_alloc
memory.
Hardware tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Hardware tag-based KASAN is similar to the software mode in concept, but uses
Hardware tag-based KASAN is similar to the software mode in concept but uses
hardware memory tagging support instead of compiler instrumentation and
shadow memory.
Hardware tag-based KASAN is currently only implemented for arm64 architecture
and based on both arm64 Memory Tagging Extension (MTE) introduced in ARMv8.5
Instruction Set Architecture, and Top Byte Ignore (TBI).
Instruction Set Architecture and Top Byte Ignore (TBI).
Special arm64 instructions are used to assign memory tags for each allocation.
Same tags are assigned to pointers to those allocations. On every memory
access, hardware makes sure that tag of the memory that is being accessed is
equal to tag of the pointer that is used to access this memory. In case of a
tag mismatch a fault is generated and a report is printed.
access, hardware makes sure that the tag of the memory that is being accessed is
equal to the tag of the pointer that is used to access this memory. In case of a
tag mismatch, a fault is generated, and a report is printed.
Hardware tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with 0xFF pointer tag aren't checked). The value 0xFE is currently
pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
reserved to tag freed memory regions.
Hardware tag-based KASAN currently only supports tagging of
kmem_cache_alloc/kmalloc and page_alloc memory.
Hardware tag-based KASAN currently only supports tagging of slab and page_alloc
memory.
If the hardware doesn't support MTE (pre ARMv8.5), hardware tag-based KASAN
won't be enabled. In this case all boot parameters are ignored.
If the hardware does not support MTE (pre ARMv8.5), hardware tag-based KASAN
will not be enabled. In this case, all KASAN boot parameters are ignored.
Note, that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
enabled. Even when kasan.mode=off is provided, or when the hardware doesn't
Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not
support MTE (but supports TBI).
Hardware tag-based KASAN only reports the first found bug. After that MTE tag
Hardware tag-based KASAN only reports the first found bug. After that, MTE tag
checking gets disabled.
What memory accesses are sanitised by KASAN?
--------------------------------------------
Shadow memory
-------------
The kernel maps memory in a number of different parts of the address
space. This poses something of a problem for KASAN, which requires
that all addresses accessed by instrumented code have a valid shadow
region.
The kernel maps memory in several different parts of the address space.
The range of kernel virtual addresses is large: there is not enough real
memory to support a real shadow region for every address that could be
accessed by the kernel. Therefore, KASAN only maps real shadow for certain
parts of the address space.
The range of kernel virtual addresses is large: there is not enough
real memory to support a real shadow region for every address that
could be accessed by the kernel.
By default
~~~~~~~~~~
Default behaviour
~~~~~~~~~~~~~~~~~
By default, architectures only map real memory over the shadow region
for the linear mapping (and potentially other small areas). For all
@@ -330,10 +329,9 @@ page is mapped over the shadow area. This read-only shadow page
declares all memory accesses as permitted.
This presents a problem for modules: they do not live in the linear
mapping, but in a dedicated module space. By hooking in to the module
allocator, KASAN can temporarily map real shadow memory to cover
them. This allows detection of invalid accesses to module globals, for
example.
mapping but in a dedicated module space. By hooking into the module
allocator, KASAN temporarily maps real shadow memory to cover them.
This allows detection of invalid accesses to module globals, for example.
This also creates an incompatibility with ``VMAP_STACK``: if the stack
lives in vmalloc space, it will be shadowed by the read-only page, and
@@ -344,9 +342,10 @@ CONFIG_KASAN_VMALLOC
~~~~~~~~~~~~~~~~~~~~
With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the
cost of greater memory usage. Currently this is only supported on x86.
cost of greater memory usage. Currently, this is supported on x86,
riscv, s390, and powerpc.
This works by hooking into vmalloc and vmap, and dynamically
This works by hooking into vmalloc and vmap and dynamically
allocating real shadow memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full
@@ -365,28 +364,76 @@ memory.
To avoid the difficulties around swapping mappings around, KASAN expects
that the part of the shadow region that covers the vmalloc space will
not be covered by the early shadow page, but will be left
unmapped. This will require changes in arch-specific code.
not be covered by the early shadow page but will be left unmapped.
This will require changes in arch-specific code.
This allows ``VMAP_STACK`` support on x86, and can simplify support of
This allows ``VMAP_STACK`` support on x86 and can simplify support of
architectures that do not have a fixed module region.
CONFIG_KASAN_KUNIT_TEST and CONFIG_KASAN_MODULE_TEST
----------------------------------------------------
For developers
--------------
KASAN tests consist of two parts:
Ignoring accesses
~~~~~~~~~~~~~~~~~
Software KASAN modes use compiler instrumentation to insert validity checks.
Such instrumentation might be incompatible with some parts of the kernel, and
therefore needs to be disabled.
Other parts of the kernel might access metadata for allocated objects.
Normally, KASAN detects and reports such accesses, but in some cases (e.g.,
in memory allocators), these accesses are valid.
For software KASAN modes, to disable instrumentation for a specific file or
directory, add a ``KASAN_SANITIZE`` annotation to the respective kernel
Makefile:
- For a single file (e.g., main.o)::
KASAN_SANITIZE_main.o := n
- For all files in one directory::
KASAN_SANITIZE := n
For software KASAN modes, to disable instrumentation on a per-function basis,
use the KASAN-specific ``__no_sanitize_address`` function attribute or the
generic ``noinstr`` one.
Note that disabling compiler instrumentation (either on a per-file or a
per-function basis) makes KASAN ignore the accesses that happen directly in
that code for software KASAN modes. It does not help when the accesses happen
indirectly (through calls to instrumented functions) or with the hardware
tag-based mode that does not use compiler instrumentation.
For software KASAN modes, to disable KASAN reports in a part of the kernel code
for the current task, annotate this part of the code with a
``kasan_disable_current()``/``kasan_enable_current()`` section. This also
disables the reports for indirect accesses that happen through function calls.
For tag-based KASAN modes (include the hardware one), to disable access
checking, use ``kasan_reset_tag()`` or ``page_kasan_tag_reset()``. Note that
temporarily disabling access checking via ``page_kasan_tag_reset()`` requires
saving and restoring the per-page KASAN tag via
``page_kasan_tag``/``page_kasan_tag_set``.
Tests
~~~~~
There are KASAN tests that allow verifying that KASAN works and can detect
certain types of memory corruptions. The tests consist of two parts:
1. Tests that are integrated with the KUnit Test Framework. Enabled with
``CONFIG_KASAN_KUNIT_TEST``. These tests can be run and partially verified
automatically in a few different ways, see the instructions below.
automatically in a few different ways; see the instructions below.
2. Tests that are currently incompatible with KUnit. Enabled with
``CONFIG_KASAN_MODULE_TEST`` and can only be run as a module. These tests can
only be verified manually, by loading the kernel module and inspecting the
only be verified manually by loading the kernel module and inspecting the
kernel log for KASAN reports.
Each KUnit-compatible KASAN test prints a KASAN report if an error is detected.
Then the test prints its number and status.
Each KUnit-compatible KASAN test prints one of multiple KASAN reports if an
error is detected. Then the test prints its number and status.
When a test passes::
@@ -414,30 +461,24 @@ Or, if one of the tests failed::
not ok 1 - kasan
There are a few ways to run KUnit-compatible KASAN tests.
1. Loadable module
~~~~~~~~~~~~~~~~~~
With ``CONFIG_KUNIT`` enabled, ``CONFIG_KASAN_KUNIT_TEST`` can be built as
a loadable module and run on any architecture that supports KASAN by loading
the module with insmod or modprobe. The module is called ``test_kasan``.
With ``CONFIG_KUNIT`` enabled, KASAN-KUnit tests can be built as a loadable
module and run by loading ``test_kasan.ko`` with ``insmod`` or ``modprobe``.
2. Built-In
~~~~~~~~~~~
With ``CONFIG_KUNIT`` built-in, ``CONFIG_KASAN_KUNIT_TEST`` can be built-in
on any architecure that supports KASAN. These and any other KUnit tests enabled
will run and print the results at boot as a late-init call.
With ``CONFIG_KUNIT`` built-in, KASAN-KUnit tests can be built-in as well.
In this case, the tests will run at boot as a late-init call.
3. Using kunit_tool
~~~~~~~~~~~~~~~~~~~
With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, it's also
possible use ``kunit_tool`` to see the results of these and other KUnit tests
in a more readable way. This will not print the KASAN reports of the tests that
passed. Use `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
for more up-to-date information on ``kunit_tool``.
With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, it is also
possible to use ``kunit_tool`` to see the results of KUnit tests in a more
readable way. This will not print the KASAN reports of the tests that passed.
See `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
for more up-to-date information on ``kunit_tool``.
.. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html

4
Documentation/devicetree/bindings/.gitignore vendored
View File

@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
*.example.dts
processed-schema*.yaml
processed-schema*.json
/processed-schema*.yaml
/processed-schema*.json

7
Documentation/devicetree/bindings/Makefile
View File

@@ -5,7 +5,7 @@ DT_MK_SCHEMA ?= dt-mk-schema
DT_SCHEMA_LINT = $(shell which yamllint)
DT_SCHEMA_MIN_VERSION = 2020.8.1
DT_SCHEMA_MIN_VERSION = 2021.2.1
PHONY += check_dtschema_version
check_dtschema_version:
@@ -48,13 +48,16 @@ define rule_chkdt
$(call cmd,mk_schema)
endef
DT_DOCS = $(shell $(find_cmd) | sed -e 's|^$(srctree)/||')
DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_cmd)))
override DTC_FLAGS := \
-Wno-avoid_unnecessary_addr_size \
-Wno-graph_child_address \
-Wno-interrupt_provider
# Disable undocumented compatible checks until warning free
override DT_CHECKER_FLAGS ?=
$(obj)/processed-schema-examples.json: $(DT_DOCS) $(src)/.yamllint check_dtschema_version FORCE
$(call if_changed_rule,chkdt)

5
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
View File

@@ -26,10 +26,7 @@ properties:
- const: simple-mfd
mboxes:
$ref: '/schemas/types.yaml#/definitions/phandle'
description: |
Phandle to the firmware device's Mailbox.
(See: ../mailbox/mailbox.txt for more information)
maxItems: 1
clocks:
type: object

2
Documentation/devicetree/bindings/arm/cpus.yaml
View File

@@ -258,13 +258,11 @@ properties:
where voltage is in V, frequency is in MHz.
power-domains:
$ref: '/schemas/types.yaml#/definitions/phandle-array'
description:
List of phandles and PM domain specifiers, as defined by bindings of the
PM domain provider (see also ../power_domain.txt).
power-domain-names:
$ref: '/schemas/types.yaml#/definitions/string-array'
description:
A list of power domain name strings sorted in the same order as the
power-domains property.

75
Documentation/devicetree/bindings/arm/ete.yaml Normal file
View File

@@ -0,0 +1,75 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
# Copyright 2021, Arm Ltd
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/ete.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: ARM Embedded Trace Extensions
maintainers:
- Suzuki K Poulose <suzuki.poulose@arm.com>
- Mathieu Poirier <mathieu.poirier@linaro.org>
description: |
Arm Embedded Trace Extension(ETE) is a per CPU trace component that
allows tracing the CPU execution. It overlaps with the CoreSight ETMv4
architecture and has extended support for future architecture changes.
The trace generated by the ETE could be stored via legacy CoreSight
components (e.g, TMC-ETR) or other means (e.g, using a per CPU buffer
Arm Trace Buffer Extension (TRBE)). Since the ETE can be connected to
legacy CoreSight components, a node must be listed per instance, along
with any optional connection graph as per the coresight bindings.
See bindings/arm/coresight.txt.
properties:
$nodename:
pattern: "^ete([0-9a-f]+)$"
compatible:
items:
- const: arm,embedded-trace-extension
cpu:
description: |
Handle to the cpu this ETE is bound to.
$ref: /schemas/types.yaml#/definitions/phandle
out-ports:
description: |
Output connections from the ETE to legacy CoreSight trace bus.
$ref: /schemas/graph.yaml#/properties/ports
properties:
port:
description: Output connection from the ETE to legacy CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- cpu
additionalProperties: false
examples:
# An ETE node without legacy CoreSight connections
- |
ete0 {
compatible = "arm,embedded-trace-extension";
cpu = <&cpu_0>;
};
# An ETE node with legacy CoreSight connections
- |
ete1 {
compatible = "arm,embedded-trace-extension";
cpu = <&cpu_1>;
out-ports { /* legacy coresight connection */
port {
ete1_out_port: endpoint {
remote-endpoint = <&funnel_in_port0>;
};
};
};
};
...

4
Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
View File

@@ -142,8 +142,8 @@ mpp50 50 gpio, ge1(rxclk), mss_i2c(sda), spi1(csn0), uart2(txd), uart0(rxd), xg(
mpp51 51 gpio, ge1(rxd0), mss_i2c(sck), spi1(csn1), uart2(rxd), uart0(cts), sdio(pwr10)
mpp52 52 gpio, ge1(rxd1), synce1(clk), synce2(clk), spi1(csn2), uart1(cts), led(clk), pcie(rstoutn), pcie0(clkreq)
mpp53 53 gpio, ge1(rxd2), ptp(clk), spi1(csn3), uart1(rxd), led(stb), sdio(led)
mpp54 54 gpio, ge1(rxd3), synce2(clk), ptp(pclk_out), synce1(clk), led(data), sdio(hw_rst), sdio(wr_protect)
mpp55 55 gpio, ge1(rxctl_rxdv), ptp(pulse), sdio(led), sdio(card_detect)
mpp54 54 gpio, ge1(rxd3), synce2(clk), ptp(pclk_out), synce1(clk), led(data), sdio(hw_rst), sdio_wp(wr_protect)
mpp55 55 gpio, ge1(rxctl_rxdv), ptp(pulse), sdio(led), sdio_cd(card_detect)
mpp56 56 gpio, tdm(drx), au(i2sdo_spdifo), spi0(clk), uart1(rxd), sata1(present_act), sdio(clk)
mpp57 57 gpio, mss_i2c(sda), ptp(pclk_out), tdm(intn), au(i2sbclk), spi0(mosi), uart1(txd), sata0(present_act), sdio(cmd)
mpp58 58 gpio, mss_i2c(sck), ptp(clk), tdm(rstn), au(i2sdi), spi0(miso), uart1(cts), led(clk), sdio(d0)

49
Documentation/devicetree/bindings/arm/trbe.yaml Normal file
View File

@@ -0,0 +1,49 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
# Copyright 2021, Arm Ltd
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/trbe.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: ARM Trace Buffer Extensions
maintainers:
- Anshuman Khandual <anshuman.khandual@arm.com>
description: |
Arm Trace Buffer Extension (TRBE) is a per CPU component
for storing trace generated on the CPU to memory. It is
accessed via CPU system registers. The software can verify
if it is permitted to use the component by checking the
TRBIDR register.
properties:
$nodename:
const: "trbe"
compatible:
items:
- const: arm,trace-buffer-extension
interrupts:
description: |
Exactly 1 PPI must be listed. For heterogeneous systems where
TRBE is only supported on a subset of the CPUs, please consult
the arm,gic-v3 binding for details on describing a PPI partition.
maxItems: 1
required:
- compatible
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
trbe {
compatible = "arm,trace-buffer-extension";
interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
};
...

4
Documentation/devicetree/bindings/ata/ahci-ceva.txt
View File

@@ -38,6 +38,8 @@ Required properties:
Optional properties:
- ceva,broken-gen2: limit to gen1 speed instead of gen2.
- phys: phandle for the PHY device
- resets: phandle to the reset controller for the SATA IP
Examples:
ahci@fd0c0000 {
@@ -56,4 +58,6 @@ Examples:
ceva,p1-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>;
ceva,p1-retry-params = /bits/ 16 <0x0216 0x7F06>;
ceva,broken-gen2;
phys = <&psgtr 1 PHY_TYPE_SATA 1 1>;
resets = <&zynqmp_reset ZYNQMP_RESET_SATA>;
};

176
Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml Normal file
View File

@@ -0,0 +1,176 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/ata/nvidia,tegra-ahci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Tegra AHCI SATA Controller
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jonathan Hunter <jonathanh@nvidia.com>
properties:
compatible:
enum:
- nvidia,tegra124-ahci
- nvidia,tegra132-ahci
- nvidia,tegra210-ahci
- nvidia,tegra186-ahci
reg:
minItems: 2
maxItems: 3
items:
- description: AHCI registers
- description: SATA configuration and IPFS registers
- description: SATA AUX registers
interrupts:
maxItems: 1
clock-names:
items:
- const: sata
- const: sata-oob
clocks:
maxItems: 2
reset-names:
minItems: 2
items:
- const: sata
- const: sata-cold
- const: sata-oob
resets:
minItems: 2
maxItems: 3
iommus:
maxItems: 1
interconnect-names:
items:
- const: dma-mem
- const: write
interconnects:
maxItems: 2
power-domains:
items:
- description: SAX power-domain
phy-names:
items:
- const: sata-0
phys:
maxItems: 1
hvdd-supply:
description: SATA HVDD regulator supply.
vddio-supply:
description: SATA VDDIO regulator supply.
avdd-supply:
description: SATA AVDD regulator supply.
target-5v-supply:
description: SATA 5V power regulator supply.
target-12v-supply:
description: SATA 12V power regulator supply.
required:
- compatible
- reg
- interrupts
- clock-names
- clocks
- reset-names
- resets
allOf:
- if:
properties:
compatible:
contains:
enum:
- nvidia,tegra124-ahci
- nvidia,tegra132-ahci
then:
properties:
reg:
maxItems: 2
reset-names:
minItems: 3
resets:
minItems: 3
required:
- phys
- phy-names
- hvdd-supply
- vddio-supply
- avdd-supply
- if:
properties:
compatible:
contains:
enum:
- nvidia,tegra210-ahci
then:
properties:
reg:
minItems: 3
reset-names:
minItems: 3
resets:
minItems: 3
- if:
properties:
compatible:
contains:
enum:
- nvidia,tegra186-ahci
then:
properties:
reg:
minItems: 3
reset-names:
maxItems: 2
resets:
maxItems: 2
required:
- iommus
- interconnect-names
- interconnects
- power-domains
additionalProperties: true
examples:
- |
#include <dt-bindings/clock/tegra210-car.h>
#include <dt-bindings/reset/tegra210-car.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
sata@70020000 {
compatible = "nvidia,tegra210-ahci";
reg = <0x70027000 0x00002000>, /* AHCI */
<0x70020000 0x00007000>, /* SATA */
<0x70001100 0x00010000>; /* SATA AUX */
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA210_CLK_SATA>,
<&tegra_car TEGRA210_CLK_SATA_OOB>;
clock-names = "sata", "sata-oob";
resets = <&tegra_car 124>,
<&tegra_car 129>,
<&tegra_car 123>;
reset-names = "sata", "sata-cold", "sata-oob";
};

44
Documentation/devicetree/bindings/ata/nvidia,tegra124-ahci.txt
View File

@@ -1,44 +0,0 @@
Tegra SoC SATA AHCI controller
Required properties :
- compatible : Must be one of:
- Tegra124 : "nvidia,tegra124-ahci"
- Tegra132 : "nvidia,tegra132-ahci", "nvidia,tegra124-ahci"
- Tegra210 : "nvidia,tegra210-ahci"
- reg : Should contain 2 entries:
- AHCI register set (SATA BAR5)
- SATA register set
- interrupts : Defines the interrupt used by SATA
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names : Must include the following entries:
- sata
- sata-oob
- resets : Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names : Must include the following entries:
- sata
- sata-oob
- sata-cold
- phys : Must contain an entry for each entry in phy-names.
See ../phy/phy-bindings.txt for details.
- phy-names : Must include the following entries:
- For Tegra124 and Tegra132:
- sata-phy : XUSB PADCTL SATA PHY
- For Tegra124 and Tegra132:
- hvdd-supply : Defines the SATA HVDD regulator
- vddio-supply : Defines the SATA VDDIO regulator
- avdd-supply : Defines the SATA AVDD regulator
- target-5v-supply : Defines the SATA 5V power regulator
- target-12v-supply : Defines the SATA 12V power regulator
Optional properties:
- reg :
- AUX register set
- clock-names :
- cml1 :
cml1 clock should be defined here if the PHY driver
doesn't manage them. If it does, they should not be.
- phy-names :
- For T210:
- sata-phy

2
Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll1-clk.yaml
View File

@@ -44,7 +44,7 @@ examples:
- |
clk@1c20000 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-pll1";
compatible = "allwinner,sun4i-a10-pll1-clk";
reg = <0x01c20000 0x4>;
clocks = <&osc24M>;
clock-output-names = "osc24M";

2
Documentation/devicetree/bindings/clock/armada3700-tbg-clock.txt
View File

@@ -1,6 +1,6 @@
* Time Base Generator Clock bindings for Marvell Armada 37xx SoCs
Marvell Armada 37xx SoCs provde Time Base Generator clocks which are
Marvell Armada 37xx SoCs provide Time Base Generator clocks which are
used as parent clocks for the peripheral clocks.
The TBG clock consumer should specify the desired clock by having the

2
Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
View File

@@ -60,7 +60,6 @@ properties:
maxItems: 2
idt,xtal-load-femtofarads:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 9000
maximum: 22760
description: Optional load capacitor for XTAL1 and XTAL2
@@ -84,7 +83,6 @@ patternProperties:
enum: [ 1800000, 2500000, 3300000 ]
idt,slew-percent:
description: The Slew rate control for CMOS single-ended.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 80, 85, 90, 100 ]
required:

68
Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml Normal file
View File

@@ -0,0 +1,68 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/mediatek,mt7621-sysc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MT7621 Clock Device Tree Bindings
maintainers:
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
description: |
The MT7621 has a PLL controller from where the cpu clock is provided
as well as derived clocks for the bus and the peripherals. It also
can gate SoC device clocks.
Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume.
All these identifiers could be found in:
[1]: <include/dt-bindings/clock/mt7621-clk.h>.
The clocks are provided inside a system controller node.
properties:
compatible:
items:
- const: mediatek,mt7621-sysc
- const: syscon
reg:
maxItems: 1
"#clock-cells":
description:
The first cell indicates the clock number, see [1] for available
clocks.
const: 1
ralink,memctl:
$ref: /schemas/types.yaml#/definitions/phandle
description:
phandle of syscon used to control memory registers
clock-output-names:
maxItems: 8
required:
- compatible
- reg
- '#clock-cells'
- ralink,memctl
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/mt7621-clk.h>
sysc: sysc@0 {
compatible = "mediatek,mt7621-sysc", "syscon";
reg = <0x0 0x100>;
#clock-cells = <1>;
ralink,memctl = <&memc>;
clock-output-names = "xtal", "cpu", "bus",
"50m", "125m", "150m",
"250m", "270m";
};

12
Documentation/devicetree/bindings/clock/milbeaut-clock.yaml
View File

@@ -18,10 +18,12 @@ description: |
properties:
compatible:
oneOf:
- items:
- enum:
- socionext,milbeaut-m10v-ccu
enum:
- socionext,milbeaut-m10v-ccu
reg:
maxItems: 1
clocks:
maxItems: 1
description: external clock
@@ -41,7 +43,7 @@ examples:
# Clock controller node:
- |
m10v-clk-ctrl@1d021000 {
compatible = "socionext,milbeaut-m10v-clk-ccu";
compatible = "socionext,milbeaut-m10v-ccu";
reg = <0x1d021000 0x4000>;
#clock-cells = <1>;
clocks = <&clki40mhz>;

82
Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml Normal file
View File

@@ -0,0 +1,82 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,gcc-sdm845.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller Binding
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- Taniya Das <tdas@codeaurora.org>
description: |
Qualcomm global clock control module which supports the clocks, resets and
power domains on SDM845
See also:
- dt-bindings/clock/qcom,gcc-sdm845.h
properties:
compatible:
const: qcom,gcc-sdm845
clocks:
items:
- description: Board XO source
- description: Board active XO source
- description: Sleep clock source
- description: PCIE 0 Pipe clock source
- description: PCIE 1 Pipe clock source
clock-names:
items:
- const: bi_tcxo
- const: bi_tcxo_ao
- const: sleep_clk
- const: pcie_0_pipe_clk
- const: pcie_1_pipe_clk
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
protected-clocks:
description:
Protected clock specifier list as per common clock binding.
required:
- compatible
- reg
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
# Example for GCC for SDM845:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@100000 {
compatible = "qcom,gcc-sdm845";
reg = <0x100000 0x1f0000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>,
<&pcie0_lane>,
<&pcie1_lane>;
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk", "pcie_0_pipe_clk", "pcie_1_pipe_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

2
Documentation/devicetree/bindings/clock/qcom,gcc.yaml
View File

@@ -32,7 +32,6 @@ description: |
- dt-bindings/clock/qcom,gcc-mdm9615.h
- dt-bindings/reset/qcom,gcc-mdm9615.h
- dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660)
- dt-bindings/clock/qcom,gcc-sdm845.h
properties:
compatible:
@@ -52,7 +51,6 @@ properties:
- qcom,gcc-mdm9615
- qcom,gcc-sdm630
- qcom,gcc-sdm660
- qcom,gcc-sdm845
'#clock-cells':
const: 1

60
Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml Normal file
View File

@@ -0,0 +1,60 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3568-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROCKCHIP rk3568 Family Clock Control Module Binding
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3568 clock controller generates the clock and also implements a
reset controller for SoC peripherals.
(examples: provide SCLK_UART1\PCLK_UART1 and SRST_P_UART1\SRST_S_UART1 for UART module)
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3568-cru.h headers and can be
used in device tree sources.
properties:
compatible:
enum:
- rockchip,rk3568-cru
- rockchip,rk3568-pmucru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
# Clock Control Module node:
- |
pmucru: clock-controller@fdd00000 {
compatible = "rockchip,rk3568-pmucru";
reg = <0xfdd00000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
- |
cru: clock-controller@fdd20000 {
compatible = "rockchip,rk3568-cru";
reg = <0xfdd20000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

15
Documentation/devicetree/bindings/connector/usb-connector.yaml
View File

@@ -149,6 +149,17 @@ properties:
maxItems: 6
$ref: /schemas/types.yaml#/definitions/uint32-array
sink-vdos-v1:
description: An array of u32 with each entry, a Vendor Defined Message Object (VDO),
providing additional information corresponding to the product, the detailed bit
definitions and the order of each VDO can be found in
"USB Power Delivery Specification Revision 2.0, Version 1.3" chapter 6.4.4.3.1 Discover
Identity. User can specify the VDO array via VDO_IDH/_CERT/_PRODUCT/_CABLE/_AMA defined in
dt-bindings/usb/pd.h.
minItems: 3
maxItems: 6
$ref: /schemas/types.yaml#/definitions/uint32-array
op-sink-microwatt:
description: Sink required operating power in microwatt, if source can't
offer the power, Capability Mismatch is set. Required for power sink and
@@ -207,6 +218,10 @@ properties:
SNK_READY for non-pd link.
type: boolean
dependencies:
sink-vdos-v1: [ 'sink-vdos' ]
sink-vdos: [ 'sink-vdos-v1' ]
required:
- compatible

5
Documentation/devicetree/bindings/ddr/lpddr3.txt
View File

@@ -12,6 +12,9 @@ Required properties:
Optional properties:
- manufacturer-id : <u32> Manufacturer ID value read from Mode Register 5
- revision-id : <u32 u32> Revision IDs read from Mode Registers 6 and 7
The following optional properties represent the minimum value of some AC
timing parameters of the DDR device in terms of number of clock cycles.
These values shall be obtained from the device data-sheet.
@@ -49,6 +52,8 @@ samsung_K3QF2F20DB: lpddr3 {
compatible = "samsung,K3QF2F20DB", "jedec,lpddr3";
density = <16384>;
io-width = <32>;
manufacturer-id = <1>;
revision-id = <123 234>;
#address-cells = <1>;
#size-cells = <0>;

1
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
View File

@@ -73,7 +73,6 @@ properties:
clock-output-names:
description:
Name of the LCD pixel clock created.
$ref: /schemas/types.yaml#/definitions/string-array
maxItems: 1
dmas:

2
Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
View File

@@ -109,7 +109,7 @@ required:
- resets
- ddc
unevaluatedProperties: false
additionalProperties: false
examples:
- |

6
Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
View File

@@ -77,12 +77,6 @@ examples:
clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr";
pitouchscreen: panel@0 {
compatible = "raspberrypi,touchscreen";
reg = <0>;
/* ... */
};
};
...

4
Documentation/devicetree/bindings/display/msm/dpu.txt
View File

@@ -2,14 +2,14 @@ Qualcomm Technologies, Inc. DPU KMS
Description:
Device tree bindings for MSM Mobile Display Subsytem(MDSS) that encapsulates
Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
sub-blocks like DPU display controller, DSI and DP interfaces etc.
The DPU display controller is found in SDM845 SoC.
MDSS:
Required properties:
- compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss"
- reg: physical base address and length of contoller's registers.
- reg: physical base address and length of controller's registers.
- reg-names: register region names. The following region is required:
* "mdss"
- power-domains: a power domain consumer specifier according to

1
Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml
View File

@@ -47,7 +47,6 @@ examples:
spi-max-frequency = <3125000>;
spi-3wire;
spi-cs-high;
reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;

2
Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
View File

@@ -40,7 +40,7 @@ additionalProperties: false
examples:
- |
panel {
compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
compatible = "startek,startek-kd050c", "panel-dpi";
label = "osddisplay";
power-supply = <&vcc_supply>;
backlight = <&backlight>;

3
Documentation/devicetree/bindings/display/renesas,du.yaml
View File

@@ -51,6 +51,9 @@ properties:
resets: true
reset-names: true
power-domains:
maxItems: 1
ports:
$ref: /schemas/graph.yaml#/properties/port
description: |

3
Documentation/devicetree/bindings/dma/qcom,gpi.yaml
View File

@@ -20,6 +20,7 @@ properties:
compatible:
enum:
- qcom,sdm845-gpi-dma
- qcom,sm8150-gpi-dma
reg:
maxItems: 1
@@ -64,7 +65,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/dma/qcom-gpi.h>
gpi_dma0: dma-controller@800000 {
compatible = "qcom,gpi-dma";
compatible = "qcom,sdm845-gpi-dma";
#dma-cells = <3>;
reg = <0x00800000 0x60000>;
iommus = <&apps_smmu 0x0016 0x0>;

46
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.txt
View File

@@ -1,46 +0,0 @@
Bindings for the Broadcom's brcm,bcm6345-gpio memory-mapped GPIO controllers.
These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345
are the only ones which don't need a pinctrl driver.
BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
Required properties:
- compatible: should be "brcm,bcm6345-gpio"
- reg-names: must contain
"dat" - data register
"dirout" - direction (output) register
- reg: address + size pairs describing the GPIO register sets;
order must correspond with the order of entries in reg-names
- #gpio-cells: must be set to 2. The first cell is the pin number and
the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- gpio-controller: Marks the device node as a gpio controller.
Optional properties:
- native-endian: use native endian memory.
Examples:
- BCM6338:
gpio: gpio-controller@fffe0407 {
compatible = "brcm,bcm6345-gpio";
reg-names = "dirout", "dat";
reg = <0xfffe0407 1>, <0xfffe040f 1>;
#gpio-cells = <2>;
gpio-controller;
};
- BCM6345:
gpio: gpio-controller@fffe0406 {
compatible = "brcm,bcm6345-gpio";
reg-names = "dirout", "dat";
reg = <0xfffe0406 2>, <0xfffe040a 2>;
native-endian;
#gpio-cells = <2>;
gpio-controller;
};

86
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml Normal file
View File

@@ -0,0 +1,86 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6345 GPIO controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description: |+
Bindings for Broadcom's BCM63xx memory-mapped GPIO controllers.
These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345
are the only ones which don't need a pinctrl driver.
BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
and dirout registers, where GPIO state can be read and/or written, and the
direction changed from input to output.
properties:
compatible:
enum:
- brcm,bcm6318-gpio
- brcm,bcm6328-gpio
- brcm,bcm6345-gpio
- brcm,bcm6358-gpio
- brcm,bcm6362-gpio
- brcm,bcm6368-gpio
- brcm,bcm63268-gpio
gpio-controller: true
"#gpio-cells":
const: 2
gpio-ranges:
maxItems: 1
native-endian: true
reg:
maxItems: 2
reg-names:
items:
- const: dirout
- const: dat
required:
- compatible
- reg
- reg-names
- gpio-controller
- '#gpio-cells'
additionalProperties: false
examples:
- |
gpio@fffe0406 {
compatible = "brcm,bcm6345-gpio";
reg-names = "dirout", "dat";
reg = <0xfffe0406 2>, <0xfffe040a 2>;
native-endian;
gpio-controller;
#gpio-cells = <2>;
};
- |
gpio@0 {
compatible = "brcm,bcm63268-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 52>;
#gpio-cells = <2>;
};

77
Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml Normal file
View File

@@ -0,0 +1,77 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/fairchild,74hc595.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic 8-bit shift register
maintainers:
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:
enum:
- fairchild,74hc595
- nxp,74lvc594
reg:
maxItems: 1
gpio-controller: true
'#gpio-cells':
description:
The second cell is only used to specify the GPIO polarity.
const: 2
registers-number:
description: Number of daisy-chained shift registers
enable-gpios:
description: GPIO connected to the OE (Output Enable) pin.
maxItems: 1
spi-max-frequency: true
patternProperties:
"^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
type: object
properties:
gpio-hog: true
gpios: true
output-high: true
output-low: true
line-name: true
required:
- gpio-hog
- gpios
additionalProperties: false
required:
- compatible
- reg
- gpio-controller
- '#gpio-cells'
- registers-number
additionalProperties: false
examples:
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
gpio5: gpio5@0 {
compatible = "fairchild,74hc595";
reg = <0>;
gpio-controller;
#gpio-cells = <2>;
registers-number = <4>;
spi-max-frequency = <100000>;
};
};

27
Documentation/devicetree/bindings/gpio/gpio-74x164.txt
View File

@@ -1,27 +0,0 @@
* Generic 8-bits shift register GPIO driver
Required properties:
- compatible: Should contain one of the following:
"fairchild,74hc595"
"nxp,74lvc594"
- reg : chip select number
- gpio-controller : Marks the device node as a gpio controller.
- #gpio-cells : Should be two. The first cell is the pin number and
the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- registers-number: Number of daisy-chained shift registers
Optional properties:
- enable-gpios: GPIO connected to the OE (Output Enable) pin.
Example:
gpio5: gpio5@0 {
compatible = "fairchild,74hc595";
reg = <0>;
gpio-controller;
#gpio-cells = <2>;
registers-number = <4>;
spi-max-frequency = <100000>;
};

78
Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml Normal file
View File

@@ -0,0 +1,78 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/realtek,otto-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Realtek Otto GPIO controller
maintainers:
- Sander Vanheule <sander@svanheule.net>
- Bert Vermeulen <bert@biot.com>
description: |
Realtek's GPIO controller on their MIPS switch SoCs (Otto platform) consists
of two banks of 32 GPIOs. These GPIOs can generate edge-triggered interrupts.
Each bank's interrupts are cascased into one interrupt line on the parent
interrupt controller, if provided.
This binding allows defining a single bank in the devicetree. The interrupt
controller is not supported on the fallback compatible name, which only
allows for GPIO port use.
properties:
$nodename:
pattern: "^gpio@[0-9a-f]+$"
compatible:
items:
- enum:
- realtek,rtl8380-gpio
- realtek,rtl8390-gpio
- const: realtek,otto-gpio
reg:
maxItems: 1
"#gpio-cells":
const: 2
gpio-controller: true
ngpios:
minimum: 1
maximum: 32
interrupt-controller: true
"#interrupt-cells":
const: 2
interrupts:
maxItems: 1
required:
- compatible
- reg
- "#gpio-cells"
- gpio-controller
additionalProperties: false
dependencies:
interrupt-controller: [ interrupts ]
examples:
- |
gpio@3500 {
compatible = "realtek,rtl8380-gpio", "realtek,otto-gpio";
reg = <0x3500 0x1c>;
gpio-controller;
#gpio-cells = <2>;
ngpios = <24>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&rtlintc>;
interrupts = <23>;
};
...

82
Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml Normal file
View File

@@ -0,0 +1,82 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/rockchip,gpio-bank.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip GPIO bank
maintainers:
- Heiko Stuebner <heiko@sntech.de>
properties:
compatible:
enum:
- rockchip,gpio-bank
- rockchip,rk3188-gpio-bank0
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
gpio-controller: true
"#gpio-cells":
const: 2
interrupt-controller: true
"#interrupt-cells":
const: 2
required:
- compatible
- reg
- interrupts
- clocks
- gpio-controller
- "#gpio-cells"
- interrupt-controller
- "#interrupt-cells"
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
pinctrl: pinctrl {
#address-cells = <1>;
#size-cells = <1>;
ranges;
gpio0: gpio@2000a000 {
compatible = "rockchip,rk3188-gpio-bank0";
reg = <0x2000a000 0x100>;
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_gates8 9>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio1: gpio@2003c000 {
compatible = "rockchip,gpio-bank";
reg = <0x2003c000 0x100>;
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_gates8 10>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
};

3
Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml
View File

@@ -43,8 +43,7 @@ properties:
gpio-ranges: true
gpio-ranges-group-names:
$ref: /schemas/types.yaml#/definitions/string-array
gpio-ranges-group-names: true
socionext,interrupt-ranges:
description: |

28
Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt
View File

@@ -1,28 +0,0 @@
SIRF Hardware spinlock device Binding
-----------------------------------------------
Required properties :
- compatible : shall contain only one of the following:
"sirf,hwspinlock"
- reg : the register address of hwspinlock
- #hwlock-cells : hwlock users only use the hwlock id to represent a specific
hwlock, so the number of cells should be <1> here.
Please look at the generic hwlock binding for usage information for consumers,
"Documentation/devicetree/bindings/hwlock/hwlock.txt"
Example of hwlock provider:
hwlock {
compatible = "sirf,hwspinlock";
reg = <0x13240000 0x00010000>;
#hwlock-cells = <1>;
};
Example of hwlock users:
node {
...
hwlocks = <&hwlock 2>;
...
};

2
Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml
View File

@@ -49,7 +49,7 @@ examples:
#size-cells = <0>;
adc@48 {
comatible = "ti,ads7828";
compatible = "ti,ads7828";
reg = <0x48>;
vref-supply = <&vref>;
ti,differential-input;

62
Documentation/devicetree/bindings/i2c/i2c-mpc.txt
View File

@@ -1,62 +0,0 @@
* I2C
Required properties :
- reg : Offset and length of the register set for the device
- compatible : should be "fsl,CHIP-i2c" where CHIP is the name of a
compatible processor, e.g. mpc8313, mpc8543, mpc8544, mpc5121,
mpc5200 or mpc5200b. For the mpc5121, an additional node
"fsl,mpc5121-i2c-ctrl" is required as shown in the example below.
Recommended properties :
- interrupts : <a b> where a is the interrupt number and b is a
field that represents an encoding of the sense and level
information for the interrupt. This should be encoded based on
the information in section 2) depending on the type of interrupt
controller you have.
- fsl,preserve-clocking : boolean; if defined, the clock settings
from the bootloader are preserved (not touched).
- clock-frequency : desired I2C bus clock frequency in Hz.
- fsl,timeout : I2C bus timeout in microseconds.
Examples :
/* MPC5121 based board */
i2c@1740 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5121-i2c", "fsl-i2c";
reg = <0x1740 0x20>;
interrupts = <11 0x8>;
interrupt-parent = <&ipic>;
clock-frequency = <100000>;
};
i2ccontrol@1760 {
compatible = "fsl,mpc5121-i2c-ctrl";
reg = <0x1760 0x8>;
};
/* MPC5200B based board */
i2c@3d00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <0x3d00 0x40>;
interrupts = <2 15 0>;
interrupt-parent = <&mpc5200_pic>;
fsl,preserve-clocking;
};
/* MPC8544 base board */
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8544-i2c", "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
clock-frequency = <400000>;
fsl,timeout = <10000>;
};

98
Documentation/devicetree/bindings/i2c/i2c-mpc.yaml Normal file
View File

@@ -0,0 +1,98 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-mpc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: I2C-Bus adapter for MPC824x/83xx/85xx/86xx/512x/52xx SoCs
maintainers:
- Chris Packham <chris.packham@alliedtelesis.co.nz>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
properties:
compatible:
oneOf:
- items:
- enum:
- mpc5200-i2c
- fsl,mpc5200-i2c
- fsl,mpc5121-i2c
- fsl,mpc8313-i2c
- fsl,mpc8543-i2c
- fsl,mpc8544-i2c
- const: fsl-i2c
- items:
- const: fsl,mpc5200b-i2c
- const: fsl,mpc5200-i2c
- const: fsl-i2c
reg:
maxItems: 1
interrupts:
maxItems: 1
fsl,preserve-clocking:
$ref: /schemas/types.yaml#/definitions/flag
description: |
if defined, the clock settings from the bootloader are
preserved (not touched)
fsl,timeout:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
I2C bus timeout in microseconds
fsl,i2c-erratum-a004447:
$ref: /schemas/types.yaml#/definitions/flag
description: |
Indicates the presence of QorIQ erratum A-004447, which
says that the standard i2c recovery scheme mechanism does
not work and an alternate implementation is needed.
required:
- compatible
- reg
- interrupts
unevaluatedProperties: false
examples:
- |
/* MPC5121 based board */
i2c@1740 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5121-i2c", "fsl-i2c";
reg = <0x1740 0x20>;
interrupts = <11 0x8>;
interrupt-parent = <&ipic>;
clock-frequency = <100000>;
};
/* MPC5200B based board */
i2c@3d00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
reg = <0x3d00 0x40>;
interrupts = <2 15 0>;
interrupt-parent = <&mpc5200_pic>;
fsl,preserve-clocking;
};
/* MPC8544 base board */
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8544-i2c", "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
clock-frequency = <400000>;
fsl,timeout = <10000>;
};
...

2
Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
View File

@@ -4,7 +4,7 @@
$id: "http://devicetree.org/schemas/i2c/xlnx,xps-iic-2.00.a.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: ilinx IIC controller Device Tree Bindings
title: Xilinx IIC controller Device Tree Bindings
maintainers:
- info@mocean-labs.com

7
Documentation/devicetree/bindings/i3c/i3c.yaml
View File

@@ -157,9 +157,10 @@ examples:
i2c-scl-hz = <100000>;
/* I2C device. */
nunchuk: nunchuk@52 {
compatible = "nintendo,nunchuk";
reg = <0x52 0x0 0x10>;
eeprom@57 {
compatible = "atmel,24c01";
reg = <0x57 0x0 0x10>;
pagesize = <0x8>;
};
/* I3C device with a static I2C address. */

2
Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
View File

@@ -49,7 +49,7 @@ additionalProperties: true
examples:
- |
i3c-master@a0000000 {
compatible = "silvaco,i3c-master";
compatible = "silvaco,i3c-master-v1";
clocks = <&zynqmp_clk 71>, <&fclk>, <&sclk>;
clock-names = "pclk", "fast_clk", "slow_clk";
interrupt-parent = <&gic>;

5
Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.yaml
View File

@@ -53,11 +53,6 @@ examples:
#address-cells = <1>;
#size-cells = <1>;
ts_adc_syscon: ts_adc_syscon@180a6000 {
compatible = "brcm,iproc-ts-adc-syscon","syscon";
reg = <0x180a6000 0xc30>;
};
adc {
compatible = "brcm,iproc-static-adc";
adc-syscon = <&ts_adc_syscon>;

1
Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
View File

@@ -102,7 +102,6 @@ patternProperties:
st,adc-channel-names:
description: List of single-ended channel names.
$ref: /schemas/types.yaml#/definitions/string-array
st,filter-order:
description: |

2
Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml
View File

@@ -83,7 +83,7 @@ examples:
#size-cells = <0>;
gyroscope@0 {
compatible = "nxp,fxas2102c";
compatible = "nxp,fxas21002c";
reg = <0x0>;
spi-max-frequency = <2000000>;

1
Documentation/devicetree/bindings/iio/light/capella,cm3605.yaml
View File

@@ -48,7 +48,6 @@ properties:
vdd-supply: true
capella,aset-resistance-ohms:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [50000, 100000, 300000, 600000]
description: >
Sensitivity calibration resistance. Note that calibration curves

Some files were not shown because too many files have changed in this diff Show More