diff options
Diffstat (limited to 'Documentation')
167 files changed, 4828 insertions, 1775 deletions
diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu index 516dafea03eb..3965ce504484 100644 --- a/Documentation/ABI/stable/sysfs-devices-system-cpu +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -42,6 +42,12 @@ Description: the CPU core ID of cpuX. Typically it is the hardware platform's architecture and platform dependent. Values: integer +What: /sys/devices/system/cpu/cpuX/topology/cluster_id +Description: the cluster ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. +Values: integer + What: /sys/devices/system/cpu/cpuX/topology/book_id Description: the book ID of cpuX. Typically it is the hardware platform's identifier (rather than the kernel's). The actual value is @@ -85,6 +91,15 @@ Description: human-readable list of CPUs within the same die. The format is like 0-3, 8-11, 14,17. Values: decimal list. +What: /sys/devices/system/cpu/cpuX/topology/cluster_cpus +Description: internal kernel map of CPUs within the same cluster. +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/cluster_cpus_list +Description: human-readable list of CPUs within the same cluster. + The format is like 0-3, 8-11, 14,17. +Values: decimal list. + What: /sys/devices/system/cpu/cpuX/topology/book_siblings Description: internal kernel map of cpuX's hardware threads within the same book_id. it's only used on s390. diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index babbe04c8d37..81d37ac7132c 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1016,6 +1016,8 @@ All time durations are in microseconds. - nr_periods - nr_throttled - throttled_usec + - nr_bursts + - burst_usec cpu.weight A read-write single value file which exists on non-root @@ -1047,6 +1049,12 @@ All time durations are in microseconds. $PERIOD duration. "max" for $MAX indicates no limit. If only one number is written, $MAX is updated. + cpu.max.burst + A read-write single value file which exists on non-root + cgroups. The default is "0". + + The burst in the range [0, $MAX]. + cpu.pressure A read-write nested-keyed file. @@ -1226,7 +1234,7 @@ PAGE_SIZE multiple when read back. Note that all fields in this file are hierarchical and the file modified event can be generated due to an event down the - hierarchy. For for the local events at the cgroup level see + hierarchy. For the local events at the cgroup level see memory.events.local. low @@ -2170,19 +2178,19 @@ existing device files. Cgroup v2 device controller has no interface files and is implemented on top of cgroup BPF. To control access to device files, a user may -create bpf programs of the BPF_CGROUP_DEVICE type and attach them -to cgroups. On an attempt to access a device file, corresponding -BPF programs will be executed, and depending on the return value -the attempt will succeed or fail with -EPERM. - -A BPF_CGROUP_DEVICE program takes a pointer to the bpf_cgroup_dev_ctx -structure, which describes the device access attempt: access type -(mknod/read/write) and device (type, major and minor numbers). -If the program returns 0, the attempt fails with -EPERM, otherwise -it succeeds. - -An example of BPF_CGROUP_DEVICE program may be found in the kernel -source tree in the tools/testing/selftests/bpf/progs/dev_cgroup.c file. +create bpf programs of type BPF_PROG_TYPE_CGROUP_DEVICE and attach +them to cgroups with BPF_CGROUP_DEVICE flag. On an attempt to access a +device file, corresponding BPF programs will be executed, and depending +on the return value the attempt will succeed or fail with -EPERM. + +A BPF_PROG_TYPE_CGROUP_DEVICE program takes a pointer to the +bpf_cgroup_dev_ctx structure, which describes the device access attempt: +access type (mknod/read/write) and device (type, major and minor numbers). +If the program returns 0, the attempt fails with -EPERM, otherwise it +succeeds. + +An example of BPF_PROG_TYPE_CGROUP_DEVICE program may be found in +tools/testing/selftests/bpf/progs/dev_cgroup.c in the kernel source tree. RDMA diff --git a/Documentation/admin-guide/cputopology.rst b/Documentation/admin-guide/cputopology.rst index b085dbac60a5..6b62e182baf4 100644 --- a/Documentation/admin-guide/cputopology.rst +++ b/Documentation/admin-guide/cputopology.rst @@ -19,11 +19,13 @@ these macros in include/asm-XXX/topology.h:: #define topology_physical_package_id(cpu) #define topology_die_id(cpu) + #define topology_cluster_id(cpu) #define topology_core_id(cpu) #define topology_book_id(cpu) #define topology_drawer_id(cpu) #define topology_sibling_cpumask(cpu) #define topology_core_cpumask(cpu) + #define topology_cluster_cpumask(cpu) #define topology_die_cpumask(cpu) #define topology_book_cpumask(cpu) #define topology_drawer_cpumask(cpu) @@ -39,10 +41,12 @@ not defined by include/asm-XXX/topology.h: 1) topology_physical_package_id: -1 2) topology_die_id: -1 -3) topology_core_id: 0 -4) topology_sibling_cpumask: just the given CPU -5) topology_core_cpumask: just the given CPU -6) topology_die_cpumask: just the given CPU +3) topology_cluster_id: -1 +4) topology_core_id: 0 +5) topology_sibling_cpumask: just the given CPU +6) topology_core_cpumask: just the given CPU +7) topology_cluster_cpumask: just the given CPU +8) topology_die_cpumask: just the given CPU For architectures that don't support books (CONFIG_SCHED_BOOK) there are no default definitions for topology_book_id() and topology_book_cpumask(). diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index e05e581af5cf..ab7d402c1677 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -490,9 +490,8 @@ Spectre variant 2 Restricting indirect branch speculation on a user program will also prevent the program from launching a variant 2 attack - on x86. All sand-boxed SECCOMP programs have indirect branch - speculation restricted by default. Administrators can change - that behavior via the kernel command line and sysfs control files. + on x86. Administrators can change that behavior via the kernel + command line and sysfs control files. See :ref:`spectre_mitigation_control_command_line`. Programs that disable their indirect branch speculation will have @@ -594,61 +593,14 @@ kernel command line. Not specifying this option is equivalent to spectre_v2=auto. -For user space mitigation: - - spectre_v2_user= - - [X86] Control mitigation of Spectre variant 2 - (indirect branch speculation) vulnerability between - user space tasks - - on - Unconditionally enable mitigations. Is - enforced by spectre_v2=on - - off - Unconditionally disable mitigations. Is - enforced by spectre_v2=off - - prctl - Indirect branch speculation is enabled, - but mitigation can be enabled via prctl - per thread. The mitigation control state - is inherited on fork. - - prctl,ibpb - Like "prctl" above, but only STIBP is - controlled per thread. IBPB is issued - always when switching between different user - space processes. - - seccomp - Same as "prctl" above, but all seccomp - threads will enable the mitigation unless - they explicitly opt out. - - seccomp,ibpb - Like "seccomp" above, but only STIBP is - controlled per thread. IBPB is issued - always when switching between different - user space processes. - - auto - Kernel selects the mitigation depending on - the available CPU features and vulnerability. - - Default mitigation: - If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl" - - Not specifying this option is equivalent to - spectre_v2_user=auto. - In general the kernel by default selects reasonable mitigations for the current CPU. To disable Spectre variant 2 mitigations, boot with spectre_v2=off. Spectre variant 1 mitigations cannot be disabled. +For spectre_v2_user see :doc:`/admin-guide/kernel-parameters`. + Mitigation selection guide -------------------------- @@ -674,9 +626,8 @@ Mitigation selection guide off by disabling their indirect branch speculation when they are run (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`). This prevents untrusted programs from polluting the branch target - buffer. All programs running in SECCOMP sandboxes have indirect - branch speculation restricted by default. This behavior can be - changed via the kernel command line and sysfs control files. See + buffer. This behavior can be changed via the kernel command line + and sysfs control files. See :ref:`spectre_mitigation_control_command_line`. 3. High security mode diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 91ba391f9b32..fb76a64a2168 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1266,7 +1266,7 @@ The VGA and EFI output is eventually overwritten by the real console. - The xen output can only be used by Xen PV guests. + The xen option can only be used in Xen domains. The sclp output can only be used on s390. @@ -5303,8 +5303,7 @@ auto - Kernel selects the mitigation depending on the available CPU features and vulnerability. - Default mitigation: - If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl" + Default mitigation: "prctl" Not specifying this option is equivalent to spectre_v2_user=auto. @@ -5348,7 +5347,7 @@ will disable SSB unless they explicitly opt out. Default mitigations: - X86: If CONFIG_SECCOMP=y "seccomp", otherwise "prctl" + X86: "prctl" On powerpc the options are: @@ -5497,6 +5496,15 @@ stifb= [HW] Format: bpp:<bpp1>[:<bpp2>[:<bpp3>...]] + strict_sas_size= + [X86] + Format: <bool> + Enable or disable strict sigaltstack size checks + against the required signal frame size which + depends on the supported FPU features. This can + be used to filter out binaries which have + not yet been made aware of AT_MINSIGSTKSZ. + sunrpc.min_resvport= sunrpc.max_resvport= [NFS,SUNRPC] diff --git a/Documentation/admin-guide/media/i2c-cardlist.rst b/Documentation/admin-guide/media/i2c-cardlist.rst index e60d459d18a9..db17f39b56cf 100644 --- a/Documentation/admin-guide/media/i2c-cardlist.rst +++ b/Documentation/admin-guide/media/i2c-cardlist.rst @@ -58,15 +58,20 @@ Camera sensor devices ============ ========================================================== Driver Name ============ ========================================================== +ccs MIPI CCS compliant camera sensors (also SMIA++ and SMIA) et8ek8 ET8EK8 camera sensor hi556 Hynix Hi-556 sensor +hi846 Hynix Hi-846 sensor +imx208 Sony IMX208 sensor imx214 Sony IMX214 sensor imx219 Sony IMX219 sensor imx258 Sony IMX258 sensor imx274 Sony IMX274 sensor imx290 Sony IMX290 sensor imx319 Sony IMX319 sensor +imx334 Sony IMX334 sensor imx355 Sony IMX355 sensor +imx412 Sony IMX412 sensor m5mols Fujitsu M-5MOLS 8MP sensor mt9m001 mt9m001 mt9m032 MT9M032 camera sensor @@ -79,6 +84,7 @@ mt9v032 Micron MT9V032 sensor mt9v111 Aptina MT9V111 sensor noon010pc30 Siliconfile NOON010PC30 sensor ov13858 OmniVision OV13858 sensor +ov13b10 OmniVision OV13B10 sensor ov2640 OmniVision OV2640 sensor ov2659 OmniVision OV2659 sensor ov2680 OmniVision OV2680 sensor @@ -104,7 +110,6 @@ s5k4ecgx Samsung S5K4ECGX sensor s5k5baf Samsung S5K5BAF sensor s5k6a3 Samsung S5K6A3 sensor s5k6aa Samsung S5K6AAFX sensor -smiapp SMIA++/SMIA sensor sr030pc30 Siliconfile SR030PC30 sensor vs6624 ST VS6624 sensor ============ ========================================================== @@ -138,6 +143,7 @@ Driver Name ad5820 AD5820 lens voice coil ak7375 AK7375 lens voice coil dw9714 DW9714 lens voice coil +dw9768 DW9768 lens voice coil dw9807-vcm DW9807 lens voice coil ============ ========================================================== diff --git a/Documentation/admin-guide/media/imx7.rst b/Documentation/admin-guide/media/imx7.rst index 1e442c97da47..4785ae8ac978 100644 --- a/Documentation/admin-guide/media/imx7.rst +++ b/Documentation/admin-guide/media/imx7.rst @@ -155,6 +155,66 @@ the resolutions supported by the sensor. [fmt:SBGGR10_1X10/800x600@1/30 field:none colorspace:srgb] -> "imx7-mipi-csis.0":0 [ENABLED] +i.MX6ULL-EVK with OV5640 +------------------------ + +On this platform a parallel OV5640 sensor is connected to the CSI port. +The following example configures a video capture pipeline with an output +of 640x480 and UYVY8_2X8 format: + +.. code-block:: none + + # Setup links + media-ctl -l "'ov5640 1-003c':0 -> 'csi':0[1]" + media-ctl -l "'csi':1 -> 'csi capture':0[1]" + + # Configure pads for pipeline + media-ctl -v -V "'ov5640 1-003c':0 [fmt:UYVY8_2X8/640x480 field:none]" + +After this streaming can start: + +.. code-block:: none + + gst-launch-1.0 -v v4l2src device=/dev/video1 ! video/x-raw,format=UYVY,width=640,height=480 ! v4l2convert ! fbdevsink + +.. code-block:: none + + # media-ctl -p + Media controller API version 5.14.0 + + Media device information + ------------------------ + driver imx7-csi + model imx-media + serial + bus info + hw revision 0x0 + driver version 5.14.0 + + Device topology + - entity 1: csi (2 pads, 2 links) + type V4L2 subdev subtype Unknown flags 0 + device node name /dev/v4l-subdev0 + pad0: Sink + [fmt:UYVY8_2X8/640x480 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] + <- "ov5640 1-003c":0 [ENABLED,IMMUTABLE] + pad1: Source + [fmt:UYVY8_2X8/640x480 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] + -> "csi capture":0 [ENABLED,IMMUTABLE] + + - entity 4: csi capture (1 pad, 1 link) + type Node subtype V4L flags 0 + device node name /dev/video1 + pad0: Sink + <- "csi":1 [ENABLED,IMMUTABLE] + + - entity 10: ov5640 1-003c (1 pad, 1 link) + type V4L2 subdev subtype Sensor flags 0 + device node name /dev/v4l-subdev1 + pad0: Source + [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] + -> "csi":0 [ENABLED,IMMUTABLE] + References ---------- diff --git a/Documentation/admin-guide/media/ipu3.rst b/Documentation/admin-guide/media/ipu3.rst index 52c1c04173da..83b3cd03b35c 100644 --- a/Documentation/admin-guide/media/ipu3.rst +++ b/Documentation/admin-guide/media/ipu3.rst @@ -51,10 +51,11 @@ to userspace as a V4L2 sub-device node and has two pads: .. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}| .. flat-table:: + :header-rows: 1 - * - pad - - direction - - purpose + * - Pad + - Direction + - Purpose * - 0 - sink @@ -148,10 +149,11 @@ Each pipe has two sink pads and three source pads for the following purpose: .. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}| .. flat-table:: + :header-rows: 1 - * - pad - - direction - - purpose + * - Pad + - Direction + - Purpose * - 0 - sink diff --git a/Documentation/admin-guide/media/ivtv.rst b/Documentation/admin-guide/media/ivtv.rst index 7b8775d20214..101f16d0263e 100644 --- a/Documentation/admin-guide/media/ivtv.rst +++ b/Documentation/admin-guide/media/ivtv.rst @@ -159,7 +159,7 @@ whatever). Otherwise the device numbers can get confusing. The ivtv Read-only The raw YUV video output from the current video input. The YUV format - is non-standard (V4L2_PIX_FMT_HM12). + is a 16x16 linear tiled NV12 format (V4L2_PIX_FMT_NV12_16L16) Note that the YUV and PCM streams are not synchronized, so they are of limited use. diff --git a/Documentation/admin-guide/media/vimc.rst b/Documentation/admin-guide/media/vimc.rst index 211cc8972410..180507d455f2 100644 --- a/Documentation/admin-guide/media/vimc.rst +++ b/Documentation/admin-guide/media/vimc.rst @@ -61,9 +61,10 @@ vimc-debayer: * 1 Pad source vimc-scaler: - Scale up the image by a factor of 3. E.g.: a 640x480 image becomes a - 1920x1440 image. (this value can be configured, see at - `Module options`_). + Re-size the image to meet the source pad resolution. E.g.: if the sync + pad is configured to 360x480 and the source to 1280x720, the image will + be stretched to fit the source resolution. Works for any resolution + within the vimc limitations (even shrinking the image if necessary). Exposes: * 1 Pad sink @@ -75,16 +76,3 @@ vimc-capture: * 1 Pad sink * 1 Pad source - - -Module options --------------- - -Vimc has a module parameter to configure the driver. - -* ``sca_mult=<unsigned int>`` - - Image size multiplier factor to be used to multiply both width and - height, so the image size will be ``sca_mult^2`` bigger than the - original one. Currently, only supports scaling up (the default value - is 3). diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 3f9d86557c5e..52d060caf8bb 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -340,6 +340,16 @@ Before jumping into the kernel, the following conditions must be met: - SMCR_EL2.LEN must be initialised to the same value for all CPUs the kernel will execute on. + For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64) + + - If EL3 is present: + + - SMCR_EL3.FA64 (bit 31) must be initialised to 0b1. + + - If the kernel is entered at EL1 and EL2 is present: + + - SMCR_EL2.FA64 (bit 31) must be initialised to 0b1. + 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. Where the values documented diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst index 328e0c454fbd..9f9b8fd06089 100644 --- a/Documentation/arm64/cpu-feature-registers.rst +++ b/Documentation/arm64/cpu-feature-registers.rst @@ -235,7 +235,15 @@ infrastructure: | DPB | [3-0] | y | +------------------------------+---------+---------+ - 6) ID_AA64MMFR2_EL1 - Memory model feature register 2 + 6) ID_AA64MMFR0_EL1 - Memory model feature register 0 + + +------------------------------+---------+---------+ + | Name | bits | visible | + +------------------------------+---------+---------+ + | ECV | [63-60] | y | + +------------------------------+---------+---------+ + + 7) ID_AA64MMFR2_EL1 - Memory model feature register 2 +------------------------------+---------+---------+ | Name | bits | visible | @@ -243,7 +251,7 @@ infrastructure: | AT | [35-32] | y | +------------------------------+---------+---------+ - 7) ID_AA64ZFR0_EL1 - SVE feature ID register 0 + 8) ID_AA64ZFR0_EL1 - SVE feature ID register 0 +------------------------------+---------+---------+ | Name | bits | visible | diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index ec1a5a63c1d0..af106af8e1c0 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -247,6 +247,10 @@ HWCAP2_MTE Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described by Documentation/arm64/memory-tagging-extension.rst. +HWCAP2_ECV + + Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001. + 4. Unused AT_HWCAP bits ----------------------- diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index d410a47ffa57..5342e895fb60 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -92,12 +92,24 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1349291 | N/A | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-500 | #841119,826419 | N/A | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 7f9b40d6b416..4d151fbe2058 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -1,5 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 +.. _inline_encryption: + ================= Inline Encryption ================= @@ -7,230 +9,269 @@ Inline Encryption Background ========== -Inline encryption hardware sits logically between memory and the disk, and can -en/decrypt data as it goes in/out of the disk. Inline encryption hardware has a -fixed number of "keyslots" - slots into which encryption contexts (i.e. the -encryption key, encryption algorithm, data unit size) can be programmed by the -kernel at any time. Each request sent to the disk can be tagged with the index -of a keyslot (and also a data unit number to act as an encryption tweak), and -the inline encryption hardware will en/decrypt the data in the request with the -encryption context programmed into that keyslot. This is very different from -full disk encryption solutions like self encrypting drives/TCG OPAL/ATA -Security standards, since with inline encryption, any block on disk could be -encrypted with any encryption context the kernel chooses. - +Inline encryption hardware sits logically between memory and disk, and can +en/decrypt data as it goes in/out of the disk. For each I/O request, software +can control exactly how the inline encryption hardware will en/decrypt the data +in terms of key, algorithm, data unit size (the granularity of en/decryption), +and data unit number (a value that determines the initialization vector(s)). + +Some inline encryption hardware accepts all encryption parameters including raw +keys directly in low-level I/O requests. However, most inline encryption +hardware instead has a fixed number of "keyslots" and requires that the key, +algorithm, and data unit size first be programmed into a keyslot. Each +low-level I/O request then just contains a keyslot index and data unit number. + +Note that inline encryption hardware is very different from traditional crypto +accelerators, which are supported through the kernel crypto API. Traditional +crypto accelerators operate on memory regions, whereas inline encryption +hardware operates on I/O requests. Thus, inline encryption hardware needs to be +managed by the block layer, not the kernel crypto API. + +Inline encryption hardware is also very different from "self-encrypting drives", +such as those based on the TCG Opal or ATA Security standards. Self-encrypting +drives don't provide fine-grained control of encryption and provide no way to +verify the correctness of the resulting ciphertext. Inline encryption hardware +provides fine-grained control of encryption, including the choice of key and +initialization vector for each sector, and can be tested for correctness. Objective ========= -We want to support inline encryption (IE) in the kernel. -To allow for testing, we also want a crypto API fallback when actual -IE hardware is absent. We also want IE to work with layered devices -like dm and loopback (i.e. we want to be able to use the IE hardware -of the underlying devices if present, or else fall back to crypto API -en/decryption). - +We want to support inline encryption in the kernel. To make testing easier, we +also want support for falling back to the kernel crypto API when actual inline +encryption hardware is absent. We also want inline encryption to work with +layered devices like device-mapper and loopback (i.e. we want to be able to use +the inline encryption hardware of the underlying devices if present, or else +fall back to crypto API en/decryption). Constraints and notes ===================== -- IE hardware has a limited number of "keyslots" that can be programmed - with an encryption context (key, algorithm, data unit size, etc.) at any time. - One can specify a keyslot in a data request made to the device, and the - device will en/decrypt the data using the encryption context programmed into - that specified keyslot. When possible, we want to make multiple requests with - the same encryption context share the same keyslot. - -- We need a way for upper layers like filesystems to specify an encryption - context to use for en/decrypting a struct bio, and a device driver (like UFS) - needs to be able to use that encryption context when it processes the bio. - -- We need a way for device drivers to expose their inline encryption - capabilities in a unified way to the upper layers. - - -Design -====== - -We add a struct bio_crypt_ctx to struct bio that can -represent an encryption context, because we need to be able to pass this -encryption context from the upper layers (like the fs layer) to the -device driver to act upon. - -While IE hardware works on the notion of keyslots, the FS layer has no -knowledge of keyslots - it simply wants to specify an encryption context to -use while en/decrypting a bio. - -We introduce a keyslot manager (KSM) that handles the translation from -encryption contexts specified by the FS to keyslots on the IE hardware. -This KSM also serves as the way IE hardware can expose its capabilities to -upper layers. The generic mode of operation is: each device driver that wants -to support IE will construct a KSM and set it up in its struct request_queue. -Upper layers that want to use IE on this device can then use this KSM in -the device's struct request_queue to translate an encryption context into -a keyslot. The presence of the KSM in the request queue shall be used to mean -that the device supports IE. - -The KSM uses refcounts to track which keyslots are idle (either they have no -encryption context programmed, or there are no in-flight struct bios -referencing that keyslot). When a new encryption context needs a keyslot, it -tries to find a keyslot that has already been programmed with the same -encryption context, and if there is no such keyslot, it evicts the least -recently used idle keyslot and programs the new encryption context into that -one. If no idle keyslots are available, then the caller will sleep until there -is at least one. - - -blk-mq changes, other block layer changes and blk-crypto-fallback -================================================================= - -We add a pointer to a ``bi_crypt_context`` and ``keyslot`` to -struct request. These will be referred to as the ``crypto fields`` -for the request. This ``keyslot`` is the keyslot into which the -``bi_crypt_context`` has been programmed in the KSM of the ``request_queue`` -that this request is being sent to. - -We introduce ``block/blk-crypto-fallback.c``, which allows upper layers to remain -blissfully unaware of whether or not real inline encryption hardware is present -underneath. When a bio is submitted with a target ``request_queue`` that doesn't -support the encryption context specified with the bio, the block layer will -en/decrypt the bio with the blk-crypto-fallback. - -If the bio is a ``WRITE`` bio, a bounce bio is allocated, and the data in the bio -is encrypted stored in the bounce bio - blk-mq will then proceed to process the -bounce bio as if it were not encrypted at all (except when blk-integrity is -concerned). ``blk-crypto-fallback`` sets the bounce bio's ``bi_end_io`` to an -internal function that cleans up the bounce bio and ends the original bio. - -If the bio is a ``READ`` bio, the bio's ``bi_end_io`` (and also ``bi_private``) -is saved and overwritten by ``blk-crypto-fallback`` to -``bio_crypto_fallback_decrypt_bio``. The bio's ``bi_crypt_context`` is also -overwritten with ``NULL``, so that to the rest of the stack, the bio looks -as if it was a regular bio that never had an encryption context specified. -``bio_crypto_fallback_decrypt_bio`` will decrypt the bio, restore the original -``bi_end_io`` (and also ``bi_private``) and end the bio again. - -Regardless of whether real inline encryption hardware is used or the +- We need a way for upper layers (e.g. filesystems) to specify an encryption + context to use for en/decrypting a bio, and device drivers (e.g. UFSHCD) need + to be able to use that encryption context when they process the request. + Encryption contexts also introduce constraints on bio merging; the block layer + needs to be aware of these constraints. + +- Different inline encryption hardware has different supported algorithms, + supported data unit sizes, maximum data unit numbers, etc. We call these + properties the "crypto capabilities". We need a way for device drivers to + advertise crypto capabilities to upper layers in a generic way. + +- Inline encryption hardware usually (but not always) requires that keys be + programmed into keyslots before being used. Since programming keyslots may be + slow and there may not be very many keyslots, we shouldn't just program the + key for every I/O request, but rather keep track of which keys are in the + keyslots and reuse an already-programmed keyslot when possible. + +- Upper layers typically define a specific end-of-life for crypto keys, e.g. + when an encrypted directory is locked or when a crypto mapping is torn down. + At these times, keys are wiped from memory. We must provide a way for upper + layers to also evict keys from any keyslots they are present in. + +- When possible, device-mapper devices must be able to pass through the inline + encryption support of their underlying devices. However, it doesn't make + sense for device-mapper devices to have keyslots themselves. + +Basic design +============ + +We introduce ``struct blk_crypto_key`` to represent an inline encryption key and +how it will be used. This includes the actual bytes of the key; the size of the +key; the algorithm and data unit size the key will be used with; and the number +of bytes needed to represent the maximum data unit number the key will be used +with. + +We introduce ``struct bio_crypt_ctx`` to represent an encryption context. It +contains a data unit number and a pointer to a blk_crypto_key. We add pointers +to a bio_crypt_ctx to ``struct bio`` and ``struct request``; this allows users +of the block layer (e.g. filesystems) to provide an encryption context when +creating a bio and have it be passed down the stack for processing by the block +layer and device drivers. Note that the encryption context doesn't explicitly +say whether to encrypt or decrypt, as that is implicit from the direction of the +bio; WRITE means encrypt, and READ means decrypt. + +We also introduce ``struct blk_crypto_profile`` to contain all generic inline +encryption-related state for a particular inline encryption device. The +blk_crypto_profile serves as the way that drivers for inline encryption hardware +advertise their crypto capabilities and provide certain functions (e.g., +functions to program and evict keys) to upper layers. Each device driver that +wants to support inline encryption will construct a blk_crypto_profile, then +associate it with the disk's request_queue. + +The blk_crypto_profile also manages the hardware's keyslots, when applicable. +This happens in the block layer, so that users of the block layer can just +specify encryption contexts and don't need to know about keyslots at all, nor do +device drivers need to care about most details of keyslot management. + +Specifically, for each keyslot, the block layer (via the blk_crypto_profile) +keeps track of which blk_crypto_key that keyslot contains (if any), and how many +in-flight I/O requests are using it. When the block layer creates a +``struct request`` for a bio that has an encryption context, it grabs a keyslot +that already contains the key if possible. Otherwise it waits for an idle +keyslot (a keyslot that isn't in-use by any I/O), then programs the key into the +least-recently-used idle keyslot using the function the device driver provided. +In both cases, the resulting keyslot is stored in the ``crypt_keyslot`` field of +the request, where it is then accessible to device drivers and is released after +the request completes. + +``struct request`` also contains a pointer to the original bio_crypt_ctx. +Requests can be built from multiple bios, and the block layer must take the +encryption context into account when trying to merge bios and requests. For two +bios/requests to be merged, they must have compatible encryption contexts: both +unencrypted, or both encrypted with the same key and contiguous data unit +numbers. Only the encryption context for the first bio in a request is +retained, since the remaining bios have been verified to be merge-compatible +with the first bio. + +To make it possible for inline encryption to work with request_queue based +layered devices, when a request is cloned, its encryption context is cloned as +well. When the cloned request is submitted, it is then processed as usual; this +includes getting a keyslot from the clone's target device if needed. + +blk-crypto-fallback +=================== + +It is desirable for the inline encryption support of upper layers (e.g. +filesystems) to be testable without real inline encryption hardware, and +likewise for the block layer's keyslot management logic. It is also desirable +to allow upper layers to just always use inline encryption rather than have to +implement encryption in multiple ways. + +Therefore, we also introduce *blk-crypto-fallback*, which is an implementation +of inline encryption using the kernel crypto API. blk-crypto-fallback is built +into the block layer, so it works on any block device without any special setup. +Essentially, when a bio with an encryption context is submitted to a +request_queue that doesn't support that encryption context, the block layer will +handle en/decryption of the bio using blk-crypto-fallback. + +For encryption, the data cannot be encrypted in-place, as callers usually rely +on it being unmodified. Instead, blk-crypto-fallback allocates bounce pages, +fills a new bio with those bounce pages, encrypts the data into those bounce +pages, and submits that "bounce" bio. When the bounce bio completes, +blk-crypto-fallback completes the original bio. If the original bio is too +large, multiple bounce bios may be required; see the code for details. + +For decryption, blk-crypto-fallback "wraps" the bio's completion callback +(``bi_complete``) and private data (``bi_private``) with its own, unsets the +bio's encryption context, then submits the bio. If the read completes +successfully, blk-crypto-fallback restores the bio's original completion +callback and private data, then decrypts the bio's data in-place using the +kernel crypto API. Decryption happens from a workqueue, as it may sleep. +Afterwards, blk-crypto-fallback completes the bio. + +In both cases, the bios that blk-crypto-fallback submits no longer have an +encryption context. Therefore, lower layers only see standard unencrypted I/O. + +blk-crypto-fallback also defines its own blk_crypto_profile and has its own +"keyslots"; its keyslots contain ``struct crypto_skcipher`` objects. The reason +for this is twofold. First, it allows the keyslot management logic to be tested +without actual inline encryption hardware. Second, similar to actual inline +encryption hardware, the crypto API doesn't accept keys directly in requests but +rather requires that keys be set ahead of time, and setting keys can be +expensive; moreover, allocating a crypto_skcipher can't happen on the I/O path +at all due to the locks it takes. Therefore, the concept of keyslots still +makes sense for blk-crypto-fallback. + +Note that regardless of whether real inline encryption hardware or blk-crypto-fallback is used, the ciphertext written to disk (and hence the -on-disk format of data) will be the same (assuming the hardware's implementation -of the algorithm being used adheres to spec and functions correctly). - -If a ``request queue``'s inline encryption hardware claimed to support the -encryption context specified with a bio, then it will not be handled by the -``blk-crypto-fallback``. We will eventually reach a point in blk-mq when a -struct request needs to be allocated for that bio. At that point, -blk-mq tries to program the encryption context into the ``request_queue``'s -keyslot_manager, and obtain a keyslot, which it stores in its newly added -``keyslot`` field. This keyslot is released when the request is completed. - -When the first bio is added to a request, ``blk_crypto_rq_bio_prep`` is called, -which sets the request's ``crypt_ctx`` to a copy of the bio's -``bi_crypt_context``. bio_crypt_do_front_merge is called whenever a subsequent -bio is merged to the front of the request, which updates the ``crypt_ctx`` of -the request so that it matches the newly merged bio's ``bi_crypt_context``. In particular, the request keeps a copy of the ``bi_crypt_context`` of the first -bio in its bio-list (blk-mq needs to be careful to maintain this invariant -during bio and request merges). - -To make it possible for inline encryption to work with request queue based -layered devices, when a request is cloned, its ``crypto fields`` are cloned as -well. When the cloned request is submitted, blk-mq programs the -``bi_crypt_context`` of the request into the clone's request_queue's keyslot -manager, and stores the returned keyslot in the clone's ``keyslot``. +on-disk format of data) will be the same (assuming that both the inline +encryption hardware's implementation and the kernel crypto API's implementation +of the algorithm being used adhere to spec and function correctly). +blk-crypto-fallback is optional and is controlled by the +``CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK`` kernel configuration option. API presented to users of the block layer ========================================= -``struct blk_crypto_key`` represents a crypto key (the raw key, size of the -key, the crypto algorithm to use, the data unit size to use, and the number of -bytes required to represent data unit numbers that will be specified with the -``bi_crypt_context``). - -``blk_crypto_init_key`` allows upper layers to initialize such a -``blk_crypto_key``. - -``bio_crypt_set_ctx`` should be called on any bio that a user of -the block layer wants en/decrypted via inline encryption (or the -blk-crypto-fallback, if hardware support isn't available for the desired -crypto configuration). This function takes the ``blk_crypto_key`` and the -data unit number (DUN) to use when en/decrypting the bio. - -``blk_crypto_config_supported`` allows upper layers to query whether or not the -an encryption context passed to request queue can be handled by blk-crypto -(either by real inline encryption hardware, or by the blk-crypto-fallback). -This is useful e.g. when blk-crypto-fallback is disabled, and the upper layer -wants to use an algorithm that may not supported by hardware - this function -lets the upper layer know ahead of time that the algorithm isn't supported, -and the upper layer can fallback to something else if appropriate. - -``blk_crypto_start_using_key`` - Upper layers must call this function on -``blk_crypto_key`` and a ``request_queue`` before using the key with any bio -headed for that ``request_queue``. This function ensures that either the -hardware supports the key's crypto settings, or the crypto API fallback has -transforms for the needed mode allocated and ready to go. Note that this -function may allocate an ``skcipher``, and must not be called from the data -path, since allocating ``skciphers`` from the data path can deadlock. - -``blk_crypto_evict_key`` *must* be called by upper layers before a -``blk_crypto_key`` is freed. Further, it *must* only be called only once -there are no more in-flight requests that use that ``blk_crypto_key``. -``blk_crypto_evict_key`` will ensure that a key is removed from any keyslots in -inline encryption hardware that the key might have been programmed into (or the blk-crypto-fallback). +``blk_crypto_config_supported()`` allows users to check ahead of time whether +inline encryption with particular crypto settings will work on a particular +request_queue -- either via hardware or via blk-crypto-fallback. This function +takes in a ``struct blk_crypto_config`` which is like blk_crypto_key, but omits +the actual bytes of the key and instead just contains the algorithm, data unit +size, etc. This function can be useful if blk-crypto-fallback is disabled. + +``blk_crypto_init_key()`` allows users to initialize a blk_crypto_key. + +Users must call ``blk_crypto_start_using_key()`` before actually starting to use +a blk_crypto_key on a request_queue (even if ``blk_crypto_config_supported()`` +was called earlier). This is needed to initialize blk-crypto-fallback if it +will be needed. This must not be called from the data path, as this may have to +allocate resources, which may deadlock in that case. + +Next, to attach an encryption context to a bio, users should call +``bio_crypt_set_ctx()``. This function allocates a bio_crypt_ctx and attaches +it to a bio, given the blk_crypto_key and the data unit number that will be used +for en/decryption. Users don't need to worry about freeing the bio_crypt_ctx +later, as that happens automatically when the bio is freed or reset. + +Finally, when done using inline encryption with a blk_crypto_key on a +request_queue, users must call ``blk_crypto_evict_key()``. This ensures that +the key is evicted from all keyslots it may be programmed into and unlinked from +any kernel data structures it may be linked into. + +In summary, for users of the block layer, the lifecycle of a blk_crypto_key is +as follows: + +1. ``blk_crypto_config_supported()`` (optional) +2. ``blk_crypto_init_key()`` +3. ``blk_crypto_start_using_key()`` +4. ``bio_crypt_set_ctx()`` (potentially many times) +5. ``blk_crypto_evict_key()`` (after all I/O has completed) +6. Zeroize the blk_crypto_key (this has no dedicated function) + +If a blk_crypto_key is being used on multiple request_queues, then +``blk_crypto_config_supported()`` (if used), ``blk_crypto_start_using_key()``, +and ``blk_crypto_evict_key()`` must be called on each request_queue. API presented to device drivers =============================== -A :c:type:``struct blk_keyslot_manager`` should be set up by device drivers in -the ``request_queue`` of the device. The device driver needs to call -``blk_ksm_init`` (or its resource-managed variant ``devm_blk_ksm_init``) on the -``blk_keyslot_manager``, while specifying the number of keyslots supported by -the hardware. - -The device driver also needs to tell the KSM how to actually manipulate the -IE hardware in the device to do things like programming the crypto key into -the IE hardware into a particular keyslot. All this is achieved through the -struct blk_ksm_ll_ops field in the KSM that the device driver -must fill up after initing the ``blk_keyslot_manager``. - -The KSM also handles runtime power management for the device when applicable -(e.g. when it wants to program a crypto key into the IE hardware, the device -must be runtime powered on) - so the device driver must also set the ``dev`` -field in the ksm to point to the `struct device` for the KSM to use for runtime -power management. - -``blk_ksm_reprogram_all_keys`` can be called by device drivers if the device -needs each and every of its keyslots to be reprogrammed with the key it -"should have" at the point in time when the function is called. This is useful -e.g. if a device loses all its keys on runtime power down/up. - -If the driver used ``blk_ksm_init`` instead of ``devm_blk_ksm_init``, then -``blk_ksm_destroy`` should be called to free up all resources used by a -``blk_keyslot_manager`` once it is no longer needed. +A device driver that wants to support inline encryption must set up a +blk_crypto_profile in the request_queue of its device. To do this, it first +must call ``blk_crypto_profile_init()`` (or its resource-managed variant +``devm_blk_crypto_profile_init()``), providing the number of keyslots. + +Next, it must advertise its crypto capabilities by setting fields in the +blk_crypto_profile, e.g. ``modes_supported`` and ``max_dun_bytes_supported``. + +It then must set function pointers in the ``ll_ops`` field of the +blk_crypto_profile to tell upper layers how to control the inline encryption +hardware, e.g. how to program and evict keyslots. Most drivers will need to +implement ``keyslot_program`` and ``keyslot_evict``. For details, see the +comments for ``struct blk_crypto_ll_ops``. + +Once the driver registers a blk_crypto_profile with a request_queue, I/O +requests the driver receives via that queue may have an encryption context. All +encryption contexts will be compatible with the crypto capabilities declared in +the blk_crypto_profile, so drivers don't need to worry about handling +unsupported requests. Also, if a nonzero number of keyslots was declared in the +blk_crypto_profile, then all I/O requests that have an encryption context will +also have a keyslot which was already programmed with the appropriate key. + +If the driver implements runtime suspend and its blk_crypto_ll_ops don't work +while the device is runtime-suspended, then the driver must also set the ``dev`` +field of the blk_crypto_profile to point to the ``struct device`` that will be +resumed before any of the low-level operations are called. + +If there are situations where the inline encryption hardware loses the contents +of its keyslots, e.g. device resets, the driver must handle reprogramming the +keyslots. To do this, the driver may call ``blk_crypto_reprogram_all_keys()``. + +Finally, if the driver used ``blk_crypto_profile_init()`` instead of +``devm_blk_crypto_profile_init()``, then it is responsible for calling +``blk_crypto_profile_destroy()`` when the crypto profile is no longer needed. Layered Devices =============== -Request queue based layered devices like dm-rq that wish to support IE need to -create their own keyslot manager for their request queue, and expose whatever -functionality they choose. When a layered device wants to pass a clone of that -request to another ``request_queue``, blk-crypto will initialize and prepare the -clone as necessary - see ``blk_crypto_insert_cloned_request`` in -``blk-crypto.c``. - - -Future Optimizations for layered devices -======================================== - -Creating a keyslot manager for a layered device uses up memory for each -keyslot, and in general, a layered device merely passes the request on to a -"child" device, so the keyslots in the layered device itself are completely -unused, and don't need any refcounting or keyslot programming. We can instead -define a new type of KSM; the "passthrough KSM", that layered devices can use -to advertise an unlimited number of keyslots, and support for any encryption -algorithms they choose, while not actually using any memory for each keyslot. -Another use case for the "passthrough KSM" is for IE devices that do not have a -limited number of keyslots. - +Request queue based layered devices like dm-rq that wish to support inline +encryption need to create their own blk_crypto_profile for their request_queue, +and expose whatever functionality they choose. When a layered device wants to +pass a clone of that request to another request_queue, blk-crypto will +initialize and prepare the clone as necessary; see +``blk_crypto_insert_cloned_request()``. Interaction between inline encryption and blk integrity ======================================================= @@ -257,7 +298,7 @@ Because there isn't any real hardware yet, it seems prudent to assume that hardware implementations might not implement both features together correctly, and disallow the combination for now. Whenever a device supports integrity, the kernel will pretend that the device does not support hardware inline encryption -(by essentially setting the keyslot manager in the request_queue of the device -to NULL). When the crypto API fallback is enabled, this means that all bios with -and encryption context will use the fallback, and IO will complete as usual. -When the fallback is disabled, a bio with an encryption context will be failed. +(by setting the blk_crypto_profile in the request_queue of the device to NULL). +When the crypto API fallback is enabled, this means that all bios with and +encryption context will use the fallback, and IO will complete as usual. When +the fallback is disabled, a bio with an encryption context will be failed. diff --git a/Documentation/block/queue-sysfs.rst b/Documentation/block/queue-sysfs.rst index 4dc7f0d499a8..e8c74306f70a 100644 --- a/Documentation/block/queue-sysfs.rst +++ b/Documentation/block/queue-sysfs.rst @@ -4,7 +4,7 @@ Queue sysfs files This text file will detail the queue files that are located in the sysfs tree for each block device. Note that stacked devices typically do not export -any settings, since their queue merely functions are a remapping target. +any settings, since their queue merely functions as a remapping target. These files are the ones found in the /sys/block/xxx/queue/ directory. Files denoted with a RO postfix are readonly and the RW postfix means @@ -286,4 +286,35 @@ sequential zones of zoned block devices (devices with a zoned attributed that reports "host-managed" or "host-aware"). This value is always 0 for regular block devices. +independent_access_ranges (RO) +------------------------------ + +The presence of this sub-directory of the /sys/block/xxx/queue/ directory +indicates that the device is capable of executing requests targeting +different sector ranges in parallel. For instance, single LUN multi-actuator +hard-disks will have an independent_access_ranges directory if the device +correctly advertizes the sector ranges of its actuators. + +The independent_access_ranges directory contains one directory per access +range, with each range described using the sector (RO) attribute file to +indicate the first sector of the range and the nr_sectors (RO) attribute file +to indicate the total number of sectors in the range starting from the first +sector of the range. For example, a dual-actuator hard-disk will have the +following independent_access_ranges entries.:: + + $ tree /sys/block/<device>/queue/independent_access_ranges/ + /sys/block/<device>/queue/independent_access_ranges/ + |-- 0 + | |-- nr_sectors + | `-- sector + `-- 1 + |-- nr_sectors + `-- sector + +The sector and nr_sectors attributes use 512B sector unit, regardless of +the actual block size of the device. Independent access ranges do not +overlap and include all sectors within the device capacity. The access +ranges are numbered in increasing order of the range start sector, +that is, the sector attribute of range 0 always has the value 0. + Jens Axboe <jens.axboe@oracle.com>, February 2009 diff --git a/Documentation/cdrom/cdrom-standard.rst b/Documentation/cdrom/cdrom-standard.rst index 5845960ca382..52ea7b6b2fe8 100644 --- a/Documentation/cdrom/cdrom-standard.rst +++ b/Documentation/cdrom/cdrom-standard.rst @@ -907,6 +907,17 @@ commands can be identified by the underscores in their names. specifies the slot for which the information is given. The special value *CDSL_CURRENT* requests that information about the currently selected slot be returned. +`CDROM_TIMED_MEDIA_CHANGE` + Checks whether the disc has been changed since a user supplied time + and returns the time of the last disc change. + + *arg* is a pointer to a *cdrom_timed_media_change_info* struct. + *arg->last_media_change* may be set by calling code to signal + the timestamp of the last known media change (by the caller). + Upon successful return, this ioctl call will set + *arg->last_media_change* to the latest media change timestamp (in ms) + known by the kernel/driver and set *arg->has_changed* to 1 if + that timestamp is more recent than the timestamp set by the caller. `CDROM_DRIVE_STATUS` Returns the status of the drive by a call to *drive_status()*. Return values are defined in cdrom_drive_status_. diff --git a/Documentation/core-api/cachetlb.rst b/Documentation/core-api/cachetlb.rst index 8aed9103e48a..5c0552e78c58 100644 --- a/Documentation/core-api/cachetlb.rst +++ b/Documentation/core-api/cachetlb.rst @@ -326,6 +326,12 @@ maps this page at its virtual address. dirty. Again, see sparc64 for examples of how to deal with this. + ``void flush_dcache_folio(struct folio *folio)`` + This function is called under the same circumstances as + flush_dcache_page(). It allows the architecture to + optimise for flushing the entire folio of pages instead + of flushing one page at a time. + ``void copy_to_user_page(struct vm_area_struct *vma, struct page *page, unsigned long user_vaddr, void *dst, void *src, int len)`` ``void copy_from_user_page(struct vm_area_struct *vma, struct page *page, diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst index 9c0e8758037a..d30b4d0a9769 100644 --- a/Documentation/core-api/irq/irq-domain.rst +++ b/Documentation/core-api/irq/irq-domain.rst @@ -67,9 +67,6 @@ variety of methods: deprecated - generic_handle_domain_irq() handles an interrupt described by a domain and a hwirq number -- handle_domain_irq() does the same thing for root interrupt - controllers and deals with the set_irq_reg()/irq_enter() sequences - that most architecture requires Note that irq domain lookups must happen in contexts that are compatible with a RCU read-side critical section. diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst index a42f9baddfbf..395835f9289f 100644 --- a/Documentation/core-api/mm-api.rst +++ b/Documentation/core-api/mm-api.rst @@ -95,6 +95,11 @@ More Memory Management Functions .. kernel-doc:: mm/mempolicy.c .. kernel-doc:: include/linux/mm_types.h :internal: +.. kernel-doc:: include/linux/mm_inline.h +.. kernel-doc:: include/linux/page-flags.h .. kernel-doc:: include/linux/mm.h :internal: +.. kernel-doc:: include/linux/page_ref.h .. kernel-doc:: include/linux/mmzone.h +.. kernel-doc:: mm/util.c + :functions: folio_mapping diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index 21dc03bc10a4..8089c559d339 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -194,14 +194,17 @@ additional boot parameters that allow disabling KASAN or controlling features: - ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``). -- ``kasan.mode=sync`` or ``=async`` controls whether KASAN is configured in - synchronous or asynchronous mode of execution (default: ``sync``). +- ``kasan.mode=sync``, ``=async`` or ``=asymm`` controls whether KASAN + is configured in synchronous, asynchronous or asymmetric mode of + execution (default: ``sync``). Synchronous mode: a bad access is detected immediately when a tag check fault occurs. Asynchronous mode: a bad access detection is delayed. When a tag check fault occurs, the information is stored in hardware (in the TFSR_EL1 register for arm64). The kernel periodically checks the hardware and only reports tag faults during these checks. + Asymmetric mode: a bad access is detected synchronously on reads and + asynchronously on writes. - ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack traces collection (default: ``on``). diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt deleted file mode 100644 index 2726c1d58a79..000000000000 --- a/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt +++ /dev/null @@ -1,49 +0,0 @@ -Binding for Samsung S2M and S5M family clock generator block -============================================================ - -This is a part of device tree bindings for S2M and S5M family multi-function -devices. -More information can be found in bindings/mfd/sec-core.txt file. - -The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz -outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs. - -To register these as clocks with common clock framework instantiate under -main device node a sub-node named "clocks". - -It uses the common clock binding documented in: - - Documentation/devicetree/bindings/clock/clock-bindings.txt - - -Required properties of the "clocks" sub-node: - - #clock-cells: should be 1. - - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk", - "samsung,s2mps14-clk", "samsung,s5m8767-clk" - The S2MPS15 uses the same compatible as S2MPS13, as both provides similar - clocks. - - -Each clock is assigned an identifier and client nodes use this identifier -to specify the clock which they consume. - Clock ID Devices - ---------------------------------------------------------- - 32KhzAP 0 S2MPS11/13/14/15, S5M8767 - 32KhzCP 1 S2MPS11/13/15, S5M8767 - 32KhzBT 2 S2MPS11/13/14/15, S5M8767 - -Include dt-bindings/clock/samsung,s2mps11.h file to use preprocessor defines -in device tree sources. - - -Example: - - s2mps11_pmic@66 { - compatible = "samsung,s2mps11-pmic"; - reg = <0x66>; - - s2m_osc: clocks { - compatible = "samsung,s2mps11-clk"; - #clock-cells = <1>; - clock-output-names = "xx", "yy", "zz"; - }; - }; diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml new file mode 100644 index 000000000000..1410c51e0e7d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,s2mps11.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2M and S5M family clock generator block + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz + outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs. + + All available clocks are defined as preprocessor macros in + dt-bindings/clock/samsung,s2mps11.h header. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +properties: + compatible: + enum: + - samsung,s2mps11-clk + - samsung,s2mps13-clk # S2MPS13 and S2MPS15 + - samsung,s2mps14-clk + - samsung,s5m8767-clk + + "#clock-cells": + const: 1 + + clock-output-names: + minItems: 3 + maxItems: 3 + description: Names for AP, CP and BT clocks. + +required: + - compatible + - "#clock-cells" + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index 07b20383cbca..b446d0f0f1b4 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -50,7 +50,6 @@ properties: data-lanes: description: array of physical DSI data lane indexes. minItems: 1 - maxItems: 4 items: - const: 1 - const: 2 @@ -71,7 +70,6 @@ properties: data-lanes: description: array of physical DSI data lane indexes. minItems: 1 - maxItems: 4 items: - const: 1 - const: 2 diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 1c2daf7c24cc..911564468c5e 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -18,7 +18,7 @@ properties: const: ti,sn65dsi86 reg: - const: 0x2d + enum: [ 0x2c, 0x2d ] enable-gpios: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml index 2ed010f91e2d..20ce88ab4b3a 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml @@ -22,7 +22,7 @@ properties: items: - enum: # ili9341 240*320 Color on stm32f429-disco board - - st,sf-tc240t-9370-t + - st,sf-tc240t-9370-t - const: ilitek,ili9341 reg: true diff --git a/Documentation/devicetree/bindings/hwmon/dps650ab.txt b/Documentation/devicetree/bindings/hwmon/dps650ab.txt deleted file mode 100644 index 76780e795899..000000000000 --- a/Documentation/devicetree/bindings/hwmon/dps650ab.txt +++ /dev/null @@ -1,11 +0,0 @@ -Bindings for Delta Electronics DPS-650-AB power supply - -Required properties: -- compatible : "delta,dps650ab" -- reg : I2C address, one of 0x58, 0x59. - -Example: - dps650ab@58 { - compatible = "delta,dps650ab"; - reg = <0x58>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/hih6130.txt b/Documentation/devicetree/bindings/hwmon/hih6130.txt deleted file mode 100644 index 2c43837af4c2..000000000000 --- a/Documentation/devicetree/bindings/hwmon/hih6130.txt +++ /dev/null @@ -1,12 +0,0 @@ -Honeywell Humidicon HIH-6130 humidity/temperature sensor --------------------------------------------------------- - -Requires node properties: -- compatible : "honeywell,hi6130" -- reg : the I2C address of the device. This is 0x27. - -Example: - hih6130@27 { - compatible = "honeywell,hih6130"; - reg = <0x27>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/ibm,cffps1.txt b/Documentation/devicetree/bindings/hwmon/ibm,cffps1.txt deleted file mode 100644 index d9a2719f9243..000000000000 --- a/Documentation/devicetree/bindings/hwmon/ibm,cffps1.txt +++ /dev/null @@ -1,26 +0,0 @@ -Device-tree bindings for IBM Common Form Factor Power Supply Versions 1 and 2 ------------------------------------------------------------------------------ - -Required properties: - - compatible : Must be one of the following: - "ibm,cffps1" - "ibm,cffps2" - or "ibm,cffps" if the system - must support any version of the - power supply - - reg = < I2C bus address >; : Address of the power supply on the - I2C bus. - -Example: - - i2c-bus@100 { - #address-cells = <1>; - #size-cells = <0>; - #interrupt-cells = <1>; - < more properties > - - power-supply@68 { - compatible = "ibm,cffps1"; - reg = <0x68>; - }; - }; diff --git a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml new file mode 100644 index 000000000000..f5a6cc3efd33 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: ADC-attached Hardware Sensor Device Tree Bindings + +maintainers: + - Jonathan Cameron <jic23@kernel.org> + +description: > + Bindings for hardware monitoring devices connected to ADC controllers + supporting the Industrial I/O bindings. + +properties: + compatible: + const: iio-hwmon + + io-channels: + minItems: 1 + maxItems: 8 # Should be enough + description: > + List of phandles to ADC channels to read the monitoring values + +required: + - compatible + - io-channels + +additionalProperties: false + +examples: + - | + iio-hwmon { + compatible = "iio-hwmon"; + io-channels = <&adc 1>, <&adc 2>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/jc42.txt b/Documentation/devicetree/bindings/hwmon/jc42.txt deleted file mode 100644 index f569db58f64a..000000000000 --- a/Documentation/devicetree/bindings/hwmon/jc42.txt +++ /dev/null @@ -1,46 +0,0 @@ -Properties for Jedec JC-42.4 compatible temperature sensors - -Required properties: -- compatible: May include a device-specific string consisting of the - manufacturer and the name of the chip. A list of supported - chip names follows. - Must include "jedec,jc-42.4-temp" for any Jedec JC-42.4 - compatible temperature sensor. - - Supported chip names: - adi,adt7408 - atmel,at30ts00 - atmel,at30tse004 - onnn,cat6095 - onnn,cat34ts02 - maxim,max6604 - microchip,mcp9804 - microchip,mcp9805 - microchip,mcp9808 - microchip,mcp98243 - microchip,mcp98244 - microchip,mcp9843 - nxp,se97 - nxp,se98 - st,stts2002 - st,stts2004 - st,stts3000 - st,stts424 - st,stts424e - idt,tse2002 - idt,tse2004 - idt,ts3000 - idt,ts3001 - -- reg: I2C address - -Optional properties: -- smbus-timeout-disable: When set, the smbus timeout function will be disabled. - This is not supported on all chips. - -Example: - -temp-sensor@1a { - compatible = "jedec,jc-42.4-temp"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml b/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml new file mode 100644 index 000000000000..0e49b3901161 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/jedec,jc42.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Jedec JC-42.4 compatible temperature sensors + +maintainers: + - Jean Delvare <jdelvare@suse.com> + - Guenter Roeck <linux@roeck-us.net> + +select: + properties: + compatible: + const: jedec,jc-42.4-temp + + required: + - compatible + +properties: + compatible: + oneOf: + - const: jedec,jc-42.4-temp + - items: + - enum: + - adi,adt7408 + - atmel,at30ts00 + - atmel,at30tse004 + - idt,tse2002 + - idt,tse2004 + - idt,ts3000 + - idt,ts3001 + - maxim,max6604 + - microchip,mcp9804 + - microchip,mcp9805 + - microchip,mcp9808 + - microchip,mcp98243 + - microchip,mcp98244 + - microchip,mcp9843 + - nxp,se97 + - nxp,se97b + - nxp,se98 + - onnn,cat6095 + - onnn,cat34ts02 + - st,stts2002 + - st,stts2004 + - st,stts3000 + - st,stts424 + - st,stts424e + - const: jedec,jc-42.4-temp + + reg: + maxItems: 1 + + smbus-timeout-disable: + description: | + When set, the smbus timeout function will be disabled. This is not + supported on all chips. + type: boolean + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + temp-sensor@1a { + compatible = "jedec,jc-42.4-temp"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml new file mode 100644 index 000000000000..4b5851c326f7 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/lltc,ltc4151.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LTC4151 High Voltage I2C Current and Voltage Monitor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: lltc,ltc4151 + + reg: + maxItems: 1 + + shunt-resistor-micro-ohms: + description: + Shunt resistor value in micro-Ohms + default: 1000 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@6e { + compatible = "lltc,ltc4151"; + reg = <0x6e>; + shunt-resistor-micro-ohms = <1500>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/lm70.txt b/Documentation/devicetree/bindings/hwmon/lm70.txt deleted file mode 100644 index ea417a0d32af..000000000000 --- a/Documentation/devicetree/bindings/hwmon/lm70.txt +++ /dev/null @@ -1,22 +0,0 @@ -* LM70/TMP121/LM71/LM74 thermometer. - -Required properties: -- compatible: one of - "ti,lm70" - "ti,tmp121" - "ti,tmp122" - "ti,lm71" - "ti,lm74" - -See Documentation/devicetree/bindings/spi/spi-bus.txt for more required and -optional properties. - -Example: - -spi_master { - temperature-sensor@0 { - compatible = "ti,lm70"; - reg = <0>; - spi-max-frequency = <1000000>; - }; -}; diff --git a/Documentation/devicetree/bindings/hwmon/lm90.txt b/Documentation/devicetree/bindings/hwmon/lm90.txt deleted file mode 100644 index 398dcb965751..000000000000 --- a/Documentation/devicetree/bindings/hwmon/lm90.txt +++ /dev/null @@ -1,51 +0,0 @@ -* LM90 series thermometer. - -Required node properties: -- compatible: manufacturer and chip name, one of - "adi,adm1032" - "adi,adt7461" - "adi,adt7461a" - "gmt,g781" - "national,lm90" - "national,lm86" - "national,lm89" - "national,lm99" - "dallas,max6646" - "dallas,max6647" - "dallas,max6649" - "dallas,max6657" - "dallas,max6658" - "dallas,max6659" - "dallas,max6680" - "dallas,max6681" - "dallas,max6695" - "dallas,max6696" - "onnn,nct1008" - "winbond,w83l771" - "nxp,sa56004" - "ti,tmp451" - -- reg: I2C bus address of the device - -- vcc-supply: vcc regulator for the supply voltage. - -Optional properties: -- interrupts: Contains a single interrupt specifier which describes the - LM90 "-ALERT" pin output. - See interrupt-controller/interrupts.txt for the format. - -- #thermal-sensor-cells: should be set to 1. See thermal/thermal-sensor.yaml - for details. See <include/dt-bindings/thermal/lm90.h> for the - definition of the local, remote and 2nd remote sensor index - constants. - -Example LM90 node: - -temp-sensor { - compatible = "onnn,nct1008"; - reg = <0x4c>; - vcc-supply = <&palmas_ldo6_reg>; - interrupt-parent = <&gpio>; - interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>; - #thermal-sensor-cells = <1>; -} diff --git a/Documentation/devicetree/bindings/hwmon/ltc4151.txt b/Documentation/devicetree/bindings/hwmon/ltc4151.txt deleted file mode 100644 index d008a5ef525a..000000000000 --- a/Documentation/devicetree/bindings/hwmon/ltc4151.txt +++ /dev/null @@ -1,18 +0,0 @@ -LTC4151 High Voltage I2C Current and Voltage Monitor - -Required properties: -- compatible: Must be "lltc,ltc4151" -- reg: I2C address - -Optional properties: -- shunt-resistor-micro-ohms - Shunt resistor value in micro-Ohms - Defaults to <1000> if unset. - -Example: - -ltc4151@6e { - compatible = "lltc,ltc4151"; - reg = <0x6e>; - shunt-resistor-micro-ohms = <1500>; -}; diff --git a/Documentation/devicetree/bindings/hwmon/mcp3021.txt b/Documentation/devicetree/bindings/hwmon/mcp3021.txt deleted file mode 100644 index 294318ba6914..000000000000 --- a/Documentation/devicetree/bindings/hwmon/mcp3021.txt +++ /dev/null @@ -1,21 +0,0 @@ -mcp3021 properties - -Required properties: -- compatible: Must be one of the following: - - "microchip,mcp3021" for mcp3021 - - "microchip,mcp3221" for mcp3221 -- reg: I2C address - -Optional properties: - -- reference-voltage-microvolt - Reference voltage in microvolt (uV) - -Example: - -mcp3021@4d { - compatible = "microchip,mcp3021"; - reg = <0x4d>; - - reference-voltage-microvolt = <4500000>; /* 4.5 V */ -}; diff --git a/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml new file mode 100644 index 000000000000..c42051f8a191 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/microchip,mcp3021.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MCP3021 A/D converter + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - microchip,mcp3021 + - microchip,mcp3221 + + reg: + maxItems: 1 + + reference-voltage-microvolt: + description: + VDD supply power and reference voltage + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + adc@4d { + compatible = "microchip,mcp3021"; + reg = <0x4d>; + + reference-voltage-microvolt = <4500000>; /* 4.5 V */ + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml new file mode 100644 index 000000000000..6e1d54ff5d5b --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/national,lm90.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LM90 series thermometer + +maintainers: + - Jean Delvare <jdelvare@suse.com> + - Guenter Roeck <linux@roeck-us.net> + +properties: + compatible: + enum: + - adi,adm1032 + - adi,adt7461 + - adi,adt7461a + - dallas,max6646 + - dallas,max6647 + - dallas,max6649 + - dallas,max6657 + - dallas,max6658 + - dallas,max6659 + - dallas,max6680 + - dallas,max6681 + - dallas,max6695 + - dallas,max6696 + - gmt,g781 + - national,lm86 + - national,lm89 + - national,lm90 + - national,lm99 + - nxp,sa56004 + - onnn,nct1008 + - ti,tmp451 + - winbond,w83l771 + + + interrupts: + items: + - description: | + Single interrupt specifier which describes the LM90 "-ALERT" pin + output. + + reg: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + + vcc-supply: + description: phandle to the regulator that provides the +VCC supply + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4c { + compatible = "onnn,nct1008"; + reg = <0x4c>; + vcc-supply = <&palmas_ldo6_reg>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>; + #thermal-sensor-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml new file mode 100644 index 000000000000..9e77cee07dbc --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml @@ -0,0 +1,141 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +--- +$id: http://devicetree.org/schemas/hwmon/ntc-thermistor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NTC thermistor temperature sensors + +maintainers: + - Naveen Krishna Chatradhi <ch.naveen@samsung.com> + - Linus Walleij <linus.walleij@linaro.org> + +description: | + Thermistors with negative temperature coefficient (NTC) are resistors that + vary in resistance in an often non-linear way in relation to temperature. + The negative temperature coefficient means that the resistance decreases + as the temperature rises. Since the relationship between resistance and + temperature is non-linear, software drivers most often need to use a look + up table and interpolation to get from resistance to temperature. + + When used in practice, a thermistor is often connected between ground, a + pull-up resistor or/and a pull-down resistor and a fixed voltage like this: + + + e.g. 5V = pull-up voltage (puv) + | + +-+ + | | + | | Pull-up resistor + | | (puo) + +-+ + |-------------------------o + +-+ | ^ + | |/ | + | / | + |/| Thermistor | Measured voltage (mv) + / | | "connected ground" + /| | | + +-+ | + |-------------------------o + +-+ ^ + | | | + | | Pull-down resistor | Measured voltage (mv) + | | (pdo) | "connected positive" + +-+ | + | | + | v + + GND GND + + The arrangements of where we measure the voltage over the thermistor are + called "connected ground" and "connected positive" and shall be understood as + the cases when either pull-up or pull-down resistance is zero. + + If the pull-up resistance is 0 one end of the thermistor is connected to the + positive voltage and we get the thermistor on top of a pull-down resistor + and we take the measure between the thermistor and the pull-down resistor. + + Conversely if the pull-down resistance is zero, one end of the thermistor is + connected to ground and we get the thermistor under the pull-up resistor + and we take the measure between the pull-up resistor and the thermistor. + + We can use both pull-up and pull-down resistors at the same time, and then + the figure illustrates where the voltage will be measured for the "connected + ground" and "connected positive" cases. + +properties: + $nodename: + pattern: "^thermistor(.*)?$" + + compatible: + oneOf: + - const: epcos,b57330v2103 + - const: epcos,b57891s0103 + - const: murata,ncp15wb473 + - const: murata,ncp18wb473 + - const: murata,ncp21wb473 + - const: murata,ncp03wb473 + - const: murata,ncp15wl333 + - const: murata,ncp03wf104 + - const: murata,ncp15xh103 + # Deprecated "ntp," compatible strings + - const: ntc,ncp15wb473 + deprecated: true + - const: ntc,ncp18wb473 + deprecated: true + - const: ntc,ncp21wb473 + deprecated: true + - const: ntc,ncp03wb473 + deprecated: true + - const: ntc,ncp15wl333 + deprecated: true + + "#thermal-sensor-cells": + description: Thermal sensor cells if used for thermal sensoring. + const: 0 + + pullup-uv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Pull-up voltage in micro volts. Must always be specified. + + pullup-ohm: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Pull-up resistance in ohms. Must always be specified, even + if zero. + + pulldown-ohm: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Pull-down resistance in ohms. Must always be specified, even + if zero. + + connected-positive: + $ref: /schemas/types.yaml#/definitions/flag + description: Indicates how the thermistor is connected in series with + a pull-up and/or a pull-down resistor. See the description above for + an illustration. If this flag is NOT specified, the thermistor is assumed + to be connected-ground, which usually means a pull-down resistance of + zero but complex arrangements are possible. + + # See /schemas/iio/adc/adc.yaml + io-channels: + maxItems: 1 + description: IIO ADC channel to read the voltage over the resistor. Must + always be specified. + +required: + - compatible + - pullup-uv + - pullup-ohm + - pulldown-ohm + - io-channels + +additionalProperties: false + +examples: + - | + thermistor0 { + compatible = "murata,ncp18wb473"; + io-channels = <&gpadc 0x06>; + pullup-uv = <1800000>; + pullup-ohm = <220000>; + pulldown-ohm = <0>; + #thermal-sensor-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt deleted file mode 100644 index 4c5c3712970e..000000000000 --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt +++ /dev/null @@ -1,44 +0,0 @@ -NTC Thermistor hwmon sensors -------------------------------- - -Requires node properties: -- "compatible" value : one of - "epcos,b57330v2103" - "epcos,b57891s0103" - "murata,ncp15wb473" - "murata,ncp18wb473" - "murata,ncp21wb473" - "murata,ncp03wb473" - "murata,ncp15wl333" - "murata,ncp03wf104" - "murata,ncp15xh103" - -/* Usage of vendor name "ntc" is deprecated */ -<DEPRECATED> "ntc,ncp15wb473" -<DEPRECATED> "ntc,ncp18wb473" -<DEPRECATED> "ntc,ncp21wb473" -<DEPRECATED> "ntc,ncp03wb473" -<DEPRECATED> "ntc,ncp15wl333" - -- "pullup-uv" Pull up voltage in micro volts -- "pullup-ohm" Pull up resistor value in ohms -- "pulldown-ohm" Pull down resistor value in ohms -- "connected-positive" Always ON, If not specified. - Status change is possible. -- "io-channels" Channel node of ADC to be used for - conversion. - -Optional node properties: -- "#thermal-sensor-cells" Used to expose itself to thermal fw. - -Read more about iio bindings at - https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/ - -Example: - ncp15wb473@0 { - compatible = "murata,ncp15wb473"; - pullup-uv = <1800000>; - pullup-ohm = <47000>; - pulldown-ohm = <0>; - io-channels = <&adc 3>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml new file mode 100644 index 000000000000..2f0620ecccc9 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml @@ -0,0 +1,145 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/hwmon/nuvoton,nct7802.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton NCT7802Y Hardware Monitoring IC + +maintainers: + - Guenter Roeck <linux@roeck-us.net> + +description: | + The NCT7802Y is a hardware monitor IC which supports one on-die and up to + 5 remote temperature sensors with SMBus interface. + + Datasheets: + https://www.nuvoton.com/export/resource-files/Nuvoton_NCT7802Y_Datasheet_V12.pdf + +additionalProperties: false + +properties: + compatible: + enum: + - nuvoton,nct7802 + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^channel@[0-3]$": + type: object + + additionalProperties: false + + properties: + reg: + items: + - enum: + - 0 # Local Temperature Sensor ("LTD") + - 1 # Remote Temperature Sensor or Voltage Sensor 1 ("RTD1") + - 2 # Remote Temperature Sensor or Voltage Sensor 2 ("RTD2") + - 3 # Remote Temperature Sensor or Voltage Sensor 3 ("RTD3") + + sensor-type: + items: + - enum: + - temperature + - voltage + + temperature-mode: + items: + - enum: + - thermistor + - thermal-diode + + required: + - reg + + allOf: + # For channels RTD1, RTD2 and RTD3, require sensor-type to be set. + # Otherwise (for all other channels), do not allow temperature-mode to be + # set. + - if: + properties: + reg: + items: + - enum: + - 1 + - 2 + - 3 + then: + required: + - sensor-type + else: + not: + required: + - sensor-type + + # For channels RTD1 and RTD2 and if sensor-type is "temperature", require + # temperature-mode to be set. Otherwise (for all other channels or + # sensor-type settings), do not allow temperature-mode to be set + - if: + properties: + reg: + items: + - enum: + - 1 + - 2 + sensor-type: + items: + - enum: + - temperature + then: + required: + - temperature-mode + else: + not: + required: + - temperature-mode + +required: + - compatible + - reg + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + nct7802@28 { + compatible = "nuvoton,nct7802"; + reg = <0x28>; + + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { /* LTD */ + reg = <0>; + }; + + channel@1 { /* RTD1 */ + reg = <1>; + sensor-type = "voltage"; + }; + + channel@2 { /* RTD2 */ + reg = <2>; + sensor-type = "temperature"; + temperature-mode = "thermal-diode"; + }; + + channel@3 { /* RTD3 */ + reg = <3>; + sensor-type = "temperature"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml new file mode 100644 index 000000000000..da8292bc32f5 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/hwmon/pmbus/ti,lm25066.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: National Semiconductor/Texas Instruments LM250x6/LM506x power-management ICs + +maintainers: + - Zev Weiss <zev@bewilderbeest.net> + +description: | + The LM25066 family of power-management ICs (a.k.a. hot-swap + controllers or eFuses in various contexts) are PMBus devices that + offer temperature, current, voltage, and power monitoring. + + Datasheet: https://www.ti.com/lit/ds/symlink/lm25066.pdf + +properties: + compatible: + enum: + - ti,lm25056 + - ti,lm25066 + - ti,lm5064 + - ti,lm5066 + - ti,lm5066i + + reg: + maxItems: 1 + + shunt-resistor-micro-ohms: + description: + Shunt (sense) resistor value in micro-Ohms + default: 1000 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@40 { + compatible = "ti,lm25066"; + reg = <0x40>; + shunt-resistor-micro-ohms = <675>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml new file mode 100644 index 000000000000..4669217d01e1 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/sensirion,sht15.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sensirion SHT15 humidity and temperature sensor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: sensirion,sht15 + + clk-gpios: + maxItems: 1 + + data-gpios: + maxItems: 1 + + vcc-supply: + description: regulator that drives the VCC pin + +required: + - compatible + - clk-gpios + - data-gpios + - vcc-supply + +additionalProperties: false + +examples: + - | + sensor { + compatible = "sensirion,sht15"; + clk-gpios = <&gpio4 12 0>; + data-gpios = <&gpio4 13 0>; + vcc-supply = <®_sht15>; + + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_sensor>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/sht15.txt b/Documentation/devicetree/bindings/hwmon/sht15.txt deleted file mode 100644 index 6a80277cc426..000000000000 --- a/Documentation/devicetree/bindings/hwmon/sht15.txt +++ /dev/null @@ -1,19 +0,0 @@ -Sensirion SHT15 Humidity and Temperature Sensor - -Required properties: - - - "compatible": must be "sensirion,sht15". - - "data-gpios": GPIO connected to the data line. - - "clk-gpios": GPIO connected to the clock line. - - "vcc-supply": regulator that drives the VCC pin. - -Example: - - sensor { - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_sensor>; - compatible = "sensirion,sht15"; - clk-gpios = <&gpio4 12 0>; - data-gpios = <&gpio4 13 0>; - vcc-supply = <®_sht15>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml new file mode 100644 index 000000000000..d3eff4fac107 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/ti,tmp102.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TMP102 temperature sensor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - ti,tmp102 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@48 { + compatible = "ti,tmp102"; + reg = <0x48>; + interrupt-parent = <&gpio7>; + interrupts = <16 IRQ_TYPE_LEVEL_LOW>; + #thermal-sensor-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml new file mode 100644 index 000000000000..eda55bbc172d --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/ti,tmp108.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TMP108 temperature sensor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - ti,tmp108 + + interrupts: + items: + - description: alert interrupt + + reg: + maxItems: 1 + + "#thermal-sensor-cells": + const: 0 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@48 { + compatible = "ti,tmp108"; + reg = <0x48>; + interrupt-parent = <&gpio1>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&tmp_alrt>; + #thermal-sensor-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml new file mode 100644 index 000000000000..36f649938fb7 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/ti,tmp421.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TMP42x/TMP44x temperature sensor + +maintainers: + - Guenter Roeck <linux@roeck-us.net> + +description: | + ±1°C Remote and Local temperature sensor + https://www.ti.com/lit/ds/symlink/tmp422.pdf + +properties: + compatible: + enum: + - ti,tmp421 + - ti,tmp422 + - ti,tmp423 + - ti,tmp441 + - ti,tmp442 + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + "^channel@([0-3])$": + type: object + description: | + Represents channels of the device and their specific configuration. + + properties: + reg: + description: | + The channel number. 0 is local channel, 1-3 are remote channels + items: + minimum: 0 + maximum: 3 + + label: + description: | + A descriptive name for this channel, like "ambient" or "psu". + + ti,n-factor: + description: | + The value (two's complement) to be programmed in the channel specific N correction register. + For remote channels only. + $ref: /schemas/types.yaml#/definitions/uint32 + items: + minimum: 0 + maximum: 255 + + required: + - reg + + additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4c { + compatible = "ti,tmp422"; + reg = <0x4c>; + }; + }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4c { + compatible = "ti,tmp422"; + reg = <0x4c>; + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0x0>; + ti,n-factor = <0x1>; + label = "local"; + }; + + channel@1 { + reg = <0x1>; + ti,n-factor = <0x0>; + label = "somelabel"; + }; + + channel@2 { + reg = <0x2>; + status = "disabled"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/tmp108.txt b/Documentation/devicetree/bindings/hwmon/tmp108.txt deleted file mode 100644 index 54d4beed4ee5..000000000000 --- a/Documentation/devicetree/bindings/hwmon/tmp108.txt +++ /dev/null @@ -1,18 +0,0 @@ -TMP108 temperature sensor -------------------------- - -This device supports I2C only. - -Requires node properties: -- compatible : "ti,tmp108" -- reg : the I2C address of the device. This is 0x48, 0x49, 0x4a, or 0x4b. - -Optional properties: -- interrupts: Reference to the TMP108 alert interrupt. -- #thermal-sensor-cells: should be set to 0. - -Example: - tmp108@48 { - compatible = "ti,tmp108"; - reg = <0x48>; - }; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml index 29de7807df54..bcd41e491f1d 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml @@ -31,11 +31,11 @@ properties: clocks: minItems: 1 - maxItems: 3 + maxItems: 7 clock-names: minItems: 1 - maxItems: 3 + maxItems: 7 required: - compatible @@ -72,6 +72,32 @@ allOf: contains: enum: - qcom,sdm660-a2noc + then: + properties: + clocks: + items: + - description: Bus Clock. + - description: Bus A Clock. + - description: IPA Clock. + - description: UFS AXI Clock. + - description: Aggregate2 UFS AXI Clock. + - description: Aggregate2 USB3 AXI Clock. + - description: Config NoC USB2 AXI Clock. + clock-names: + items: + - const: bus + - const: bus_a + - const: ipa + - const: ufs_axi + - const: aggre2_ufs_axi + - const: aggre2_usb3_axi + - const: cfg_noc_usb2_axi + + - if: + properties: + compatible: + contains: + enum: - qcom,sdm660-bimc - qcom,sdm660-cnoc - qcom,sdm660-gnoc @@ -91,6 +117,7 @@ examples: - | #include <dt-bindings/clock/qcom,rpmcc.h> #include <dt-bindings/clock/qcom,mmcc-sdm660.h> + #include <dt-bindings/clock/qcom,gcc-sdm660.h> bimc: interconnect@1008000 { compatible = "qcom,sdm660-bimc"; @@ -123,9 +150,20 @@ examples: compatible = "qcom,sdm660-a2noc"; reg = <0x01704000 0xc100>; #interconnect-cells = <1>; - clock-names = "bus", "bus_a"; + clock-names = "bus", + "bus_a", + "ipa", + "ufs_axi", + "aggre2_ufs_axi", + "aggre2_usb3_axi", + "cfg_noc_usb2_axi"; clocks = <&rpmcc RPM_SMD_AGGR2_NOC_CLK>, - <&rpmcc RPM_SMD_AGGR2_NOC_A_CLK>; + <&rpmcc RPM_SMD_AGGR2_NOC_A_CLK>, + <&rpmcc RPM_SMD_IPA_CLK>, + <&gcc GCC_UFS_AXI_CLK>, + <&gcc GCC_AGGRE2_UFS_AXI_CLK>, + <&gcc GCC_AGGRE2_USB3_AXI_CLK>, + <&gcc GCC_CFG_NOC_USB2_AXI_CLK>; }; mnoc: interconnect@1745000 { diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml new file mode 100644 index 000000000000..50003880ee6f --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/microchip,eic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip External Interrupt Controller + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: + This interrupt controller is found in Microchip SoCs (SAMA7G5) and provides + support for handling up to 2 external interrupt lines. + +properties: + compatible: + enum: + - microchip,sama7g5-eic + + reg: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + description: + The first cell is the input IRQ number (between 0 and 1), the second cell + is the trigger type as defined in interrupt.txt present in this directory. + + interrupts: + description: | + Contains the GIC SPI IRQs mapped to the external interrupt lines. They + should be specified sequentially from output 0 to output 1. + minItems: 2 + maxItems: 2 + + clocks: + maxItems: 1 + + clock-names: + const: pclk + +required: + - compatible + - reg + - interrupt-controller + - '#interrupt-cells' + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + eic: interrupt-controller@e1628000 { + compatible = "microchip,sama7g5-eic"; + reg = <0xe1628000 0x100>; + interrupt-parent = <&gic>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 37>; + clock-names = "pclk"; + }; + +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml index abb22db3bb28..79d0358e2f61 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml @@ -27,6 +27,7 @@ properties: - renesas,intc-ex-r8a774a1 # RZ/G2M - renesas,intc-ex-r8a774b1 # RZ/G2N - renesas,intc-ex-r8a774c0 # RZ/G2E + - renesas,intc-ex-r8a774e1 # RZ/G2H - renesas,intc-ex-r8a7795 # R-Car H3 - renesas,intc-ex-r8a7796 # R-Car M3-W - renesas,intc-ex-r8a77961 # R-Car M3-W+ diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt index 028268fd99ee..c9902fd4b38b 100644 --- a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt +++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt @@ -9,6 +9,7 @@ Required properties: - compatible : should be one of "aspeed,ast2400-ibt-bmc" "aspeed,ast2500-ibt-bmc" + "aspeed,ast2600-ibt-bmc" - reg: physical address and size of the registers Optional properties: diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml new file mode 100644 index 000000000000..93d8f8e88cf5 --- /dev/null +++ b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ipmi/ipmi-ipmb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IPMI IPMB device bindings + +description: IPMI IPMB device bindings + +maintainers: + - Corey Minyard <cminyard@mvista.com> + +properties: + compatible: + enum: + - ipmi-ipmb + + device_type: + items: + - const: "ipmi" + + reg: + maxItems: 1 + + bmcaddr: + $ref: /schemas/types.yaml#/definitions/uint8 + description: The address of the BMC on the IPMB bus. Defaults to 0x20. + + retry-time: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Time between retries of sends, in milliseconds. Defaults to 250. + + max-retries: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of retries before a failure is declared. Defaults to 1. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ipmi-ipmb@40 { + compatible = "ipmi-ipmb"; + device_type = "ipmi"; + reg = <0x40>; + bmcaddr = /bits/ 8 <0x20>; + retry-time = <250>; + max-retries = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml new file mode 100644 index 000000000000..2c1704b34e7a --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/apple,mailbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mailbox Controller + +maintainers: + - Hector Martin <marcan@marcan.st> + - Sven Peter <sven@svenpeter.dev> + +description: + The Apple mailbox consists of two FIFOs used to exchange 64+32 bit + messages between the main CPU and a co-processor. Multiple instances + of this mailbox can be found on Apple SoCs. + One of the two FIFOs is used to send data to a co-processor while the other + FIFO is used for the other direction. + Various clients implement different IPC protocols based on these simple + messages and shared memory buffers. + +properties: + compatible: + oneOf: + - description: + ASC mailboxes are the most common variant found on the M1 used + for example for the display controller, the system management + controller and the NVMe coprocessor. + items: + - const: apple,t8103-asc-mailbox + + - description: + M3 mailboxes are an older variant with a slightly different MMIO + interface still found on the M1. It is used for the Thunderbolt + co-processors. + items: + - const: apple,t8103-m3-mailbox + + reg: + maxItems: 1 + + interrupts: + items: + - description: send fifo is empty interrupt + - description: send fifo is not empty interrupt + - description: receive fifo is empty interrupt + - description: receive fifo is not empty interrupt + + interrupt-names: + items: + - const: send-empty + - const: send-not-empty + - const: recv-empty + - const: recv-not-empty + + "#mbox-cells": + const: 0 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + mailbox@77408000 { + compatible = "apple,t8103-asc-mailbox"; + reg = <0x77408000 0x4000>; + interrupts = <1 583 4>, <1 584 4>, <1 585 4>, <1 586 4>; + interrupt-names = "send-empty", "send-not-empty", + "recv-empty", "recv-not-empty"; + #mbox-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index 675ad9de15bb..a337bcd80c4a 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -28,6 +28,7 @@ properties: - const: fsl,imx7ulp-mu - const: fsl,imx8ulp-mu - const: fsl,imx8-mu-scu + - const: fsl,imx8ulp-mu-s4 - items: - enum: - fsl,imx7s-mu diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 6395281b0cec..01e9d9155c83 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -11,7 +11,7 @@ description: platforms. maintainers: - - Sivaprakash Murugesan <sivaprak@codeaurora.org> + - Jassi Brar <jassisinghbrar@gmail.com> properties: compatible: @@ -24,6 +24,7 @@ properties: - qcom,msm8994-apcs-kpss-global - qcom,msm8996-apcs-hmss-global - qcom,msm8998-apcs-hmss-global + - qcom,qcm2290-apcs-hmss-global - qcom,qcs404-apcs-apps-global - qcom,sc7180-apss-shared - qcom,sc8180x-apss-shared diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml index de15cebe2955..c19d8391e2d5 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml @@ -4,23 +4,24 @@ $id: http://devicetree.org/schemas/media/i2c/adv7604.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Analog Devices ADV7604/11/12 video decoder with HDMI receiver +title: Analog Devices ADV7604/10/11/12 video decoder with HDMI receiver maintainers: - Hans Verkuil <hverkuil-cisco@xs4all.nl> description: - The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated - HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog - input, and the ADV7611 has one HDMI input and no analog input. The 7612 is - similar to the 7611 but has 2 HDMI inputs. + The ADV7604 and ADV7610/11/12 are multiformat video decoders with + an integrated HDMI receiver. The ADV7604 has four multiplexed HDMI inputs + and one analog input, and the ADV7610/11 have one HDMI input and no analog + input. The ADV7612 is similar to the ADV7610/11 but has 2 HDMI inputs. - These device tree bindings support the ADV7611/12 only at the moment. + These device tree bindings support the ADV7610/11/12 only at the moment. properties: compatible: items: - enum: + - adi,adv7610 - adi,adv7611 - adi,adv7612 diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml new file mode 100644 index 000000000000..c2ba78116dbb --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/aptina,mt9p031.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: | + The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor + with an active array size of 2592H x 1944V. It is programmable through a + simple two-wire serial interface. + +properties: + compatible: + enum: + - aptina,mt9p031 + - aptina,mt9p031m + + reg: + description: I2C device address + maxItems: 1 + + clocks: + maxItems: 1 + + vdd-supply: + description: Digital supply voltage, 1.8 V + + vdd_io-supply: + description: I/O supply voltage, 1.8 or 2.8 V + + vaa-supply: + description: Analog supply voltage, 2.8 V + + reset-gpios: + maxItems: 1 + description: Chip reset GPIO + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + input-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 6000000 + maximum: 96000000 + description: Input clock frequency + + pixel-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 96000000 + description: Target pixel clock frequency + + pclk-sample: + default: 0 + + required: + - input-clock-frequency + - pixel-clock-frequency + +required: + - compatible + - reg + - clocks + - vdd-supply + - vdd_io-supply + - vaa-supply + - port + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + mt9p031@5d { + compatible = "aptina,mt9p031"; + reg = <0x5d>; + reset-gpios = <&gpio_sensor 0 0>; + + clocks = <&sensor_clk>; + + vdd-supply = <®_vdd>; + vdd_io-supply = <®_vdd_io>; + vaa-supply = <®_vaa>; + + port { + mt9p031_1: endpoint { + input-clock-frequency = <6000000>; + pixel-clock-frequency = <96000000>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml new file mode 100644 index 000000000000..85a8877c2f38 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/hynix,hi846.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SK Hynix Hi-846 1/4" 8M Pixel MIPI CSI-2 sensor + +maintainers: + - Martin Kepplinger <martin.kepplinger@puri.sm> + +description: |- + The Hi-846 is a raw image sensor with an MIPI CSI-2 image data + interface and CCI (I2C compatible) control bus. The output format + is raw Bayer. + +properties: + compatible: + const: hynix,hi846 + + reg: + maxItems: 1 + + clocks: + items: + - description: Reference to the mclk clock. + + assigned-clocks: + maxItems: 1 + + assigned-clock-rates: + maxItems: 1 + + reset-gpios: + description: Reference to the GPIO connected to the RESETB pin. Active low. + maxItems: 1 + + shutdown-gpios: + description: Reference to the GPIO connected to the XSHUTDOWN pin. Active low. + maxItems: 1 + + vddio-supply: + description: Definition of the regulator used for the VDDIO power supply. + + vdda-supply: + description: Definition of the regulator used for the VDDA power supply. + + vddd-supply: + description: Definition of the regulator used for the VDDD power supply. + + port: + $ref: /schemas/graph.yaml#/properties/port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + oneOf: + - items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + - items: + - const: 1 + - const: 2 + + required: + - data-lanes + +required: + - compatible + - reg + - clocks + - assigned-clocks + - assigned-clock-rates + - vddio-supply + - vdda-supply + - vddd-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + hi846: camera@20 { + compatible = "hynix,hi846"; + reg = <0x20>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_csi1>; + clocks = <&clk 0>; + assigned-clocks = <&clk 0>; + assigned-clock-rates = <25000000>; + vdda-supply = <®_camera_vdda>; + vddd-supply = <®_camera_vddd>; + vddio-supply = <®_camera_vddio>; + reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>; + shutdown-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>; + + port { + camera_out: endpoint { + remote-endpoint = <&csi1_ep1>; + link-frequencies = /bits/ 64 + <80000000 200000000>; + data-lanes = <1 2>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/i2c/mt9p031.txt b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt deleted file mode 100644 index cb60443ff78f..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/mt9p031.txt +++ /dev/null @@ -1,40 +0,0 @@ -* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor - -The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor with -an active array size of 2592H x 1944V. It is programmable through a simple -two-wire serial interface. - -Required Properties: -- compatible: value should be either one among the following - (a) "aptina,mt9p031" for mt9p031 sensor - (b) "aptina,mt9p031m" for mt9p031m sensor - -- input-clock-frequency: Input clock frequency. - -- pixel-clock-frequency: Pixel clock frequency. - -Optional Properties: -- reset-gpios: Chip reset GPIO - -For further reading on port node refer to -Documentation/devicetree/bindings/media/video-interfaces.txt. - -Example: - - i2c0@1c22000 { - ... - ... - mt9p031@5d { - compatible = "aptina,mt9p031"; - reg = <0x5d>; - reset-gpios = <&gpio3 30 0>; - - port { - mt9p031_1: endpoint { - input-clock-frequency = <6000000>; - pixel-clock-frequency = <96000000>; - }; - }; - }; - ... - }; diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml index 3e5d82df90a2..a2abed06a099 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml @@ -31,7 +31,7 @@ properties: maxItems: 1 port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml index ad42992c6da3..bf115ab9d926 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml @@ -38,7 +38,7 @@ properties: port: additionalProperties: false - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base properties: endpoint: diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml index 881f79532501..cf2ca2702cc9 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml @@ -38,7 +38,7 @@ properties: port: additionalProperties: false - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base properties: endpoint: diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml index 1edeabf39e6a..afcf70947f7e 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml @@ -38,7 +38,7 @@ properties: port: additionalProperties: false - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base properties: endpoint: diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt index ad1321e5a22d..665a9508708e 100644 --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt @@ -10,6 +10,8 @@ Required properties: "mediatek,mt8183-vcodec-enc" for MT8183 encoder. "mediatek,mt8173-vcodec-dec" for MT8173 decoder. "mediatek,mt8192-vcodec-enc" for MT8192 encoder. + "mediatek,mt8183-vcodec-dec" for MT8183 decoder. + "mediatek,mt8195-vcodec-enc" for MT8195 encoder. - reg : Physical base address of the video codec registers and length of memory mapped region. - interrupts : interrupt number to the cpu. diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml new file mode 100644 index 000000000000..fa54c560e0bd --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml @@ -0,0 +1,162 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/qcom,sc7280-venus.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Venus video encode and decode accelerators + +maintainers: + - Stanimir Varbanov <stanimir.varbanov@linaro.org> + +description: | + The Venus Iris2 IP is a video encode and decode accelerator present + on Qualcomm platforms + +properties: + compatible: + const: qcom,sc7280-venus + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + minItems: 2 + maxItems: 3 + + power-domain-names: + minItems: 2 + maxItems: 3 + items: + - const: venus + - const: vcodec0 + - const: cx + + clocks: + maxItems: 5 + + clock-names: + items: + - const: core + - const: bus + - const: iface + - const: vcodec_core + - const: vcodec_bus + + iommus: + maxItems: 2 + + memory-region: + maxItems: 1 + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: cpu-cfg + - const: video-mem + + video-decoder: + type: object + + properties: + compatible: + const: venus-decoder + + required: + - compatible + + additionalProperties: false + + video-encoder: + type: object + + properties: + compatible: + const: venus-encoder + + required: + - compatible + + additionalProperties: false + + video-firmware: + type: object + + description: | + Firmware subnode is needed when the platform does not + have TrustZone. + + properties: + iommus: + maxItems: 1 + + required: + - iommus + +required: + - compatible + - reg + - interrupts + - power-domains + - power-domain-names + - clocks + - clock-names + - iommus + - memory-region + - video-decoder + - video-encoder + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sc7280.h> + #include <dt-bindings/interconnect/qcom,sc7280.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + venus: video-codec@aa00000 { + compatible = "qcom,sc7280-venus"; + reg = <0x0aa00000 0xd0600>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&videocc VIDEO_CC_MVSC_CORE_CLK>, + <&videocc VIDEO_CC_MVSC_CTL_AXI_CLK>, + <&videocc VIDEO_CC_VENUS_AHB_CLK>, + <&videocc VIDEO_CC_MVS0_CORE_CLK>, + <&videocc VIDEO_CC_MVS0_AXI_CLK>; + clock-names = "core", "bus", "iface", + "vcodec_core", "vcodec_bus"; + + power-domains = <&videocc MVSC_GDSC>, + <&videocc MVS0_GDSC>, + <&rpmhpd SC7280_CX>; + power-domain-names = "venus", "vcodec0", "cx"; + + interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>, + <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>; + interconnect-names = "cpu-cfg", "video-mem"; + + iommus = <&apps_smmu 0x2180 0x20>, + <&apps_smmu 0x2184 0x20>; + + memory-region = <&video_mem>; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; + }; + + video-firmware { + iommus = <&apps_smmu 0x21a2 0x0>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml new file mode 100644 index 000000000000..33da7d3cfd38 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml @@ -0,0 +1,186 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/qcom,sdm660-venus.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Venus video encode and decode accelerators + +maintainers: + - Stanimir Varbanov <stanimir.varbanov@linaro.org> + - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> + +description: | + The Venus IP is a video encode and decode accelerator present + on Qualcomm platforms + +properties: + compatible: + const: qcom,sdm660-venus + + reg: + maxItems: 1 + + clocks: + maxItems: 4 + + clock-names: + items: + - const: core + - const: iface + - const: bus + - const: bus_throttle + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: cpu-cfg + - const: video-mem + + interrupts: + maxItems: 1 + + iommus: + maxItems: 20 + + memory-region: + maxItems: 1 + + power-domains: + maxItems: 1 + + video-decoder: + type: object + + properties: + compatible: + const: venus-decoder + + clocks: + maxItems: 1 + + clock-names: + items: + - const: vcodec0_core + + power-domains: + maxItems: 1 + + required: + - compatible + - clocks + - clock-names + - power-domains + + additionalProperties: false + + video-encoder: + type: object + + properties: + compatible: + const: venus-encoder + + clocks: + maxItems: 1 + + clock-names: + items: + - const: vcodec0_core + + power-domains: + maxItems: 1 + + required: + - compatible + - clocks + - clock-names + - power-domains + + additionalProperties: false + + video-firmware: + type: object + + description: | + Firmware subnode is needed when the platform does not + have TrustZone. + + properties: + iommus: + maxItems: 1 + + required: + - iommus + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - iommus + - memory-region + - power-domains + - video-decoder + - video-encoder + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,mmcc-sdm660.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + video-codec@cc00000 { + compatible = "qcom,sdm660-venus"; + reg = <0x0cc00000 0xff000>; + clocks = <&mmcc VIDEO_CORE_CLK>, + <&mmcc VIDEO_AHB_CLK>, + <&mmcc VIDEO_AXI_CLK>, + <&mmcc THROTTLE_VIDEO_AXI_CLK>; + clock-names = "core", "iface", "bus", "bus_throttle"; + interconnects = <&gnoc 0 &mnoc 13>, + <&mnoc 4 &bimc 5>; + interconnect-names = "cpu-cfg", "video-mem"; + interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; + iommus = <&mmss_smmu 0x400>, + <&mmss_smmu 0x401>, + <&mmss_smmu 0x40a>, + <&mmss_smmu 0x407>, + <&mmss_smmu 0x40e>, + <&mmss_smmu 0x40f>, + <&mmss_smmu 0x408>, + <&mmss_smmu 0x409>, + <&mmss_smmu 0x40b>, + <&mmss_smmu 0x40c>, + <&mmss_smmu 0x40d>, + <&mmss_smmu 0x410>, + <&mmss_smmu 0x421>, + <&mmss_smmu 0x428>, + <&mmss_smmu 0x429>, + <&mmss_smmu 0x42b>, + <&mmss_smmu 0x42c>, + <&mmss_smmu 0x42d>, + <&mmss_smmu 0x411>, + <&mmss_smmu 0x431>; + memory-region = <&venus_region>; + power-domains = <&mmcc VENUS_GDSC>; + + video-decoder { + compatible = "venus-decoder"; + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; + clock-names = "vcodec0_core"; + power-domains = <&mmcc VENUS_CORE0_GDSC>; + }; + + video-encoder { + compatible = "venus-encoder"; + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; + clock-names = "vcodec0_core"; + power-domains = <&mmcc VENUS_CORE0_GDSC>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml index 23703b767f5b..e6a036721082 100644 --- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml +++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml @@ -30,6 +30,7 @@ properties: - renesas,r8a77970-csi2 # R-Car V3M - renesas,r8a77980-csi2 # R-Car V3H - renesas,r8a77990-csi2 # R-Car E3 + - renesas,r8a779a0-csi2 # R-Car V3U reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/renesas,imr.txt b/Documentation/devicetree/bindings/media/renesas,imr.txt deleted file mode 100644 index b0614153ed36..000000000000 --- a/Documentation/devicetree/bindings/media/renesas,imr.txt +++ /dev/null @@ -1,31 +0,0 @@ -Renesas R-Car Image Renderer (Distortion Correction Engine) ------------------------------------------------------------ - -The image renderer, or the distortion correction engine, is a drawing processor -with a simple instruction system capable of referencing video capture data or -data in an external memory as 2D texture data and performing texture mapping -and drawing with respect to any shape that is split into triangular objects. - -Required properties: - -- compatible: "renesas,<soctype>-imr-lx4", "renesas,imr-lx4" as a fallback for - the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs, - where the examples with <soctype> are: - - "renesas,r8a7795-imr-lx4" for R-Car H3, - - "renesas,r8a7796-imr-lx4" for R-Car M3-W. -- reg: offset and length of the register block; -- interrupts: single interrupt specifier; -- clocks: single clock phandle/specifier pair; -- power-domains: power domain phandle/specifier pair; -- resets: reset phandle/specifier pair. - -Example: - - imr-lx4@fe860000 { - compatible = "renesas,r8a7795-imr-lx4", "renesas,imr-lx4"; - reg = <0 0xfe860000 0 0x2000>; - interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 823>; - power-domains = <&sysc R8A7795_PD_A3VC>; - resets = <&cpg 823>; - }; diff --git a/Documentation/devicetree/bindings/media/renesas,imr.yaml b/Documentation/devicetree/bindings/media/renesas,imr.yaml new file mode 100644 index 000000000000..512f57417fd8 --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,imr.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/renesas,imr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car Image Renderer (Distortion Correction Engine) + +maintainers: + - Sergei Shtylyov <sergei.shtylyov@gmail.com> + +description: | + The image renderer, or the distortion correction engine, is a drawing + processor with a simple instruction system capable of referencing video + capture data or data in an external memory as 2D texture data and performing + texture mapping and drawing with respect to any shape that is split into + triangular objects. + + The image renderer light extended 4 (IMR-LX4) is found in R-Car Gen3 SoCs. + +properties: + compatible: + items: + - enum: + - renesas,r8a7795-imr-lx4 # R-Car H3 + - renesas,r8a7796-imr-lx4 # R-Car M3-W + - const: renesas,imr-lx4 # R-Car Gen3 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + imr-lx4@fe860000 { + compatible = "renesas,r8a7795-imr-lx4", "renesas,imr-lx4"; + reg = <0xfe860000 0x2000>; + interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 823>; + power-domains = <&sysc R8A7795_PD_A3VC>; + resets = <&cpg 823>; + }; diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml index a6b1eff879ed..d1489b177331 100644 --- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml @@ -15,13 +15,22 @@ description: | properties: compatible: - const: rockchip,rk3399-cif-isp + enum: + - rockchip,px30-cif-isp + - rockchip,rk3399-cif-isp reg: maxItems: 1 interrupts: - maxItems: 1 + minItems: 1 + maxItems: 3 + + interrupt-names: + items: + - const: isp + - const: mi + - const: mipi clocks: minItems: 3 @@ -41,7 +50,7 @@ properties: - const: aclk - const: hclk # only for isp1 - - const: pclk_isp + - const: pclk iommus: maxItems: 1 @@ -90,19 +99,29 @@ required: - power-domains - ports -if: - properties: - compatible: - contains: - const: rockchip,rk3399-cif-isp -then: - properties: - clocks: - minItems: 3 - maxItems: 4 - clock-names: - minItems: 3 - maxItems: 4 +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3399-cif-isp + then: + properties: + clocks: + minItems: 3 + maxItems: 4 + clock-names: + minItems: 3 + maxItems: 4 + + - if: + properties: + compatible: + contains: + const: rockchip,px30-cif-isp + then: + required: + - interrupt-names additionalProperties: false @@ -183,3 +202,66 @@ examples: }; }; }; + + - | + + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/px30-power.h> + + parent1: parent { + #address-cells = <2>; + #size-cells = <2>; + + isp: isp@ff4a0000 { + compatible = "rockchip,px30-cif-isp"; + reg = <0x0 0xff4a0000 0x0 0x8000>; + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "isp", "mi", "mipi"; + clocks = <&cru SCLK_ISP0>, + <&cru ACLK_ISP0_WRAPPER>, + <&cru HCLK_ISP0_WRAPPER>, + <&cru PCLK_ISP1_WRAPPER>; + clock-names = "isp", "aclk", "hclk", "pclk"; + iommus = <&isp_mmu>; + phys = <&csi_dphy>; + phy-names = "dphy"; + power-domains = <&power PX30_PD_VI>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + mipi_in_ucam1: endpoint@0 { + reg = <0>; + remote-endpoint = <&ucam1_out>; + data-lanes = <1 2>; + }; + }; + }; + }; + + i2c2: i2c { + #address-cells = <1>; + #size-cells = <0>; + + ov5695: camera@36 { + compatible = "ovti,ov5647"; + reg = <0x36>; + clocks = <&cru SCLK_CIF_OUT>; + + port { + ucam1_out: endpoint { + remote-endpoint = <&mipi_in_ucam1>; + data-lanes = <1 2>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml index fc1317ab3226..28ac60acf4ac 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml @@ -32,13 +32,13 @@ properties: "#size-cells": const: 1 - pinctrl: - $ref: ../pinctrl/brcm,ns-pinmux.yaml - patternProperties: '^clock-controller@[a-f0-9]+$': $ref: ../clock/brcm,iproc-clocks.yaml + '^pin-controller@[a-f0-9]+$': + $ref: ../pinctrl/brcm,ns-pinmux.yaml + '^thermal@[a-f0-9]+$': $ref: ../thermal/brcm,ns-thermal.yaml @@ -73,9 +73,10 @@ examples: "iprocfast", "sata1", "sata2"; }; - pinctrl { + pin-controller@1c0 { compatible = "brcm,bcm4708-pinmux"; - offset = <0x1c0>; + reg = <0x1c0 0x24>; + reg-names = "cru_gpio_control"; }; thermal@2c0 { diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml index 37a5fe7b26dc..de6f076e0ece 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml @@ -88,6 +88,12 @@ properties: description: For this device it is strongly suggested to include arasan,soc-ctl-syscon. + - items: + - const: intel,thunderbay-sdhci-5.1 # Intel Thunder Bay eMMC PHY + - const: arasan,sdhci-5.1 + description: + For this device it is strongly suggested to include + clock-output-names and '#clock-cells'. reg: maxItems: 1 @@ -153,7 +159,6 @@ properties: The MIO bank number in which the command and data lines are configured. dependencies: - clock-output-names: [ '#clock-cells' ] '#clock-cells': [ clock-output-names ] required: @@ -301,3 +306,22 @@ examples: <&scmi_clk KEEM_BAY_PSS_SD0>; arasan,soc-ctl-syscon = <&sd0_phy_syscon>; }; + + - | + #define EMMC_XIN_CLK + #define EMMC_AXI_CLK + #define TBH_PSS_EMMC_RST_N + mmc@80420000 { + compatible = "intel,thunderbay-sdhci-5.1", "arasan,sdhci-5.1"; + interrupts = <GIC_SPI 714 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x80420000 0x400>; + clocks = <&scmi_clk EMMC_XIN_CLK>, + <&scmi_clk EMMC_AXI_CLK>; + clock-names = "clk_xin", "clk_ahb"; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + assigned-clocks = <&scmi_clk EMMC_XIN_CLK>; + clock-output-names = "emmc_cardclock"; + resets = <&rst_pss1 TBH_PSS_EMMC_RST_N>; + #clock-cells = <0x0>; + }; diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml index af7442f73881..4207fed62dfe 100644 --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml @@ -17,6 +17,7 @@ properties: compatible: items: - enum: + - microchip,mpfs-sd4hc - socionext,uniphier-sd4hc - const: cdns,sd4hc diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index a3412f221104..19621a2f8beb 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -34,6 +34,7 @@ properties: - fsl,imx6ull-usdhc - fsl,imx7d-usdhc - fsl,imx7ulp-usdhc + - nxp,s32g2-usdhc - items: - enum: - fsl,imx8mm-usdhc diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt b/Documentation/devicetree/bindings/mmc/mmc-card.txt deleted file mode 100644 index 8d2d71758907..000000000000 --- a/Documentation/devicetree/bindings/mmc/mmc-card.txt +++ /dev/null @@ -1,30 +0,0 @@ -mmc-card / eMMC bindings ------------------------- - -This documents describes the devicetree bindings for a mmc-host controller -child node describing a mmc-card / an eMMC, see "Use of Function subnodes" -in mmc.txt - -Required properties: --compatible : Must be "mmc-card" --reg : Must be <0> - -Optional properties: --broken-hpi : Use this to indicate that the mmc-card has a broken hpi - implementation, and that hpi should not be used - -Example: - -&mmc2 { - pinctrl-names = "default"; - pinctrl-0 = <&mmc2_pins_a>; - vmmc-supply = <®_vcc3v3>; - bus-width = <8>; - non-removable; - - mmccard: mmccard@0 { - reg = <0>; - compatible = "mmc-card"; - broken-hpi; - }; -}; diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml new file mode 100644 index 000000000000..b17d454442b3 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MMC Card / eMMC Generic Device Tree Bindings + +maintainers: + - Ulf Hansson <ulf.hansson@linaro.org> + +description: | + This documents describes the devicetree bindings for a mmc-host controller + child node describing a mmc-card / an eMMC. + +properties: + compatible: + const: mmc-card + + reg: + const: 0 + + broken-hpi: + $ref: /schemas/types.yaml#/definitions/flag + description: + Use this to indicate that the mmc-card has a broken hpi + implementation, and that hpi should not be used. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + mmc { + #address-cells = <1>; + #size-cells = <0>; + + card@0 { + compatible = "mmc-card"; + reg = <0>; + broken-hpi; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index 25ac8e200970..513f3c8758aa 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -333,12 +333,6 @@ patternProperties: subnode describes. A value of 0 denotes the memory SD function, values from 1 to 7 denote the SDIO functions. - broken-hpi: - $ref: /schemas/types.yaml#/definitions/flag - description: - Use this to indicate that the mmc-card has a broken hpi - implementation, and that hpi should not be used. - required: - reg diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index e866e985549e..82768a807294 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -119,6 +119,18 @@ properties: If present, HS400 command responses are sampled on rising edges. If not present, HS400 command responses are sampled on falling edges. + mediatek,hs400-ds-dly3: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Gear of the third delay line for DS for input data latch in data + pad macro, there are 32 stages from 0 to 31. + For different corner IC, the time is different about one step, it is + about 100ps. + The value is confirmed by doing scan and calibration to find a best + value with corner IC and it is valid only for HS400 mode. + minimum: 0 + maximum: 31 + mediatek,latch-ck: $ref: /schemas/types.yaml#/definitions/uint32 description: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 365c3fc122ea..50841e2843fc 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -13,6 +13,7 @@ Required properties: string is added to support this change - "qcom,sdhci-msm-v5". full compatible strings with SoC and version: "qcom,apq8084-sdhci", "qcom,sdhci-msm-v4" + "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8974-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8916-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8992-sdhci", "qcom,sdhci-msm-v4" diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt index aeb615ef672a..f91e341e6b36 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt @@ -5,7 +5,11 @@ Refer to mmc.txt for standard MMC bindings. For UHS devices which require tuning, the device tree should have a "cpu_thermal" node which maps to the appropriate thermal zone. This is used to get the temperature of the zone during tuning. Required properties: -- compatible: Should be "ti,dra7-sdhci" for DRA7 and DRA72 controllers +- compatible: Should be "ti,omap2430-sdhci" for omap2430 controllers + Should be "ti,omap3-sdhci" for omap3 controllers + Should be "ti,omap4-sdhci" for omap4 and ti81 controllers + Should be "ti,omap5-sdhci" for omap5 controllers + Should be "ti,dra7-sdhci" for DRA7 and DRA72 controllers Should be "ti,k2g-sdhci" for K2G Should be "ti,am335-sdhci" for am335x controllers Should be "ti,am437-sdhci" for am437x controllers @@ -24,6 +28,9 @@ Optional properties: DMA specifiers listed in dmas. The string naming is to be "tx" and "rx" for TX and RX DMA requests, respectively. +Deprecated properties: +- ti,non-removable: Compatible with the generic non-removable property + Example: mmc1: mmc@4809c000 { compatible = "ti,dra7-sdhci"; diff --git a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml index e6c9a2f77cc7..f300ced4cdf3 100644 --- a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml @@ -20,9 +20,7 @@ properties: - snps,dwcmshc-sdhci reg: - minItems: 1 - items: - - description: Offset and length of the register set for the device + maxItems: 1 interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt index 30c11fea491b..2363b412410c 100644 --- a/Documentation/devicetree/bindings/net/dsa/marvell.txt +++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt @@ -83,7 +83,7 @@ Example: #interrupt-cells = <2>; switch0: switch@0 { - compatible = "marvell,mv88e6390"; + compatible = "marvell,mv88e6190"; reg = <0>; reset-gpios = <&gpio5 1 GPIO_ACTIVE_LOW>; diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml index 5629b2e4ccf8..ee4afe361fac 100644 --- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -34,7 +34,6 @@ properties: clocks: minItems: 3 - maxItems: 5 items: - description: MAC host clock - description: MAC apb clock diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 42689b7d03a2..c115c95ee584 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -21,6 +21,7 @@ select: contains: enum: - snps,dwmac + - snps,dwmac-3.40a - snps,dwmac-3.50a - snps,dwmac-3.610 - snps,dwmac-3.70a @@ -76,6 +77,7 @@ properties: - rockchip,rk3399-gmac - rockchip,rv1108-gmac - snps,dwmac + - snps,dwmac-3.40a - snps,dwmac-3.50a - snps,dwmac-3.610 - snps,dwmac-3.70a diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index 2911e565b260..acea1cd444fd 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -41,7 +41,6 @@ properties: - description: builtin MSI controller. interrupt-names: - minItems: 1 items: - const: msi diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml index 470aff599c27..fc39e3e9f71c 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml @@ -17,9 +17,6 @@ description: A list of pins varies across chipsets so few bindings are available. - Node of the pinmux must be nested in the CRU (Central Resource Unit) "syscon" - node. - properties: compatible: enum: @@ -27,10 +24,11 @@ properties: - brcm,bcm4709-pinmux - brcm,bcm53012-pinmux - offset: - description: offset of pin registers in the CRU block + reg: maxItems: 1 - $ref: /schemas/types.yaml#/definitions/uint32-array + + reg-names: + const: cru_gpio_control patternProperties: '-pins$': @@ -72,23 +70,20 @@ allOf: uart1_grp ] required: - - offset + - reg + - reg-names additionalProperties: false examples: - | - cru@1800c100 { - compatible = "syscon", "simple-mfd"; - reg = <0x1800c100 0x1a4>; - - pinctrl { - compatible = "brcm,bcm4708-pinmux"; - offset = <0xc0>; - - spi-pins { - function = "spi"; - groups = "spi_grp"; - }; + pin-controller@1800c1c0 { + compatible = "brcm,bcm4708-pinmux"; + reg = <0x1800c1c0 0x24>; + reg-names = "cru_gpio_control"; + + spi-pins { + function = "spi"; + groups = "spi_grp"; }; }; diff --git a/Documentation/devicetree/bindings/regulator/max8952.txt b/Documentation/devicetree/bindings/regulator/max8952.txt deleted file mode 100644 index 866fcdd0f4eb..000000000000 --- a/Documentation/devicetree/bindings/regulator/max8952.txt +++ /dev/null @@ -1,52 +0,0 @@ -Maxim MAX8952 voltage regulator - -Required properties: -- compatible: must be equal to "maxim,max8952" -- reg: I2C slave address, usually 0x60 -- max8952,dvs-mode-microvolt: array of 4 integer values defining DVS voltages - in microvolts. All values must be from range <770000, 1400000> -- any required generic properties defined in regulator.txt - -Optional properties: -- max8952,vid-gpios: array of two GPIO pins used for DVS voltage selection -- max8952,en-gpio: GPIO used to control enable status of regulator -- max8952,default-mode: index of default DVS voltage, from <0, 3> range -- max8952,sync-freq: sync frequency, must be one of following values: - - 0: 26 MHz - - 1: 13 MHz - - 2: 19.2 MHz - Defaults to 26 MHz if not specified. -- max8952,ramp-speed: voltage ramp speed, must be one of following values: - - 0: 32mV/us - - 1: 16mV/us - - 2: 8mV/us - - 3: 4mV/us - - 4: 2mV/us - - 5: 1mV/us - - 6: 0.5mV/us - - 7: 0.25mV/us - Defaults to 32mV/us if not specified. -- any available generic properties defined in regulator.txt - -Example: - - vdd_arm_reg: pmic@60 { - compatible = "maxim,max8952"; - reg = <0x60>; - - /* max8952-specific properties */ - max8952,vid-gpios = <&gpx0 3 0>, <&gpx0 4 0>; - max8952,en-gpio = <&gpx0 1 0>; - max8952,default-mode = <0>; - max8952,dvs-mode-microvolt = <1250000>, <1200000>, - <1050000>, <950000>; - max8952,sync-freq = <0>; - max8952,ramp-speed = <0>; - - /* generic regulator properties */ - regulator-name = "vdd_arm"; - regulator-min-microvolt = <770000>; - regulator-max-microvolt = <1400000>; - regulator-always-on; - regulator-boot-on; - }; diff --git a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt deleted file mode 100644 index c2c68fcc1b41..000000000000 --- a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt +++ /dev/null @@ -1,52 +0,0 @@ -* Maxim MAX8973 Voltage Regulator - -Required properties: - -- compatible: must be one of following: - "maxim,max8973" - "maxim,max77621". -- reg: the i2c slave address of the regulator. It should be 0x1b. - -Any standard regulator properties can be used to configure the single max8973 -DCDC. - -Optional properties: - --maxim,externally-enable: boolean, externally control the regulator output - enable/disable. --maxim,enable-gpio: GPIO for enable control. If the valid GPIO is provided - then externally enable control will be considered. --maxim,dvs-gpio: GPIO which is connected to DVS pin of device. --maxim,dvs-default-state: Default state of GPIO during initialisation. - 1 for HIGH and 0 for LOW. --maxim,enable-remote-sense: boolean, enable reote sense. --maxim,enable-falling-slew-rate: boolean, enable falling slew rate. --maxim,enable-active-discharge: boolean: enable active discharge. --maxim,enable-frequency-shift: boolean, enable 9% frequency shift. --maxim,enable-bias-control: boolean, enable bias control. By enabling this - startup delay can be reduce to 20us from 220us. --maxim,enable-etr: boolean, enable Enhanced Transient Response. --maxim,enable-high-etr-sensitivity: boolean, Enhanced transient response - circuit is enabled and set for high sensitivity. If this - property is available then etr will be enable default. - -Enhanced transient response (ETR) will affect the configuration of CKADV. - --junction-warn-millicelsius: u32, junction warning temperature threshold - in millicelsius. If die temperature crosses this level then - device generates the warning interrupts. - -Please note that thermal functionality is only supported on MAX77621. The -supported threshold warning temperature for MAX77621 are 120 degC and 140 degC. - -Example: - - max8973@1b { - compatible = "maxim,max8973"; - reg = <0x1b>; - - regulator-min-microvolt = <935000>; - regulator-max-microvolt = <1200000>; - regulator-boot-on; - regulator-always-on; - }; diff --git a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt deleted file mode 100644 index b53c5e2b335f..000000000000 --- a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt +++ /dev/null @@ -1,145 +0,0 @@ -* Maxim MAX8997 Voltage and Current Regulator - -The Maxim MAX8997 is a multi-function device which includes voltage and -current regulators, rtc, charger controller and other sub-blocks. It is -interfaced to the host controller using a i2c interface. Each sub-block is -addressed by the host system using different i2c slave address. This document -describes the bindings for 'pmic' sub-block of max8997. - -Required properties: -- compatible: Should be "maxim,max8997-pmic". -- reg: Specifies the i2c slave address of the pmic block. It should be 0x66. - -- max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck1 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - -- max8997,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck2 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - -- max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck5 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - -[1] If none of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional - property is specified, the 'max8997,pmic-buck[1/2/5]-dvs-voltage' - property should specify atleast one voltage level (which would be a - safe operating voltage). - - If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional - property is specified, then all the eight voltage values for the - 'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified. - -Optional properties: -- interrupts: Interrupt specifiers for two interrupt sources. - - First interrupt specifier is for 'irq1' interrupt. - - Second interrupt specifier is for 'alert' interrupt. -- charger-supply: regulator node for charging current. -- max8997,pmic-buck1-uses-gpio-dvs: 'buck1' can be controlled by gpio dvs. -- max8997,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs. -- max8997,pmic-buck5-uses-gpio-dvs: 'buck5' can be controlled by gpio dvs. - -Additional properties required if either of the optional properties are used: -- max8997,pmic-ignore-gpiodvs-side-effect: When GPIO-DVS mode is used for - multiple bucks, changing the voltage value of one of the bucks may affect - that of another buck, which is the side effect of the change (set_voltage). - Use this property to ignore such side effects and change the voltage. - -- max8997,pmic-buck125-default-dvs-idx: Default voltage setting selected from - the possible 8 options selectable by the dvs gpios. The value of this - property should be between 0 and 7. If not specified or if out of range, the - default value of this property is set to 0. - -- max8997,pmic-buck125-dvs-gpios: GPIO specifiers for three host gpio's used - for dvs. The format of the gpio specifier depends in the gpio controller. - -Regulators: The regulators of max8997 that have to be instantiated should be -included in a sub-node named 'regulators'. Regulator nodes included in this -sub-node should be of the format as listed below. - - regulator_name { - standard regulator bindings here - }; - -The following are the names of the regulators that the max8997 pmic block -supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number -as per the datasheet of max8997. - - - LDOn - - valid values for n are 1 to 18 and 21 - - Example: LDO0, LD01, LDO2, LDO21 - - BUCKn - - valid values for n are 1 to 7. - - Example: BUCK1, BUCK2, BUCK3, BUCK7 - - - ENVICHG: Battery Charging Current Monitor Output. This is a fixed - voltage type regulator - - - ESAFEOUT1: (ldo19) - - ESAFEOUT2: (ld020) - - - CHARGER_CV: main battery charger voltage control - - CHARGER: main battery charger current control - - CHARGER_TOPOFF: end of charge current threshold level - -The bindings inside the regulator nodes use the standard regulator bindings -which are documented elsewhere. - -Example: - - max8997_pmic@66 { - compatible = "maxim,max8997-pmic"; - interrupt-parent = <&wakeup_eint>; - reg = <0x66>; - interrupts = <4 0>, <3 0>; - - max8997,pmic-buck1-uses-gpio-dvs; - max8997,pmic-buck2-uses-gpio-dvs; - max8997,pmic-buck5-uses-gpio-dvs; - - max8997,pmic-ignore-gpiodvs-side-effect; - max8997,pmic-buck125-default-dvs-idx = <0>; - - max8997,pmic-buck125-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */ - <&gpx0 1 1 0 0>, /* SET2 */ - <&gpx0 2 1 0 0>; /* SET3 */ - - max8997,pmic-buck1-dvs-voltage = <1350000>, <1300000>, - <1250000>, <1200000>, - <1150000>, <1100000>, - <1000000>, <950000>; - - max8997,pmic-buck2-dvs-voltage = <1100000>, <1100000>, - <1100000>, <1100000>, - <1000000>, <1000000>, - <1000000>, <1000000>; - - max8997,pmic-buck5-dvs-voltage = <1200000>, <1200000>, - <1200000>, <1200000>, - <1200000>, <1200000>, - <1200000>, <1200000>; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "VDD_ABB_3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - ldo2_reg: LDO2 { - regulator-name = "VDD_ALIVE_1.1V"; - regulator-min-microvolt = <1100000>; - regulator-max-microvolt = <1100000>; - regulator-always-on; - }; - - buck1_reg: BUCK1 { - regulator-name = "VDD_ARM_1.2V"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8952.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8952.yaml new file mode 100644 index 000000000000..e4e8c58f6046 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max8952.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max8952.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX8952 voltage regulator + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + const: maxim,max8952 + + max8952,default-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + description: | + index of default DVS voltage + + max8952,dvs-mode-microvolt: + minItems: 4 + maxItems: 4 + items: + minimum: 770000 + maximum: 1400000 + description: | + Array of 4 integer values defining DVS voltages in microvolts. All values + must be from range <770000, 1400000>. + + max8952,en-gpio: + maxItems: 1 + description: | + GPIO used to control enable status of regulator + + max8952,ramp-speed: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + default: 0 + description: | + Voltage ramp speed, values map to: + - 0: 32mV/us + - 1: 16mV/us + - 2: 8mV/us + - 3: 4mV/us + - 4: 2mV/us + - 5: 1mV/us + - 6: 0.5mV/us + - 7: 0.25mV/us + Defaults to 32mV/us if not specified. + + max8952,sync-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + default: 0 + description: | + Sync frequency, values map to: + - 0: 26 MHz + - 1: 13 MHz + - 2: 19.2 MHz + Defaults to 26 MHz if not specified. + + max8952,vid-gpios: + minItems: 2 + maxItems: 2 + description: | + Array of two GPIO pins used for DVS voltage selection + + reg: + maxItems: 1 + +required: + - compatible + - max8952,dvs-mode-microvolt + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@60 { + compatible = "maxim,max8952"; + reg = <0x60>; + + max8952,vid-gpios = <&gpx0 3 GPIO_ACTIVE_HIGH>, + <&gpx0 4 GPIO_ACTIVE_HIGH>; + max8952,default-mode = <0>; + max8952,dvs-mode-microvolt = <1250000>, <1200000>, + <1050000>, <950000>; + max8952,sync-freq = <0>; + max8952,ramp-speed = <0>; + + regulator-name = "VARM_1.2V_C210"; + regulator-min-microvolt = <770000>; + regulator-max-microvolt = <1400000>; + regulator-always-on; + regulator-boot-on; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml new file mode 100644 index 000000000000..54522827265b --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml @@ -0,0 +1,139 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max8973.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX8973/MAX77621 voltage regulator + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - maxim,max8973 + - maxim,max77621 + + junction-warn-millicelsius: + description: | + Junction warning temperature threshold in millicelsius. If die + temperature crosses this level then device generates the warning + interrupts. + Please note that thermal functionality is only supported on MAX77621. The + supported threshold warning temperature for MAX77621 are 120 degC and 140 + degC. + + maxim,dvs-gpio: + maxItems: 1 + description: | + GPIO which is connected to DVS pin of device. + + maxim,dvs-default-state: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + Default state of GPIO during initialisation. + 1 for HIGH and 0 for LOW. + + maxim,externally-enable: + type: boolean + description: | + Externally control the regulator output enable/disable. + + maxim,enable-gpio: + maxItems: 1 + description: | + GPIO for enable control. If the valid GPIO is provided then externally + enable control will be considered. + + maxim,enable-remote-sense: + type: boolean + description: Enable remote sense. + + maxim,enable-falling-slew-rate: + type: boolean + description: Enable falling slew rate. + + maxim,enable-active-discharge: + type: boolean + description: Eable active discharge. + + maxim,enable-frequency-shift: + type: boolean + description: Enable 9% frequency shift. + + maxim,enable-bias-control: + type: boolean + description: | + Enable bias control which can reduce the startup delay to 20us from 220us. + + maxim,enable-etr: + type: boolean + description: Enable Enhanced Transient Response. + + maxim,enable-high-etr-sensitivity: + type: boolean + description: | + Enhanced transient response circuit is enabled and set for high + sensitivity. If this property is available then etr will be enable + default. + Enhanced transient response (ETR) will affect the configuration of CKADV. + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@1b { + compatible = "maxim,max8973"; + reg = <0x1b>; + + regulator-min-microvolt = <935000>; + regulator-max-microvolt = <1200000>; + regulator-boot-on; + regulator-always-on; + }; + }; + + - | + #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@1b { + compatible = "maxim,max77621"; + reg = <0x1b>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(Y, 1) IRQ_TYPE_LEVEL_LOW>; + + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1231250>; + regulator-name = "PPVAR_CPU"; + regulator-ramp-delay = <12500>; + maxim,dvs-default-state = <1>; + maxim,enable-active-discharge; + maxim,enable-bias-control; + maxim,enable-etr; + maxim,enable-gpio = <&pmic 5 GPIO_ACTIVE_HIGH>; + maxim,externally-enable; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8997.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8997.yaml new file mode 100644 index 000000000000..d5a44ca3df04 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max8997.yaml @@ -0,0 +1,445 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max8997.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX8997 Power Management IC + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + The Maxim MAX8997 is a Power Management IC which includes voltage and current + regulators, charger controller with fuel gauge, RTC, clock outputs, haptic + motor driver, flash LED driver and Micro-USB Interface Controller. + + The binding here is not complete and describes only regulator and charger + controller parts. + +properties: + compatible: + const: maxim,max8997-pmic + + charger-supply: + description: | + Regulator node for charging current. + + interrupts: + items: + - description: irq1 interrupt + - description: alert interrupt + + max8997,pmic-buck1-dvs-voltage: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + description: | + A set of 8 voltage values in micro-volt (uV) units for buck1 when + changing voltage using GPIO DVS. + If none of max8997,pmic-buck[1/2/5]-uses-gpio-dvs optional property is + specified, the max8997,pmic-buck[1/2/5]-dvs-voltage property should + specify at least one voltage level (which would be a safe operating + voltage). + + max8997,pmic-buck2-dvs-voltage: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + description: | + A set of 8 voltage values in micro-volt (uV) units for buck2 when + changing voltage using GPIO DVS. + If none of max8997,pmic-buck[1/2/5]-uses-gpio-dvs optional property is + specified, the max8997,pmic-buck[1/2/5]-dvs-voltage property should + specify at least one voltage level (which would be a safe operating + voltage). + + max8997,pmic-buck5-dvs-voltage: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + description: | + A set of 8 voltage values in micro-volt (uV) units for buck5 when + changing voltage using GPIO DVS. + If none of max8997,pmic-buck[1/2/5]-uses-gpio-dvs optional property is + specified, the max8997,pmic-buck[1/2/5]-dvs-voltage property should + specify at least one voltage level (which would be a safe operating + voltage). + + max8997,pmic-buck1-uses-gpio-dvs: + type: boolean + description: | + buck1 can be controlled by GPIO DVS. + + max8997,pmic-buck2-uses-gpio-dvs: + type: boolean + description: | + buck2 can be controlled by GPIO DVS. + + max8997,pmic-buck5-uses-gpio-dvs: + type: boolean + description: | + buck5 can be controlled by GPIO DVS. + + max8997,pmic-buck125-default-dvs-idx: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + default: 0 + description: | + Default voltage setting selected from the possible 8 options selectable + by the dvs gpios. The value of this property should be between 0 and 7. + If not specified or if out of range, the default value of this property + is set to 0. + + max8997,pmic-buck125-dvs-gpios: + minItems: 3 + maxItems: 3 + description: | + GPIO specifiers for three host gpio's used for DVS. + + max8997,pmic-ignore-gpiodvs-side-effect: + type: boolean + description: | + When GPIO-DVS mode is used for multiple bucks, changing the voltage value + of one of the bucks may affect that of another buck, which is the side + effect of the change (set_voltage). Use this property to ignore such + side effects and change the voltage. + + reg: + maxItems: 1 + + regulators: + type: object + description: + List of child nodes that specify the regulators. + + patternProperties: + # 1-18 and 21 LDOs + "^LDO([1-9]|1[0-8]|21)$": + type: object + $ref: regulator.yaml# + description: + Properties for single LDO regulator. + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + # 7 bucks + "^BUCK[1-7]$": + type: object + $ref: regulator.yaml# + description: + Properties for single BUCK regulator. + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + "^EN32KHZ_[AC]P$": + type: object + $ref: regulator.yaml# + description: + 32768 Hz clock output (modelled as regulator) + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + + required: + - regulator-name + + additionalProperties: false + + properties: + CHARGER: + type: object + $ref: regulator.yaml# + description: main battery charger current control + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + CHARGER_CV: + type: object + $ref: regulator.yaml# + description: main battery charger voltage control + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + CHARGER_TOPOFF: + type: object + $ref: regulator.yaml# + description: end of charge current threshold level + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + ENVICHG: + type: object + $ref: regulator.yaml# + description: | + Battery Charging Current Monitor Output. This is a fixed voltage type + regulator + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + ESAFEOUT1: + type: object + $ref: regulator.yaml# + description: LDO19 + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + ESAFEOUT2: + type: object + $ref: regulator.yaml# + description: LDO20 + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + +required: + - compatible + - max8997,pmic-buck1-dvs-voltage + - max8997,pmic-buck2-dvs-voltage + - max8997,pmic-buck5-dvs-voltage + - reg + - regulators + +dependencies: + max8997,pmic-buck1-uses-gpio-dvs: [ 'max8997,pmic-buck125-dvs-gpios' ] + max8997,pmic-buck2-uses-gpio-dvs: [ 'max8997,pmic-buck125-dvs-gpios' ] + max8997,pmic-buck5-uses-gpio-dvs: [ 'max8997,pmic-buck125-dvs-gpios' ] + +additionalProperties: false + +if: + anyOf: + - required: + - max8997,pmic-buck1-uses-gpio-dvs + - required: + - max8997,pmic-buck2-uses-gpio-dvs + - required: + - max8997,pmic-buck5-uses-gpio-dvs +then: + properties: + max8997,pmic-buck1-dvs-voltage: + minItems: 8 + maxItems: 8 + max8997,pmic-buck2-dvs-voltage: + minItems: 8 + maxItems: 8 + max8997,pmic-buck5-dvs-voltage: + minItems: 8 + maxItems: 8 + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "maxim,max8997-pmic"; + reg = <0x66>; + + interrupts-extended = <&gpx0 7 IRQ_TYPE_LEVEL_LOW>, + <&gpx2 3 IRQ_TYPE_EDGE_FALLING>; + + max8997,pmic-buck1-uses-gpio-dvs; + max8997,pmic-buck2-uses-gpio-dvs; + max8997,pmic-buck5-uses-gpio-dvs; + + max8997,pmic-ignore-gpiodvs-side-effect; + max8997,pmic-buck125-default-dvs-idx = <0>; + + max8997,pmic-buck125-dvs-gpios = <&gpx0 5 GPIO_ACTIVE_HIGH>, + <&gpx0 6 GPIO_ACTIVE_HIGH>, + <&gpl0 0 GPIO_ACTIVE_HIGH>; + + max8997,pmic-buck1-dvs-voltage = <1350000>, <1300000>, + <1250000>, <1200000>, + <1150000>, <1100000>, + <1000000>, <950000>; + + max8997,pmic-buck2-dvs-voltage = <1100000>, <1000000>, + <950000>, <900000>, + <1100000>, <1000000>, + <950000>, <900000>; + + max8997,pmic-buck5-dvs-voltage = <1200000>, <1200000>, + <1200000>, <1200000>, + <1200000>, <1200000>, + <1200000>, <1200000>; + + pinctrl-0 = <&max8997_irq>, <&otg_gp>, <&usb_sel>; + pinctrl-names = "default"; + + charger-supply = <&charger_reg>; + + regulators { + LDO1 { + regulator-name = "VADC_3.3V_C210"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + + LDO2 { + regulator-name = "VALIVE_1.1V_C210"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + }; + + BUCK1 { + regulator-name = "VARM_1.2V_C210"; + regulator-min-microvolt = <65000>; + regulator-max-microvolt = <2225000>; + regulator-always-on; + }; + + // ... + + BUCK7 { + regulator-name = "VCC_SUB_2.0V"; + regulator-min-microvolt = <2000000>; + regulator-max-microvolt = <2000000>; + regulator-always-on; + }; + + ESAFEOUT1 { + regulator-name = "SAFEOUT1"; + }; + + ESAFEOUT2 { + regulator-name = "SAFEOUT2"; + regulator-boot-on; + }; + + EN32KHZ_AP { + regulator-name = "EN32KHZ_AP"; + regulator-always-on; + }; + + EN32KHZ_CP { + regulator-name = "EN32KHZ_CP"; + regulator-always-on; + }; + + CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <200000>; + regulator-max-microamp = <950000>; + }; + + CHARGER_CV { + regulator-name = "CHARGER_CV"; + regulator-min-microvolt = <4200000>; + regulator-max-microvolt = <4200000>; + regulator-always-on; + }; + + CHARGER_TOPOFF { + regulator-name = "CHARGER_TOPOFF"; + regulator-min-microamp = <200000>; + regulator-max-microamp = <200000>; + regulator-always-on; + }; + }; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "maxim,max8997-pmic"; + reg = <0x66>; + + interrupt-parent = <&gpx0>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>, + <3 IRQ_TYPE_EDGE_FALLING>; + pinctrl-names = "default"; + pinctrl-0 = <&max8997_irq>; + + max8997,pmic-buck1-dvs-voltage = <1350000>; + max8997,pmic-buck2-dvs-voltage = <1100000>; + max8997,pmic-buck5-dvs-voltage = <1200000>; + + regulators { + LDO1 { + regulator-name = "VDD_ABB_3.3V"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + // ... + + BUCK1 { + regulator-name = "VDD_ARM_1.2V"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + }; + + // ... + + EN32KHZ_AP { + regulator-name = "EN32KHZ_AP"; + regulator-always-on; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index 34de38377aa6..b959504e0ea4 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -35,6 +35,7 @@ description: | PMIC. Supported regulator node names are For PM6150, smps1 - smps5, ldo1 - ldo19 For PM6150L, smps1 - smps8, ldo1 - ldo11, bob + For PM6350, smps1 - smps5, ldo1 - ldo22 For PM7325, smps1 - smps8, ldo1 - ldo19 For PM8005, smps1 - smps4 For PM8009, smps1 - smps2, ldo1 - ldo7 @@ -52,6 +53,7 @@ properties: enum: - qcom,pm6150-rpmh-regulators - qcom,pm6150l-rpmh-regulators + - qcom,pm6350-rpmh-regulators - qcom,pm7325-rpmh-regulators - qcom,pm8005-rpmh-regulators - qcom,pm8009-rpmh-regulators diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index 83b53579f463..f052e03be402 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -65,6 +65,9 @@ description: For pms405, s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13 + For pm2250, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, + l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22 + maintainers: - Kathiravan T <kathirav@codeaurora.org> @@ -86,6 +89,7 @@ properties: - qcom,rpm-pmi8994-regulators - qcom,rpm-pmi8998-regulators - qcom,rpm-pms405-regulators + - qcom,rpm-pm2250-regulators patternProperties: ".*-supply$": diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt b/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt deleted file mode 100644 index bae3c7f838cf..000000000000 --- a/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt +++ /dev/null @@ -1,79 +0,0 @@ -Binding for Samsung S2MPA01 regulator block -=========================================== - -This is a part of device tree bindings for S2M family multi-function devices. -More information can be found in bindings/mfd/sec-core.txt file. - -The S2MPA01 device provide buck and LDO regulators. - -To register these with regulator framework instantiate under main device node -a sub-node named "regulators" with more sub-nodes for each regulator using the -common regulator binding documented in: - - Documentation/devicetree/bindings/regulator/regulator.txt - - -Names of regulators supported by S2MPA01 device: - - LDOn - - valid values for n are 1 to 26 - - Example: LDO1, LD02, LDO26 - - BUCKn - - valid values for n are 1 to 10. - - Example: BUCK1, BUCK2, BUCK9 -Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number -as per the datasheet of device. - - -Optional properties of buck regulator nodes under "regulators" sub-node: - - regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500 - (default), 25000, or 50000. May be 0 for disabling the ramp delay on - BUCK{1,2,3,4}. - - In the absence of the regulator-ramp-delay property, the default ramp - delay will be used. - - Note: Some bucks share the ramp rate setting i.e. same ramp value - will be set for a particular group of bucks so provide the same - regulator-ramp-delay value for them. - Groups sharing ramp rate: - - buck{1,6}, - - buck{2,4}, - - buck{8,9,10}. - -Example: - - s2mpa01_pmic@66 { - compatible = "samsung,s2mpa01-pmic"; - reg = <0x66>; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "VDD_ALIVE"; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1000000>; - }; - - ldo2_reg: LDO2 { - regulator-name = "VDDQ_MMC2"; - regulator-min-microvolt = <2800000>; - regulator-max-microvolt = <2800000>; - regulator-always-on; - }; - - buck1_reg: BUCK1 { - regulator-name = "vdd_mif"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - }; - - buck2_reg: BUCK2 { - regulator-name = "vdd_arm"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - regulator-ramp-delay = <50000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml new file mode 100644 index 000000000000..0627dec513da --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mpa01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPA01 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPA01 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml for + additional information and example. + +patternProperties: + # 26 LDOs + "^LDO([1-9]|1[0-9]|2[0-6])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 10 bucks + "^BUCK([1-9]|10)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + properties: + regulator-ramp-delay: + enum: [0, 6250, 12500, 25000, 50000] + default: 12500 + description: | + May be 0 for disabling the ramp delay on BUCK{1,2,3,4}. + + In the absence of the regulator-ramp-delay property, the default ramp + delay will be used. + + Note: Some bucks share the ramp rate setting i.e. same ramp value + will be set for a particular group of bucks so provide the same + regulator-ramp-delay value for them. + Groups sharing ramp rate: + * buck{1,6}, + * buck{2,4}, + * buck{8,9,10}. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt b/Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt deleted file mode 100644 index 27a48bf1b185..000000000000 --- a/Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt +++ /dev/null @@ -1,102 +0,0 @@ -Binding for Samsung S2M family regulator block -============================================== - -This is a part of device tree bindings for S2M family multi-function devices. -More information can be found in bindings/mfd/sec-core.txt file. - -The S2MPS11/13/14/15 and S2MPU02 devices provide buck and LDO regulators. - -To register these with regulator framework instantiate under main device node -a sub-node named "regulators" with more sub-nodes for each regulator using the -common regulator binding documented in: - - Documentation/devicetree/bindings/regulator/regulator.txt - - -Names of regulators supported by different devices: - - LDOn - - valid values for n are: - - S2MPS11: 1 to 38 - - S2MPS13: 1 to 40 - - S2MPS14: 1 to 25 - - S2MPS15: 1 to 27 - - S2MPU02: 1 to 28 - - Example: LDO1, LDO2, LDO28 - - BUCKn - - valid values for n are: - - S2MPS11: 1 to 10 - - S2MPS13: 1 to 10 - - S2MPS14: 1 to 5 - - S2MPS15: 1 to 10 - - S2MPU02: 1 to 7 - - Example: BUCK1, BUCK2, BUCK9 -Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number -as per the datasheet of device. - - -Optional properties of the nodes under "regulators" sub-node: - - regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500, - 25000 (default) or 50000. - - Additionally S2MPS11 supports disabling ramp delay for BUCK{2,3,4,6} - by setting it to <0>. - - Note: On S2MPS11 some bucks share the ramp rate setting i.e. same ramp value - will be set for a particular group of bucks so provide the same - regulator-ramp-delay value for them. - Groups sharing ramp rate: - - buck{1,6}, - - buck{3,4}, - - buck{7,8,10}. - - - samsung,ext-control-gpios: On S2MPS14 the LDO10, LDO11 and LDO12 can be - configured to external control over GPIO. To turn this feature on this - property must be added to the regulator sub-node: - - samsung,ext-control-gpios: GPIO specifier for one GPIO - controlling this regulator (enable/disable) - Example: - LDO12 { - regulator-name = "V_EMMC_2.8V"; - regulator-min-microvolt = <2800000>; - regulator-max-microvolt = <2800000>; - samsung,ext-control-gpios = <&gpk0 2 0>; - }; - - -Example: - - s2mps11_pmic@66 { - compatible = "samsung,s2mps11-pmic"; - reg = <0x66>; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "VDD_ABB_3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - ldo2_reg: LDO2 { - regulator-name = "VDD_ALIVE_1.1V"; - regulator-min-microvolt = <1100000>; - regulator-max-microvolt = <1100000>; - regulator-always-on; - }; - - buck1_reg: BUCK1 { - regulator-name = "vdd_mif"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - }; - - buck2_reg: BUCK2 { - regulator-name = "vdd_arm"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - regulator-ramp-delay = <50000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml new file mode 100644 index 000000000000..e3b780715f44 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mps11.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPS11 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPS11 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 38 LDOs + "^LDO([1-9]|[1-2][0-9]|3[0-8])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 10 bucks + "^BUCK([1-9]|10)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml new file mode 100644 index 000000000000..579d77aefc3f --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mps13.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPS13 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPS13 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 40 LDOs + "^LDO([1-9]|[1-3][0-9]|40)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 10 bucks + "^BUCK([1-9]|10)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml new file mode 100644 index 000000000000..fdea290b3e94 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mps14.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPS14 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPS14 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 25 LDOs + "^LDO([1-9]|[1][0-9]|2[0-5])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 5 bucks + "^BUCK[1-5]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml new file mode 100644 index 000000000000..b3a883c94628 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mps15.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPS15 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPS15 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 27 LDOs + "^LDO([1-9]|[1][0-9]|2[0-7])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 10 bucks + "^BUCK([1-9]|10)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml new file mode 100644 index 000000000000..0ded6953e3b6 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mpu02.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPU02 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPU02 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 28 LDOs + "^LDO([1-9]|1[0-9]|2[0-8])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 7 bucks + "^BUCK[1-7]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt deleted file mode 100644 index 093edda0c8df..000000000000 --- a/Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt +++ /dev/null @@ -1,145 +0,0 @@ -Binding for Samsung S5M8767 regulator block -=========================================== - -This is a part of device tree bindings for S5M family multi-function devices. -More information can be found in bindings/mfd/sec-core.txt file. - -The S5M8767 device provide buck and LDO regulators. - -To register these with regulator framework instantiate under main device node -a sub-node named "regulators" with more sub-nodes for each regulator using the -common regulator binding documented in: - - Documentation/devicetree/bindings/regulator/regulator.txt - - -Required properties of the main device node (the parent!): - - s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck2 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - - - s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck3 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - - - s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck4 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - - - s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used - for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines. - - [1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional - property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage' - property should specify atleast one voltage level (which would be a - safe operating voltage). - - If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional - property is specified, then all the eight voltage values for the - 's5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified. - -Optional properties of the main device node (the parent!): - - s5m8767,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs. - - s5m8767,pmic-buck3-uses-gpio-dvs: 'buck3' can be controlled by gpio dvs. - - s5m8767,pmic-buck4-uses-gpio-dvs: 'buck4' can be controlled by gpio dvs. - -Additional properties required if either of the optional properties are used: - - - s5m8767,pmic-buck234-default-dvs-idx: Default voltage setting selected from - the possible 8 options selectable by the dvs gpios. The value of this - property should be between 0 and 7. If not specified or if out of range, the - default value of this property is set to 0. - - - s5m8767,pmic-buck-dvs-gpios: GPIO specifiers for three host gpio's used - for dvs. The format of the gpio specifier depends in the gpio controller. - - -Names of regulators supported by S5M8767 device: - - LDOn - - valid values for n are 1 to 28 - - Example: LDO1, LDO2, LDO28 - - BUCKn - - valid values for n are 1 to 9. - - Example: BUCK1, BUCK2, BUCK9 -Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number -as per the datasheet of device. - - -Optional properties of the nodes under "regulators" sub-node: - - op_mode: describes the different operating modes of the LDO's with - power mode change in SOC. The different possible values are, - 0 - always off mode - 1 - on in normal mode - 2 - low power mode - 3 - suspend mode - - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one - GPIO controlling this regulator - (enable/disable); This is valid only - for buck9. - -Example: - - s5m8767_pmic@66 { - compatible = "samsung,s5m8767-pmic"; - reg = <0x66>; - - s5m8767,pmic-buck2-uses-gpio-dvs; - s5m8767,pmic-buck3-uses-gpio-dvs; - s5m8767,pmic-buck4-uses-gpio-dvs; - - s5m8767,pmic-buck-default-dvs-idx = <0>; - - s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 0>, /* DVS1 */ - <&gpx0 1 0>, /* DVS2 */ - <&gpx0 2 0>; /* DVS3 */ - - s5m8767,pmic-buck-ds-gpios = <&gpx2 3 0>, /* SET1 */ - <&gpx2 4 0>, /* SET2 */ - <&gpx2 5 0>; /* SET3 */ - - s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>, - <1250000>, <1200000>, - <1150000>, <1100000>, - <1000000>, <950000>; - - s5m8767,pmic-buck3-dvs-voltage = <1100000>, <1100000>, - <1100000>, <1100000>, - <1000000>, <1000000>, - <1000000>, <1000000>; - - s5m8767,pmic-buck4-dvs-voltage = <1200000>, <1200000>, - <1200000>, <1200000>, - <1200000>, <1200000>, - <1200000>, <1200000>; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "VDD_ABB_3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - op_mode = <1>; /* Normal Mode */ - }; - - ldo2_reg: LDO2 { - regulator-name = "VDD_ALIVE_1.1V"; - regulator-min-microvolt = <1100000>; - regulator-max-microvolt = <1100000>; - regulator-always-on; - }; - - buck1_reg: BUCK1 { - regulator-name = "VDD_MIF_1.2V"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - }; - - vemmc_reg: BUCK9 { - regulator-name = "VMEM_VDD_2.8V"; - regulator-min-microvolt = <2800000>; - regulator-max-microvolt = <2800000>; - op_mode = <3>; /* Standby Mode */ - s5m8767,pmic-ext-control-gpios = <&gpk0 2 0>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml new file mode 100644 index 000000000000..80a63d47790a --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s5m8767.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5M8767 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S5M8767 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml for + additional information and example. + +patternProperties: + # 28 LDOs + "^LDO([1-9]|1[0-9]|2[0-8])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + properties: + op_mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 1 + description: | + Describes the different operating modes of the LDO's with power mode + change in SOC. The different possible values are: + 0 - always off mode + 1 - on in normal mode + 2 - low power mode + 3 - suspend mode + + required: + - regulator-name + + # 8 bucks + "^BUCK[1-8]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + + # 9 buck + "^BUCK9$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + properties: + s5m8767,pmic-ext-control-gpios: + maxItems: 1 + description: | + GPIO specifier for one GPIO controlling this regulator on/off. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml b/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml new file mode 100644 index 000000000000..a52a67c869b5 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/silergy,sy8106a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silergy SY8106A Voltage Regulator Device Tree Bindings + +maintainers: + - Ondrej Jirman <megous@megous.com> + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + const: silergy,sy8106a + + reg: + maxItems: 1 + + silergy,fixed-microvolt: + description: > + The voltage when I2C regulating is disabled (set by external resistor + like a fixed voltage) + +required: + - compatible + - reg + - silergy,fixed-microvolt + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@65 { + compatible = "silergy,sy8106a"; + reg = <0x65>; + regulator-name = "sy8106a-vdd"; + silergy,fixed-microvolt = <1200000>; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1400000>; + regulator-boot-on; + regulator-always-on; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml index 861d5f3c79e8..1218f21ba320 100644 --- a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml @@ -27,6 +27,7 @@ properties: - socionext,uniphier-pxs2-usb3-regulator - socionext,uniphier-ld20-usb3-regulator - socionext,uniphier-pxs3-usb3-regulator + - socionext,uniphier-nx1-usb3-regulator reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt deleted file mode 100644 index 39a8ca73f572..000000000000 --- a/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt +++ /dev/null @@ -1,23 +0,0 @@ -SY8106A Voltage regulator - -Required properties: -- compatible: Must be "silergy,sy8106a" -- reg: I2C slave address - must be <0x65> -- silergy,fixed-microvolt - the voltage when I2C regulating is disabled (set - by external resistor like a fixed voltage) - -Any property defined as part of the core regulator binding, defined in -./regulator.txt, can also be used. - -Example: - - sy8106a { - compatible = "silergy,sy8106a"; - reg = <0x65>; - regulator-name = "sy8106a-vdd"; - silergy,fixed-microvolt = <1200000>; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1400000>; - regulator-boot-on; - regulator-always-on; - }; diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml index 0e7087cc8bf9..ca155abbda7a 100644 --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml @@ -11,6 +11,14 @@ maintainers: allOf: - $ref: spi-controller.yaml# + - if: + properties: + compatible: + contains: + const: xlnx,versal-ospi-1.0 + then: + required: + - power-domains properties: compatible: @@ -20,6 +28,7 @@ properties: - ti,k2g-qspi - ti,am654-ospi - intel,lgm-qspi + - xlnx,versal-ospi-1.0 - const: cdns,qspi-nor - const: cdns,qspi-nor @@ -65,6 +74,9 @@ properties: data rather than the QSPI clock. Make sure that QSPI return clock is populated on the board before using this property. + power-domains: + maxItems: 1 + resets: maxItems: 2 diff --git a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml new file mode 100644 index 000000000000..b8bb8a3dbf54 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020-21 Cadence +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/spi/cdns,xspi.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Cadence XSPI Controller + +maintainers: + - Parshuram Thombare <pthombar@cadence.com> + +description: | + The XSPI controller allows SPI protocol communication in + single, dual, quad or octal wire transmission modes for + read/write access to slaves such as SPI-NOR flash. + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + const: cdns,xspi-nor + + reg: + items: + - description: address and length of the controller register set + - description: address and length of the Slave DMA data port + - description: address and length of the auxiliary registers + + reg-names: + items: + - const: io + - const: sdma + - const: aux + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + bus { + #address-cells = <2>; + #size-cells = <2>; + + xspi: spi@a0010000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "cdns,xspi-nor"; + reg = <0x0 0xa0010000 0x0 0x1040>, + <0x0 0xb0000000 0x0 0x1000>, + <0x0 0xa0020000 0x0 0x100>; + reg-names = "io", "sdma", "aux"; + interrupts = <0 90 IRQ_TYPE_LEVEL_HIGH>; + interrupt-parent = <&gic>; + + flash@0 { + compatible = "jedec,spi-nor"; + spi-max-frequency = <75000000>; + reg = <0>; + }; + + flash@1 { + compatible = "jedec,spi-nor"; + spi-max-frequency = <75000000>; + reg = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/ingenic,spi.yaml b/Documentation/devicetree/bindings/spi/ingenic,spi.yaml new file mode 100644 index 000000000000..cf56cc484b19 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/ingenic,spi.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/ingenic,spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs SPI controller devicetree bindings + +maintainers: + - Artur Rojek <contact@artur-rojek.eu> + - Paul Cercueil <paul@crapouillou.net> + +allOf: + - $ref: /schemas/spi/spi-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - ingenic,jz4750-spi + - ingenic,jz4780-spi + - items: + - enum: + - ingenic,jz4760-spi + - ingenic,jz4770-spi + - const: ingenic,jz4750-spi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + dmas: + maxItems: 2 + minItems: 2 + + dma-names: + items: + - const: rx + - const: tx + +required: + - compatible + - reg + - interrupts + - clocks + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/jz4770-cgu.h> + spi@10043000 { + compatible = "ingenic,jz4770-spi", "ingenic,jz4750-spi"; + reg = <0x10043000 0x1c>; + #address-cells = <1>; + #size-cells = <0>; + + interrupt-parent = <&intc>; + interrupts = <8>; + + clocks = <&cgu JZ4770_CLK_SSI0>; + + dmas = <&dmac1 23 0xffffffff>, <&dmac1 22 0xffffffff>; + dma-names = "rx", "tx"; + }; diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml index ef5698f426b2..055524fe8327 100644 --- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml @@ -21,7 +21,11 @@ allOf: properties: compatible: items: - - const: qcom,sdm845-qspi + - enum: + - qcom,sc7180-qspi + - qcom,sc7280-qspi + - qcom,sdm845-qspi + - const: qcom,qspi-v1 reg: diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml index ca91201a9926..d7e08b03e204 100644 --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml @@ -171,7 +171,7 @@ examples: cs-gpios = <&gpio0 13 0>, <&gpio0 14 0>; rx-sample-delay-ns = <3>; - spi-flash@1 { + flash@1 { compatible = "spi-nand"; reg = <1>; rx-sample-delay-ns = <7>; diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt deleted file mode 100644 index 8f34a7c7d8b8..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt +++ /dev/null @@ -1,44 +0,0 @@ -* NXP Flex Serial Peripheral Interface (FSPI) - -Required properties: - - compatible : Should be "nxp,lx2160a-fspi" - "nxp,imx8qxp-fspi" - "nxp,imx8mm-fspi" - "nxp,imx8mp-fspi" - "nxp,imx8dxl-fspi" - - - reg : First contains the register location and length, - Second contains the memory mapping address and length - - reg-names : Should contain the resource reg names: - - fspi_base: configuration register address space - - fspi_mmap: memory mapped address space - - interrupts : Should contain the interrupt for the device - -Required SPI slave node properties: - - reg : There are two buses (A and B) with two chip selects each. - This encodes to which bus and CS the flash is connected: - - <0>: Bus A, CS 0 - - <1>: Bus A, CS 1 - - <2>: Bus B, CS 0 - - <3>: Bus B, CS 1 - -Example showing the usage of two SPI NOR slave devices on bus A: - -fspi0: spi@20c0000 { - compatible = "nxp,lx2160a-fspi"; - reg = <0x0 0x20c0000 0x0 0x10000>, <0x0 0x20000000 0x0 0x10000000>; - reg-names = "fspi_base", "fspi_mmap"; - interrupts = <0 25 0x4>; /* Level high type */ - clocks = <&clockgen 4 3>, <&clockgen 4 3>; - clock-names = "fspi_en", "fspi"; - - mt35xu512aba0: flash@0 { - reg = <0>; - .... - }; - - mt35xu512aba1: flash@1 { - reg = <1>; - .... - }; -}; diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml new file mode 100644 index 000000000000..283815d59e85 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-nxp-fspi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Flex Serial Peripheral Interface (FSPI) + +maintainers: + - Kuldeep Singh <kuldeep.singh@nxp.com> + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + enum: + - nxp,imx8dxl-fspi + - nxp,imx8mm-fspi + - nxp,imx8mp-fspi + - nxp,imx8qxp-fspi + - nxp,lx2160a-fspi + + reg: + items: + - description: registers address space + - description: memory mapped address space + + reg-names: + items: + - const: fspi_base + - const: fspi_mmap + + interrupts: + maxItems: 1 + + clocks: + items: + - description: SPI bus clock + - description: SPI serial clock + + clock-names: + items: + - const: fspi_en + - const: fspi + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/fsl,qoriq-clockgen.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + spi@20c0000 { + compatible = "nxp,lx2160a-fspi"; + reg = <0x0 0x20c0000 0x0 0x100000>, + <0x0 0x20000000 0x0 0x10000000>; + reg-names = "fspi_base", "fspi_mmap"; + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(4)>, + <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(4)>; + clock-names = "fspi_en", "fspi"; + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "jedec,spi-nor"; + spi-max-frequency = <50000000>; + reg = <0>; + spi-rx-bus-width = <8>; + spi-tx-bus-width = <8>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 1e4b3464d734..791079021f1b 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -41,10 +41,6 @@ properties: - adi,adp5585-02 # Analog Devices ADP5589 Keypad Decoder and I/O Expansion - adi,adp5589 - # +/-1C TDM Extended Temp Range I.C - - adi,adt7461 - # +/-1C TDM Extended Temp Range I.C - - adt7461 # AMS iAQ-Core VOC Sensor - ams,iaq-core # i2c serial eeprom (24cxx) @@ -77,6 +73,8 @@ properties: - dallas,ds4510 # Digital Thermometer and Thermostat - dallas,ds75 + # Delta Electronics DPS-650-AB power supply + - delta,dps650ab # Delta Electronics DPS920AB 920W 54V Power Supply - delta,dps920ab # 1/4 Brick DC/DC Regulated Power Module @@ -113,8 +111,14 @@ properties: - mps,mp2888 # Monolithic Power Systems Inc. multi-phase controller mp2975 - mps,mp2975 - # G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface - - gmt,g751 + # Honeywell Humidicon HIH-6130 humidity/temperature sensor + - honeywell,hi6130 + # IBM Common Form Factor Power Supply Versions (all versions) + - ibm,cffps + # IBM Common Form Factor Power Supply Versions 1 + - ibm,cffps1 + # IBM Common Form Factor Power Supply Versions 2 + - ibm,cffps2 # Infineon IR36021 digital POL buck controller - infineon,ir36021 # Infineon IR38064 Voltage Regulator @@ -307,16 +311,22 @@ properties: - ti,hdc1050 # Temperature and humidity sensor with i2c interface - ti,hdc1080 + # Thermometer with SPI interface + - ti,lm70 + - ti,lm71 # Temperature sensor with 2-wire interface - ti,lm73 + # Thermometer with SPI interface + - ti,lm74 # Temperature sensor with integrated fan control - ti,lm96000 # I2C Touch-Screen Controller - ti,tsc2003 # Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface - - ti,tmp102 - # Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface - ti,tmp103 + # Thermometer with SPI interface + - ti,tmp121 + - ti,tmp122 # Digital Temperature Sensor - ti,tmp275 # TI Dual channel DCAP+ multiphase controller TPS53676 with AVSBus diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index a867f7102c35..952553759ac4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -509,6 +509,8 @@ patternProperties: description: Hycon Technology Corp. "^hydis,.*": description: Hydis Technologies + "^hynix,.*": + description: SK Hynix Inc. "^hyundai,.*": description: Hyundai Technology "^i2se,.*": diff --git a/Documentation/driver-api/ipmi.rst b/Documentation/driver-api/ipmi.rst index bc281f10ce4b..e224e47b6b09 100644 --- a/Documentation/driver-api/ipmi.rst +++ b/Documentation/driver-api/ipmi.rst @@ -166,8 +166,8 @@ and the type is IPMI_SYSTEM_INTERFACE_ADDR_TYPE. This is used for talking straight to the BMC on the current card. The channel must be IPMI_BMC_CHANNEL. -Messages that are destined to go out on the IPMB bus use the -IPMI_IPMB_ADDR_TYPE address type. The format is:: +Messages that are destined to go out on the IPMB bus going through the +BMC use the IPMI_IPMB_ADDR_TYPE address type. The format is:: struct ipmi_ipmb_addr { @@ -181,6 +181,23 @@ The "channel" here is generally zero, but some devices support more than one channel, it corresponds to the channel as defined in the IPMI spec. +There is also an IPMB direct address for a situation where the sender +is directly on an IPMB bus and doesn't have to go through the BMC. +You can send messages to a specific management controller (MC) on the +IPMB using the IPMI_IPMB_DIRECT_ADDR_TYPE with the following format:: + + struct ipmi_ipmb_direct_addr + { + int addr_type; + short channel; + unsigned char slave_addr; + unsigned char rq_lun; + unsigned char rs_lun; + }; + +The channel is always zero. You can also receive commands from other +MCs that you have registered to handle and respond to them, so you can +use this to implement a management controller on a bus.. Messages -------- @@ -348,6 +365,10 @@ user may be registered for each netfn/cmd/channel, but different users may register for different commands, or the same command if the channel bitmasks do not overlap. +To respond to a received command, set the response bit in the returned +netfn, use the address from the received message, and use the same +msgid that you got in the receive message. + From userland, equivalent IOCTLs are provided to do these functions. @@ -570,6 +591,45 @@ web page. The driver supports a hot add and remove of interfaces through the I2C sysfs interface. +The IPMI IPMB Driver +-------------------- + +This driver is for supporting a system that sits on an IPMB bus; it +allows the interface to look like a normal IPMI interface. Sending +system interface addressed messages to it will cause the message to go +to the registered BMC on the system (default at IPMI address 0x20). + +It also allows you to directly address other MCs on the bus using the +ipmb direct addressing. You can receive commands from other MCs on +the bus and they will be handled through the normal received command +mechanism described above. + +Parameters are:: + + ipmi_ipmb.bmcaddr=<address to use for system interface addresses messages> + ipmi_ipmb.retry_time_ms=<Time between retries on IPMB> + ipmi_ipmb.max_retries=<Number of times to retry a message> + +Loading the module will not result in the driver automatcially +starting unless there is device tree information setting it up. If +you want to instantiate one of these by hand, do:: + + echo ipmi-ipmb <addr> > /sys/class/i2c-dev/i2c-<n>/device/new_device + +Note that the address you give here is the I2C address, not the IPMI +address. So if you want your MC address to be 0x60, you put 0x30 +here. See the I2C driver info for more details. + +Command bridging to other IPMB busses through this interface does not +work. The receive message queue is not implemented, by design. There +is only one receive message queue on a BMC, and that is meant for the +host drivers, not something on the IPMB bus. + +A BMC may have multiple IPMB busses, which bus your device sits on +depends on how the system is wired. You can fetch the channels with +"ipmitool channel info <n>" where <n> is the channel, with the +channels being 0-7 and try the IPMB channels. + Other Pieces ------------ diff --git a/Documentation/driver-api/media/drivers/rkisp1.rst b/Documentation/driver-api/media/drivers/rkisp1.rst new file mode 100644 index 000000000000..ea336958a3af --- /dev/null +++ b/Documentation/driver-api/media/drivers/rkisp1.rst @@ -0,0 +1,43 @@ +.. SPDX-License-Identifier: GPL-2.0 + +The Rockchip Image Signal Processor Driver (rkisp1) +=================================================== + +Versions and their differences +------------------------------ + +The rkisp1 block underwent some changes between SoC implementations. +The vendor designates them as: + +- V10: used at least in rk3288 and rk3399 +- V11: declared in the original vendor code, but not used +- V12: used at least in rk3326 and px30 +- V13: used at least in rk1808 +- V20: used in rk3568 and beyond + +Right now the kernel supports rkisp1 implementations based +on V10 and V12 variants. V11 does not seem to be actually used +and V13 will need some more additions but isn't researched yet, +especially as it seems to be limited to the rk1808 which hasn't +reached much market spread. + +V20 on the other hand will probably be used in future SoCs and +has seen really big changes in the vendor kernel, so will need +quite a bit of research. + +Changes from V10 to V12 +----------------------- + +- V12 supports a new CSI-host implementation but can still + also use the same implementation from V10 +- The module for lens shading correction got changed + from 12bit to 13bit width +- The AWB and AEC modules got replaced to support finer + grained data collection + +Changes from V12 to V13 +----------------------- + +The list for V13 is incomplete and needs further investigation. + +- V13 does not support the old CSI-host implementation anymore diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst index eb1cdfd280ba..ffc712a5f632 100644 --- a/Documentation/driver-api/media/maintainer-entry-profile.rst +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst @@ -71,7 +71,7 @@ media maintainers do the review. The media maintainers that work on specific areas of the subsystem are: -- Digital TV and remote controllers: +- Remote Controllers (infrared): Sean Young <sean@mess.org> - HDMI CEC: diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst index 7736da077fb8..08ea2673b19e 100644 --- a/Documentation/driver-api/media/v4l2-subdev.rst +++ b/Documentation/driver-api/media/v4l2-subdev.rst @@ -191,21 +191,21 @@ registered this way are stored in a global list of subdevices, ready to be picked up by bridge drivers. Bridge drivers in turn have to register a notifier object. This is -performed using the :c:func:`v4l2_async_notifier_register` call. To +performed using the :c:func:`v4l2_async_nf_register` call. To unregister the notifier the driver has to call -:c:func:`v4l2_async_notifier_unregister`. The former of the two functions +:c:func:`v4l2_async_nf_unregister`. The former of the two functions takes two arguments: a pointer to struct :c:type:`v4l2_device` and a pointer to struct :c:type:`v4l2_async_notifier`. Before registering the notifier, bridge drivers must do two things: first, the -notifier must be initialized using the :c:func:`v4l2_async_notifier_init`. +notifier must be initialized using the :c:func:`v4l2_async_nf_init`. Second, bridge drivers can then begin to form a list of subdevice descriptors that the bridge device needs for its operation. Several functions are available to add subdevice descriptors to a notifier, depending on the type of device and the needs of the driver. -:c:func:`v4l2_async_notifier_add_fwnode_remote_subdev` and -:c:func:`v4l2_async_notifier_add_i2c_subdev` are for bridge and ISP drivers for +:c:func:`v4l2_async_nf_add_fwnode_remote` and +:c:func:`v4l2_async_nf_add_i2c` are for bridge and ISP drivers for registering their async sub-devices with the notifier. :c:func:`v4l2_async_register_subdev_sensor` is a helper function for @@ -230,8 +230,8 @@ These functions allocate an async sub-device descriptor which is of type struct ... - my_asd = v4l2_async_notifier_add_fwnode_remote_subdev(¬ifier, ep, - struct my_async_subdev); + my_asd = v4l2_async_nf_add_fwnode_remote(¬ifier, ep, + struct my_async_subdev); fwnode_handle_put(ep); if (IS_ERR(asd)) diff --git a/Documentation/driver-api/mmc/mmc-tools.rst b/Documentation/driver-api/mmc/mmc-tools.rst index a231e9644351..eee1c2ccfa8f 100644 --- a/Documentation/driver-api/mmc/mmc-tools.rst +++ b/Documentation/driver-api/mmc/mmc-tools.rst @@ -2,10 +2,10 @@ MMC tools introduction ====================== -There is one MMC test tools called mmc-utils, which is maintained by Chris Ball, +There is one MMC test tools called mmc-utils, which is maintained by Ulf Hansson, you can find it at the below public git repository: - https://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/ + https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git Functions ========= diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt index 9f0259bbd7df..3361e86b0958 100644 --- a/Documentation/features/core/thread-info-in-task/arch-support.txt +++ b/Documentation/features/core/thread-info-in-task/arch-support.txt @@ -20,7 +20,7 @@ | nds32: | ok | | nios2: | TODO | | openrisc: | TODO | - | parisc: | TODO | + | parisc: | ok | | powerpc: | ok | | riscv: | ok | | s390: | ok | diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index b97579b7d8fb..01df283c7d04 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -19,9 +19,10 @@ It is designed as a better filesystem solution for the following scenarios: immutable and bit-for-bit identical to the official golden image for their releases due to security and other considerations and - - hope to save some extra storage space with guaranteed end-to-end performance - by using reduced metadata and transparent file compression, especially - for those embedded devices with limited memory (ex, smartphone); + - hope to minimize extra storage space with guaranteed end-to-end performance + by using compact layout, transparent file compression and direct access, + especially for those embedded devices with limited memory and high-density + hosts with numerous containers; Here is the main features of EROFS: @@ -51,7 +52,9 @@ Here is the main features of EROFS: - Support POSIX.1e ACLs by using xattrs; - Support transparent data compression as an option: - LZ4 algorithm with the fixed-sized output compression for high performance. + LZ4 algorithm with the fixed-sized output compression for high performance; + + - Multiple device support for multi-layer container images. The following git tree provides the file system user-space tools under development (ex, formatting tool mkfs.erofs): @@ -87,6 +90,7 @@ cache_strategy=%s Select a strategy for cached decompression from now on: dax={always,never} Use direct access (no page cache). See Documentation/filesystems/dax.rst. dax A legacy option which is an alias for ``dax=always``. +device=%s Specify a path to an extra device to be used together. =================== ========================================================= On-disk details diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 0eb799d9d05a..4d5d50dca65c 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -77,11 +77,11 @@ Side-channel attacks fscrypt is only resistant to side-channel attacks, such as timing or electromagnetic attacks, to the extent that the underlying Linux -Cryptographic API algorithms are. If a vulnerable algorithm is used, -such as a table-based implementation of AES, it may be possible for an -attacker to mount a side channel attack against the online system. -Side channel attacks may also be mounted against applications -consuming decrypted data. +Cryptographic API algorithms or inline encryption hardware are. If a +vulnerable algorithm is used, such as a table-based implementation of +AES, it may be possible for an attacker to mount a side channel attack +against the online system. Side channel attacks may also be mounted +against applications consuming decrypted data. Unauthorized file access ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -176,11 +176,11 @@ Master Keys Each encrypted directory tree is protected by a *master key*. Master keys can be up to 64 bytes long, and must be at least as long as the -greater of the key length needed by the contents and filenames -encryption modes being used. For example, if AES-256-XTS is used for -contents encryption, the master key must be 64 bytes (512 bits). Note -that the XTS mode is defined to require a key twice as long as that -required by the underlying block cipher. +greater of the security strength of the contents and filenames +encryption modes being used. For example, if any AES-256 mode is +used, the master key must be at least 256 bits, i.e. 32 bytes. A +stricter requirement applies if the key is used by a v1 encryption +policy and AES-256-XTS is used; such keys must be 64 bytes. To "unlock" an encrypted directory tree, userspace must provide the appropriate master key. There can be any number of master keys, each @@ -1135,6 +1135,50 @@ where applications may later write sensitive data. It is recommended that systems implementing a form of "verified boot" take advantage of this by validating all top-level encryption policies prior to access. +Inline encryption support +========================= + +By default, fscrypt uses the kernel crypto API for all cryptographic +operations (other than HKDF, which fscrypt partially implements +itself). The kernel crypto API supports hardware crypto accelerators, +but only ones that work in the traditional way where all inputs and +outputs (e.g. plaintexts and ciphertexts) are in memory. fscrypt can +take advantage of such hardware, but the traditional acceleration +model isn't particularly efficient and fscrypt hasn't been optimized +for it. + +Instead, many newer systems (especially mobile SoCs) have *inline +encryption hardware* that can encrypt/decrypt data while it is on its +way to/from the storage device. Linux supports inline encryption +through a set of extensions to the block layer called *blk-crypto*. +blk-crypto allows filesystems to attach encryption contexts to bios +(I/O requests) to specify how the data will be encrypted or decrypted +in-line. For more information about blk-crypto, see +:ref:`Documentation/block/inline-encryption.rst <inline_encryption>`. + +On supported filesystems (currently ext4 and f2fs), fscrypt can use +blk-crypto instead of the kernel crypto API to encrypt/decrypt file +contents. To enable this, set CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y in +the kernel configuration, and specify the "inlinecrypt" mount option +when mounting the filesystem. + +Note that the "inlinecrypt" mount option just specifies to use inline +encryption when possible; it doesn't force its use. fscrypt will +still fall back to using the kernel crypto API on files where the +inline encryption hardware doesn't have the needed crypto capabilities +(e.g. support for the needed encryption algorithm and data unit size) +and where blk-crypto-fallback is unusable. (For blk-crypto-fallback +to be usable, it must be enabled in the kernel configuration with +CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y.) + +Currently fscrypt always uses the filesystem block size (which is +usually 4096 bytes) as the data unit size. Therefore, it can only use +inline encryption hardware that supports that data unit size. + +Inline encryption doesn't affect the ciphertext or other aspects of +the on-disk format, so users may freely switch back and forth between +using "inlinecrypt" and not using "inlinecrypt". + Implementation details ====================== @@ -1184,6 +1228,13 @@ keys`_ and `DIRECT_KEY policies`_. Data path changes ----------------- +When inline encryption is used, filesystems just need to associate +encryption contexts with bios to specify how the block layer or the +inline encryption hardware will encrypt/decrypt the file contents. + +When inline encryption isn't used, filesystems must encrypt/decrypt +the file contents themselves, as described below: + For the read path (->readpage()) of regular files, filesystems can read the ciphertext into the page cache and decrypt it in-place. The page lock must be held until decryption has finished, to prevent the @@ -1197,18 +1248,6 @@ buffer. Some filesystems, such as UBIFS, already use temporary buffers regardless of encryption. Other filesystems, such as ext4 and F2FS, have to allocate bounce pages specially for encryption. -Fscrypt is also able to use inline encryption hardware instead of the -kernel crypto API for en/decryption of file contents. When possible, -and if directed to do so (by specifying the 'inlinecrypt' mount option -for an ext4/F2FS filesystem), it adds encryption contexts to bios and -uses blk-crypto to perform the en/decryption instead of making use of -the above read/write path changes. Of course, even if directed to -make use of inline encryption, fscrypt will only be able to do so if -either hardware inline encryption support is available for the -selected encryption algorithm or CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK -is selected. If neither is the case, fscrypt will fall back to using -the above mentioned read/write path changes for en/decryption. - Filename hashing and encoding ----------------------------- diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index c0ad233963ae..bee63d42e5ec 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -29,7 +29,6 @@ algorithms work. fiemap files locks - mandatory-locking mount_api quota seq_file diff --git a/Documentation/filesystems/locks.rst b/Documentation/filesystems/locks.rst index c5ae858b1aac..26429317dbbc 100644 --- a/Documentation/filesystems/locks.rst +++ b/Documentation/filesystems/locks.rst @@ -57,16 +57,9 @@ fcntl(), with all the problems that implies. 1.3 Mandatory Locking As A Mount Option --------------------------------------- -Mandatory locking, as described in -'Documentation/filesystems/mandatory-locking.rst' was prior to this release a -general configuration option that was valid for all mounted filesystems. This -had a number of inherent dangers, not the least of which was the ability to -freeze an NFS server by asking it to read a file for which a mandatory lock -existed. - -From this release of the kernel, mandatory locking can be turned on and off -on a per-filesystem basis, using the mount options 'mand' and 'nomand'. -The default is to disallow mandatory locking. The intention is that -mandatory locking only be enabled on a local filesystem as the specific need -arises. +Mandatory locking was prior to this release a general configuration option +that was valid for all mounted filesystems. This had a number of inherent +dangers, not the least of which was the ability to freeze an NFS server by +asking it to read a file for which a mandatory lock existed. +Such option was dropped in Kernel v5.14. diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 57a641847818..bb68d39f03b7 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -524,3 +524,5 @@ Note that these methods are passed a pointer to the cache resource structure, not the read request structure as they could be used in other situations where there isn't a read request structure as well, such as writing dirty data to the cache. + +.. kernel-doc:: include/linux/netfs.h diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst index ffe9ea0c1499..d67ccd22c63b 100644 --- a/Documentation/filesystems/ntfs3.rst +++ b/Documentation/filesystems/ntfs3.rst @@ -4,103 +4,112 @@ NTFS3 ===== - Summary and Features ==================== -NTFS3 is fully functional NTFS Read-Write driver. The driver works with -NTFS versions up to 3.1, normal/compressed/sparse files -and journal replaying. File system type to use on mount is 'ntfs3'. +NTFS3 is fully functional NTFS Read-Write driver. The driver works with NTFS +versions up to 3.1. File system type to use on mount is *ntfs3*. - This driver implements NTFS read/write support for normal, sparse and compressed files. -- Supports native journal replaying; -- Supports extended attributes - Predefined extended attributes: - - 'system.ntfs_security' gets/sets security - descriptor (SECURITY_DESCRIPTOR_RELATIVE) - - 'system.ntfs_attrib' gets/sets ntfs file/dir attributes. - Note: applied to empty files, this allows to switch type between - sparse(0x200), compressed(0x800) and normal; +- Supports native journal replaying. - Supports NFS export of mounted NTFS volumes. +- Supports extended attributes. Predefined extended attributes: + + - *system.ntfs_security* gets/sets security + + Descriptor: SECURITY_DESCRIPTOR_RELATIVE + + - *system.ntfs_attrib* gets/sets ntfs file/dir attributes. + + Note: Applied to empty files, this allows to switch type between + sparse(0x200), compressed(0x800) and normal. Mount Options ============= The list below describes mount options supported by NTFS3 driver in addition to -generic ones. +generic ones. You can use every mount option with **no** option. If it is in +this table marked with no it means default is without **no**. -=============================================================================== +.. flat-table:: + :widths: 1 5 + :fill-cells: -nls=name This option informs the driver how to interpret path - strings and translate them to Unicode and back. If - this option is not set, the default codepage will be - used (CONFIG_NLS_DEFAULT). - Examples: - 'nls=utf8' + * - iocharset=name + - This option informs the driver how to interpret path strings and + translate them to Unicode and back. If this option is not set, the + default codepage will be used (CONFIG_NLS_DEFAULT). -uid= -gid= -umask= Controls the default permissions for files/directories created - after the NTFS volume is mounted. + Example: iocharset=utf8 -fmask= -dmask= Instead of specifying umask which applies both to - files and directories, fmask applies only to files and - dmask only to directories. + * - uid= + - :rspan:`1` + * - gid= -nohidden Files with the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN) - attribute will not be shown under Linux. + * - umask= + - Controls the default permissions for files/directories created after + the NTFS volume is mounted. -sys_immutable Files with the Windows-specific SYSTEM - (FILE_ATTRIBUTE_SYSTEM) attribute will be marked as system - immutable files. + * - dmask= + - :rspan:`1` Instead of specifying umask which applies both to files and + directories, fmask applies only to files and dmask only to directories. + * - fmask= -discard Enable support of the TRIM command for improved performance - on delete operations, which is recommended for use with the - solid-state drives (SSD). + * - noacsrules + - "No access rules" mount option sets access rights for files/folders to + 777 and owner/group to root. This mount option absorbs all other + permissions. -force Forces the driver to mount partitions even if 'dirty' flag - (volume dirty) is set. Not recommended for use. + - Permissions change for files/folders will be reported as successful, + but they will remain 777. -sparse Create new files as "sparse". + - Owner/group change will be reported as successful, butthey will stay + as root. -showmeta Use this parameter to show all meta-files (System Files) on - a mounted NTFS partition. - By default, all meta-files are hidden. + * - nohidden + - Files with the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN) attribute + will not be shown under Linux. -prealloc Preallocate space for files excessively when file size is - increasing on writes. Decreases fragmentation in case of - parallel write operations to different files. + * - sys_immutable + - Files with the Windows-specific SYSTEM (FILE_ATTRIBUTE_SYSTEM) attribute + will be marked as system immutable files. -no_acs_rules "No access rules" mount option sets access rights for - files/folders to 777 and owner/group to root. This mount - option absorbs all other permissions: - - permissions change for files/folders will be reported - as successful, but they will remain 777; - - owner/group change will be reported as successful, but - they will stay as root + * - discard + - Enable support of the TRIM command for improved performance on delete + operations, which is recommended for use with the solid-state drives + (SSD). -acl Support POSIX ACLs (Access Control Lists). Effective if - supported by Kernel. Not to be confused with NTFS ACLs. - The option specified as acl enables support for POSIX ACLs. + * - force + - Forces the driver to mount partitions even if volume is marked dirty. + Not recommended for use. -noatime All files and directories will not update their last access - time attribute if a partition is mounted with this parameter. - This option can speed up file system operation. + * - sparse + - Create new files as sparse. -=============================================================================== + * - showmeta + - Use this parameter to show all meta-files (System Files) on a mounted + NTFS partition. By default, all meta-files are hidden. -ToDo list -========= + * - prealloc + - Preallocate space for files excessively when file size is increasing on + writes. Decreases fragmentation in case of parallel write operations to + different files. -- Full journaling support (currently journal replaying is supported) over JBD. + * - acl + - Support POSIX ACLs (Access Control Lists). Effective if supported by + Kernel. Not to be confused with NTFS ACLs. The option specified as acl + enables support for POSIX ACLs. +Todo list +========= +- Full journaling support over JBD. Currently journal replaying is supported + which is not necessarily as effectice as JBD would be. References ========== -https://www.paragon-software.com/home/ntfs-linux-professional/ - - Commercial version of the NTFS driver for Linux. +- Commercial version of the NTFS driver for Linux. + https://www.paragon-software.com/home/ntfs-linux-professional/ -almaz.alexandrovich@paragon-software.com - - Direct e-mail address for feedback and requests on the NTFS3 implementation. +- Direct e-mail address for feedback and requests on the NTFS3 implementation. + almaz.alexandrovich@paragon-software.com diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst index 364680cdad2e..8ba72e898099 100644 --- a/Documentation/gpu/amdgpu.rst +++ b/Documentation/gpu/amdgpu.rst @@ -300,8 +300,8 @@ pcie_replay_count .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c :doc: pcie_replay_count -+GPU SmartShift Information -============================ +GPU SmartShift Information +========================== GPU SmartShift information via sysfs diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 06af044c882f..607f78f0f189 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -111,15 +111,6 @@ Component Helper Usage .. kernel-doc:: drivers/gpu/drm/drm_drv.c :doc: component helper usage recommendations -IRQ Helper Library -~~~~~~~~~~~~~~~~~~ - -.. kernel-doc:: drivers/gpu/drm/drm_irq.c - :doc: irq helpers - -.. kernel-doc:: drivers/gpu/drm/drm_irq.c - :export: - Memory Manager Initialization ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/hwmon/dell-smm-hwmon.rst b/Documentation/hwmon/dell-smm-hwmon.rst index 3bf77a5df995..beec88491171 100644 --- a/Documentation/hwmon/dell-smm-hwmon.rst +++ b/Documentation/hwmon/dell-smm-hwmon.rst @@ -34,6 +34,9 @@ Name Perm Description =============================== ======= ======================================= fan[1-3]_input RO Fan speed in RPM. fan[1-3]_label RO Fan label. +fan[1-3]_min RO Minimal Fan speed in RPM +fan[1-3]_max RO Maximal Fan speed in RPM +fan[1-3]_target RO Expected Fan speed in RPM pwm[1-3] RW Control the fan PWM duty-cycle. pwm1_enable WO Enable or disable automatic BIOS fan control (not supported on all laptops, diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index f790f1260c33..7046bf1870d9 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -130,6 +130,7 @@ Hardware Monitoring Kernel Drivers max31785 max31790 max34440 + max6620 max6639 max6642 max6650 diff --git a/Documentation/hwmon/k10temp.rst b/Documentation/hwmon/k10temp.rst index 8557e26281c3..91b99adc6c48 100644 --- a/Documentation/hwmon/k10temp.rst +++ b/Documentation/hwmon/k10temp.rst @@ -132,20 +132,3 @@ On Family 17h and Family 18h CPUs, additional temperature sensors may report Core Complex Die (CCD) temperatures. Up to 8 such temperatures are reported as temp{3..10}_input, labeled Tccd{1..8}. Actual support depends on the CPU variant. - -Various Family 17h and 18h CPUs report voltage and current telemetry -information. The following attributes may be reported. - -Attribute Label Description -=============== ======= ================ -in0_input Vcore Core voltage -in1_input Vsoc SoC voltage -curr1_input Icore Core current -curr2_input Isoc SoC current -=============== ======= ================ - -Current values are raw (unscaled) as reported by the CPU. Core current is -reported as multiples of 1A / LSB. SoC is reported as multiples of 0.25A -/ LSB. The real current is board specific. Reported currents should be seen -as rough guidance, and should be scaled using sensors3.conf as appropriate -for a given board. diff --git a/Documentation/hwmon/lm25066.rst b/Documentation/hwmon/lm25066.rst index 9f1d7e4d3ca1..a2098eb24090 100644 --- a/Documentation/hwmon/lm25066.rst +++ b/Documentation/hwmon/lm25066.rst @@ -79,6 +79,8 @@ This driver does not auto-detect devices. You will have to instantiate the devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for details. +The shunt (sense) resistor value can be configured by a device tree property; +see Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml for details. Platform data support --------------------- diff --git a/Documentation/hwmon/lm90.rst b/Documentation/hwmon/lm90.rst index 3da8c6e06a36..05391fb4042d 100644 --- a/Documentation/hwmon/lm90.rst +++ b/Documentation/hwmon/lm90.rst @@ -265,6 +265,16 @@ Supported chips: https://www.ti.com/litv/pdf/sbos686 + * Texas Instruments TMP461 + + Prefix: 'tmp461' + + Addresses scanned: I2C 0x48 through 0x4F + + Datasheet: Publicly available at TI website + + https://www.ti.com/lit/gpn/tmp461 + Author: Jean Delvare <jdelvare@suse.de> diff --git a/Documentation/hwmon/max6620.rst b/Documentation/hwmon/max6620.rst new file mode 100644 index 000000000000..84c1c44d3de4 --- /dev/null +++ b/Documentation/hwmon/max6620.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver max6620 +===================== + +Supported chips: + + Maxim MAX6620 + + Prefix: 'max6620' + + Addresses scanned: none + + Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6620.pdf + +Authors: + - L\. Grunenberg <contact@lgrunenberg.de> + - Cumulus Networks <support@cumulusnetworks.com> + - Shuotian Cheng <shuche@microsoft.com> + - Arun Saravanan Balachandran <Arun_Saravanan_Balac@dell.com> + +Description +----------- + +This driver implements support for Maxim MAX6620 fan controller. + +The driver configures the fan controller in RPM mode. To give the readings more +range or accuracy, the desired value can be set by a programmable register +(1, 2, 4, 8, 16 or 32). Set higher values for larger speeds. + +The driver provides the following sensor access in sysfs: + +================ ======= ===================================================== +fan[1-4]_alarm ro Fan alarm. +fan[1-4]_div rw Sets the nominal RPM range of the fan. Valid values + are 1, 2, 4, 8, 16 and 32. +fan[1-4]_input ro Fan speed in RPM. +fan[1-4]_target rw Desired fan speed in RPM. +================ ======= ===================================================== + +Usage notes +----------- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for +details. diff --git a/Documentation/hwmon/tmp401.rst b/Documentation/hwmon/tmp401.rst index 14bf1fbf4493..3aacf3d3bdf3 100644 --- a/Documentation/hwmon/tmp401.rst +++ b/Documentation/hwmon/tmp401.rst @@ -43,12 +43,6 @@ Supported chips: Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp435.html - * Texas Instruments TMP461 - - Prefix: 'tmp461' - - Datasheet: https://www.ti.com/product/tmp461 - Authors: @@ -60,7 +54,7 @@ Description ----------- This driver implements support for Texas Instruments TMP401, TMP411, -TMP431, TMP432, TMP435, and TMP461 chips. These chips implement one or two +TMP431, TMP432, and TMP435 chips. These chips implement one or two remote and one local temperature sensors. Temperature is measured in degrees Celsius. Resolution of the remote sensor is 0.0625 degree. Local sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not @@ -84,10 +78,3 @@ some additional features. TMP432 is compatible with TMP401 and TMP431. It supports two external temperature sensors. - -TMP461 is compatible with TMP401. It supports offset correction -that is applied to the remote sensor. - -* Sensor offset values are temperature values - - Exported via sysfs attribute tempX_offset diff --git a/Documentation/hwmon/tmp421.rst b/Documentation/hwmon/tmp421.rst index ddcd5159c75d..a3002117bbd7 100644 --- a/Documentation/hwmon/tmp421.rst +++ b/Documentation/hwmon/tmp421.rst @@ -64,3 +64,13 @@ the temperature values via the following sysfs files: **temp[1-4]_input** **temp[2-4]_fault** + +Each sensor can be individually disabled via Devicetree or from sysfs +via: + +**temp[1-4]_enable** + +If labels were specified in Devicetree, additional sysfs files will +be present: + +**temp[1-4]_label** diff --git a/Documentation/kbuild/gcc-plugins.rst b/Documentation/kbuild/gcc-plugins.rst index 3349966f213d..0ba76719f1b9 100644 --- a/Documentation/kbuild/gcc-plugins.rst +++ b/Documentation/kbuild/gcc-plugins.rst @@ -32,6 +32,32 @@ This infrastructure was ported from grsecurity [6]_ and PaX [7]_. .. [7] https://pax.grsecurity.net/ +Purpose +======= + +GCC plugins are designed to provide a place to experiment with potential +compiler features that are neither in GCC nor Clang upstream. Once +their utility is proven, the goal is to upstream the feature into GCC +(and Clang), and then to finally remove them from the kernel once the +feature is available in all supported versions of GCC. + +Specifically, new plugins should implement only features that have no +upstream compiler support (in either GCC or Clang). + +When a feature exists in Clang but not GCC, effort should be made to +bring the feature to upstream GCC (rather than just as a kernel-specific +GCC plugin), so the entire ecosystem can benefit from it. + +Similarly, even if a feature provided by a GCC plugin does *not* exist +in Clang, but the feature is proven to be useful, effort should be spent +to upstream the feature to GCC (and Clang). + +After a feature is available in upstream GCC, the plugin will be made +unbuildable for the corresponding GCC version (and later). Once all +kernel-supported versions of GCC provide the feature, the plugin will +be removed from the kernel. + + Files ===== @@ -70,7 +96,6 @@ Enable the GCC plugin infrastructure and some plugin(s) you want to use in the kernel config:: CONFIG_GCC_PLUGINS=y - CONFIG_GCC_PLUGIN_CYC_COMPLEXITY=y CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y ... @@ -89,4 +114,3 @@ The GCC plugins are in scripts/gcc-plugins/. You need to put plugin source files right under scripts/gcc-plugins/. Creating subdirectories is not supported. It must be added to scripts/gcc-plugins/Makefile, scripts/Makefile.gcc-plugins and a relevant Kconfig file. -See the cyc_complexity_plugin.c (CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) GCC plugin. diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst index 90bc3f51eda9..e6cd40663ea5 100644 --- a/Documentation/kernel-hacking/locking.rst +++ b/Documentation/kernel-hacking/locking.rst @@ -1352,7 +1352,19 @@ Mutex API reference Futex API reference =================== -.. kernel-doc:: kernel/futex.c +.. kernel-doc:: kernel/futex/core.c + :internal: + +.. kernel-doc:: kernel/futex/futex.h + :internal: + +.. kernel-doc:: kernel/futex/pi.c + :internal: + +.. kernel-doc:: kernel/futex/requeue.c + :internal: + +.. kernel-doc:: kernel/futex/waitwake.c :internal: Further reading diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index a432dc419fa4..5d97cee9457b 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -30,10 +30,11 @@ The ``ice`` driver reports the following versions PHY, link, etc. * - ``fw.mgmt.api`` - running - - 1.5 - - 2-digit version number of the API exported over the AdminQ by the - management firmware. Used by the driver to identify what commands - are supported. + - 1.5.1 + - 3-digit version number (major.minor.patch) of the API exported over + the AdminQ by the management firmware. Used by the driver to + identify what commands are supported. Historical versions of the + kernel only displayed a 2-digit version number (major.minor). * - ``fw.mgmt.build`` - running - 0x305d955f diff --git a/Documentation/networking/mctp.rst b/Documentation/networking/mctp.rst index 6100cdc220f6..fa7730dbf7b9 100644 --- a/Documentation/networking/mctp.rst +++ b/Documentation/networking/mctp.rst @@ -59,11 +59,11 @@ specified with a ``sockaddr`` type, with a single-byte endpoint address: }; struct sockaddr_mctp { - unsigned short int smctp_family; - int smctp_network; - struct mctp_addr smctp_addr; - __u8 smctp_type; - __u8 smctp_tag; + __kernel_sa_family_t smctp_family; + unsigned int smctp_network; + struct mctp_addr smctp_addr; + __u8 smctp_type; + __u8 smctp_tag; }; #define MCTP_NET_ANY 0x0 diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst index 1fc73555f5c4..173c14110c85 100644 --- a/Documentation/scheduler/sched-bwc.rst +++ b/Documentation/scheduler/sched-bwc.rst @@ -22,9 +22,52 @@ cfs_quota units at each period boundary. As threads consume this bandwidth it is transferred to cpu-local "silos" on a demand basis. The amount transferred within each of these updates is tunable and described as the "slice". +Burst feature +------------- +This feature borrows time now against our future underrun, at the cost of +increased interference against the other system users. All nicely bounded. + +Traditional (UP-EDF) bandwidth control is something like: + + (U = \Sum u_i) <= 1 + +This guaranteeds both that every deadline is met and that the system is +stable. After all, if U were > 1, then for every second of walltime, +we'd have to run more than a second of program time, and obviously miss +our deadline, but the next deadline will be further out still, there is +never time to catch up, unbounded fail. + +The burst feature observes that a workload doesn't always executes the full +quota; this enables one to describe u_i as a statistical distribution. + +For example, have u_i = {x,e}_i, where x is the p(95) and x+e p(100) +(the traditional WCET). This effectively allows u to be smaller, +increasing the efficiency (we can pack more tasks in the system), but at +the cost of missing deadlines when all the odds line up. However, it +does maintain stability, since every overrun must be paired with an +underrun as long as our x is above the average. + +That is, suppose we have 2 tasks, both specify a p(95) value, then we +have a p(95)*p(95) = 90.25% chance both tasks are within their quota and +everything is good. At the same time we have a p(5)p(5) = 0.25% chance +both tasks will exceed their quota at the same time (guaranteed deadline +fail). Somewhere in between there's a threshold where one exceeds and +the other doesn't underrun enough to compensate; this depends on the +specific CDFs. + +At the same time, we can say that the worst case deadline miss, will be +\Sum e_i; that is, there is a bounded tardiness (under the assumption +that x+e is indeed WCET). + +The interferenece when using burst is valued by the possibilities for +missing the deadline and the average WCET. Test results showed that when +there many cgroups or CPU is under utilized, the interference is +limited. More details are shown in: +https://lore.kernel.org/lkml/5371BD36-55AE-4F71-B9D7-B86DC32E3D2B@linux.alibaba.com/ + Management ---------- -Quota and period are managed within the cpu subsystem via cgroupfs. +Quota, period and burst are managed within the cpu subsystem via cgroupfs. .. note:: The cgroupfs files described in this section are only applicable @@ -32,29 +75,37 @@ Quota and period are managed within the cpu subsystem via cgroupfs. :ref:`Documentation/admin-guide/cgroup-v2.rst <cgroup-v2-cpu>`. - cpu.cfs_quota_us: the total available run-time within a period (in - microseconds) +- cpu.cfs_quota_us: run-time replenished within a period (in microseconds) - cpu.cfs_period_us: the length of a period (in microseconds) - cpu.stat: exports throttling statistics [explained further below] +- cpu.cfs_burst_us: the maximum accumulated run-time (in microseconds) The default values are:: cpu.cfs_period_us=100ms - cpu.cfs_quota=-1 + cpu.cfs_quota_us=-1 + cpu.cfs_burst_us=0 A value of -1 for cpu.cfs_quota_us indicates that the group does not have any bandwidth restriction in place, such a group is described as an unconstrained bandwidth group. This represents the traditional work-conserving behavior for CFS. -Writing any (valid) positive value(s) will enact the specified bandwidth limit. -The minimum quota allowed for the quota or period is 1ms. There is also an -upper bound on the period length of 1s. Additional restrictions exist when -bandwidth limits are used in a hierarchical fashion, these are explained in -more detail below. +Writing any (valid) positive value(s) no smaller than cpu.cfs_burst_us will +enact the specified bandwidth limit. The minimum quota allowed for the quota or +period is 1ms. There is also an upper bound on the period length of 1s. +Additional restrictions exist when bandwidth limits are used in a hierarchical +fashion, these are explained in more detail below. Writing any negative value to cpu.cfs_quota_us will remove the bandwidth limit and return the group to an unconstrained state once more. +A value of 0 for cpu.cfs_burst_us indicates that the group can not accumulate +any unused bandwidth. It makes the traditional bandwidth control behavior for +CFS unchanged. Writing any (valid) positive value(s) no larger than +cpu.cfs_quota_us into cpu.cfs_burst_us will enact the cap on unused bandwidth +accumulation. + Any updates to a group's bandwidth specification will result in it becoming unthrottled if it is in a constrained state. @@ -74,7 +125,7 @@ for more fine-grained consumption. Statistics ---------- -A group's bandwidth statistics are exported via 3 fields in cpu.stat. +A group's bandwidth statistics are exported via 5 fields in cpu.stat. cpu.stat: @@ -82,6 +133,9 @@ cpu.stat: - nr_throttled: Number of times the group has been throttled/limited. - throttled_time: The total time duration (in nanoseconds) for which entities of the group have been throttled. +- nr_bursts: Number of periods burst occurs. +- burst_time: Cumulative wall-time (in nanoseconds) that any CPUs has used + above quota in respective periods This interface is read-only. @@ -179,3 +233,15 @@ Examples By using a small period here we are ensuring a consistent latency response at the expense of burst capacity. + +4. Limit a group to 40% of 1 CPU, and allow accumulate up to 20% of 1 CPU + additionally, in case accumulation has been done. + + With 50ms period, 20ms quota will be equivalent to 40% of 1 CPU. + And 10ms burst will be equivalent to 20% of 1 CPU. + + # echo 20000 > cpu.cfs_quota_us /* quota = 20ms */ + # echo 50000 > cpu.cfs_period_us /* period = 50ms */ + # echo 10000 > cpu.cfs_burst_us /* burst = 10ms */ + + Larger buffer setting (no larger than quota) allows greater burst capacity. diff --git a/Documentation/spi/spi-summary.rst b/Documentation/spi/spi-summary.rst index d4239025461d..aab5d07cb3d7 100644 --- a/Documentation/spi/spi-summary.rst +++ b/Documentation/spi/spi-summary.rst @@ -336,14 +336,6 @@ certainly includes SPI devices hooked up through the card connectors! Non-static Configurations ^^^^^^^^^^^^^^^^^^^^^^^^^ -Developer boards often play by different rules than product boards, and one -example is the potential need to hotplug SPI devices and/or controllers. - -For those cases you might need to use spi_busnum_to_master() to look -up the spi bus master, and will likely need spi_new_device() to provide the -board info based on the board that was hotplugged. Of course, you'd later -call at least spi_unregister_device() when that board is removed. - When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those configurations will also be dynamic. Fortunately, such devices all support basic device identification probes, so they should hotplug normally. diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index 1efb8293bf1f..163f1bd4e857 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -1396,7 +1396,19 @@ Riferimento per l'API dei Mutex Riferimento per l'API dei Futex =============================== -.. kernel-doc:: kernel/futex.c +.. kernel-doc:: kernel/futex/core.c + :internal: + +.. kernel-doc:: kernel/futex/futex.h + :internal: + +.. kernel-doc:: kernel/futex/pi.c + :internal: + +.. kernel-doc:: kernel/futex/requeue.c + :internal: + +.. kernel-doc:: kernel/futex/waitwake.c :internal: Approfondimenti diff --git a/Documentation/userspace-api/futex2.rst b/Documentation/userspace-api/futex2.rst new file mode 100644 index 000000000000..9693f47a7e62 --- /dev/null +++ b/Documentation/userspace-api/futex2.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====== +futex2 +====== + +:Author: André Almeida <andrealmeid@collabora.com> + +futex, or fast user mutex, is a set of syscalls to allow userspace to create +performant synchronization mechanisms, such as mutexes, semaphores and +conditional variables in userspace. C standard libraries, like glibc, uses it +as a means to implement more high level interfaces like pthreads. + +futex2 is a followup version of the initial futex syscall, designed to overcome +limitations of the original interface. + +User API +======== + +``futex_waitv()`` +----------------- + +Wait on an array of futexes, wake on any:: + + futex_waitv(struct futex_waitv *waiters, unsigned int nr_futexes, + unsigned int flags, struct timespec *timeout, clockid_t clockid) + + struct futex_waitv { + __u64 val; + __u64 uaddr; + __u32 flags; + __u32 __reserved; + }; + +Userspace sets an array of struct futex_waitv (up to a max of 128 entries), +using ``uaddr`` for the address to wait for, ``val`` for the expected value +and ``flags`` to specify the type (e.g. private) and size of futex. +``__reserved`` needs to be 0, but it can be used for future extension. The +pointer for the first item of the array is passed as ``waiters``. An invalid +address for ``waiters`` or for any ``uaddr`` returns ``-EFAULT``. + +If userspace has 32-bit pointers, it should do a explicit cast to make sure +the upper bits are zeroed. ``uintptr_t`` does the tricky and it works for +both 32/64-bit pointers. + +``nr_futexes`` specifies the size of the array. Numbers out of [1, 128] +interval will make the syscall return ``-EINVAL``. + +The ``flags`` argument of the syscall needs to be 0, but it can be used for +future extension. + +For each entry in ``waiters`` array, the current value at ``uaddr`` is compared +to ``val``. If it's different, the syscall undo all the work done so far and +return ``-EAGAIN``. If all tests and verifications succeeds, syscall waits until +one of the following happens: + +- The timeout expires, returning ``-ETIMEOUT``. +- A signal was sent to the sleeping task, returning ``-ERESTARTSYS``. +- Some futex at the list was woken, returning the index of some waked futex. + +An example of how to use the interface can be found at ``tools/testing/selftests/futex/functional/futex_waitv.c``. + +Timeout +------- + +``struct timespec *timeout`` argument is an optional argument that points to an +absolute timeout. You need to specify the type of clock being used at +``clockid`` argument. ``CLOCK_MONOTONIC`` and ``CLOCK_REALTIME`` are supported. +This syscall accepts only 64bit timespec structs. + +Types of futex +-------------- + +A futex can be either private or shared. Private is used for processes that +shares the same memory space and the virtual address of the futex will be the +same for all processes. This allows for optimizations in the kernel. To use +private futexes, it's necessary to specify ``FUTEX_PRIVATE_FLAG`` in the futex +flag. For processes that doesn't share the same memory space and therefore can +have different virtual addresses for the same futex (using, for instance, a +file-backed shared memory) requires different internal mechanisms to be get +properly enqueued. This is the default behavior, and it works with both private +and shared futexes. + +Futexes can be of different sizes: 8, 16, 32 or 64 bits. Currently, the only +supported one is 32 bit sized futex, and it need to be specified using +``FUTEX_32`` flag. diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index c432be070f67..a61eac0c73f8 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -28,6 +28,7 @@ place where this information is gathered. media/index sysfs-platform_profile vduse + futex2 .. only:: subproject and html diff --git a/Documentation/userspace-api/ioctl/cdrom.rst b/Documentation/userspace-api/ioctl/cdrom.rst index 3b4c0506de46..682948fc88a3 100644 --- a/Documentation/userspace-api/ioctl/cdrom.rst +++ b/Documentation/userspace-api/ioctl/cdrom.rst @@ -13,61 +13,64 @@ in drivers/cdrom/cdrom.c and drivers/block/scsi_ioctl.c ioctl values are listed in <linux/cdrom.h>. As of this writing, they are as follows: - ====================== =============================================== - CDROMPAUSE Pause Audio Operation - CDROMRESUME Resume paused Audio Operation - CDROMPLAYMSF Play Audio MSF (struct cdrom_msf) - CDROMPLAYTRKIND Play Audio Track/index (struct cdrom_ti) - CDROMREADTOCHDR Read TOC header (struct cdrom_tochdr) - CDROMREADTOCENTRY Read TOC entry (struct cdrom_tocentry) - CDROMSTOP Stop the cdrom drive - CDROMSTART Start the cdrom drive - CDROMEJECT Ejects the cdrom media - CDROMVOLCTRL Control output volume (struct cdrom_volctrl) - CDROMSUBCHNL Read subchannel data (struct cdrom_subchnl) - CDROMREADMODE2 Read CDROM mode 2 data (2336 Bytes) - (struct cdrom_read) - CDROMREADMODE1 Read CDROM mode 1 data (2048 Bytes) - (struct cdrom_read) - CDROMREADAUDIO (struct cdrom_read_audio) - CDROMEJECT_SW enable(1)/disable(0) auto-ejecting - CDROMMULTISESSION Obtain the start-of-last-session - address of multi session disks - (struct cdrom_multisession) - CDROM_GET_MCN Obtain the "Universal Product Code" - if available (struct cdrom_mcn) - CDROM_GET_UPC Deprecated, use CDROM_GET_MCN instead. - CDROMRESET hard-reset the drive - CDROMVOLREAD Get the drive's volume setting - (struct cdrom_volctrl) - CDROMREADRAW read data in raw mode (2352 Bytes) - (struct cdrom_read) - CDROMREADCOOKED read data in cooked mode - CDROMSEEK seek msf address - CDROMPLAYBLK scsi-cd only, (struct cdrom_blk) - CDROMREADALL read all 2646 bytes - CDROMGETSPINDOWN return 4-bit spindown value - CDROMSETSPINDOWN set 4-bit spindown value - CDROMCLOSETRAY pendant of CDROMEJECT - CDROM_SET_OPTIONS Set behavior options - CDROM_CLEAR_OPTIONS Clear behavior options - CDROM_SELECT_SPEED Set the CD-ROM speed - CDROM_SELECT_DISC Select disc (for juke-boxes) - CDROM_MEDIA_CHANGED Check is media changed - CDROM_DRIVE_STATUS Get tray position, etc. - CDROM_DISC_STATUS Get disc type, etc. - CDROM_CHANGER_NSLOTS Get number of slots - CDROM_LOCKDOOR lock or unlock door - CDROM_DEBUG Turn debug messages on/off - CDROM_GET_CAPABILITY get capabilities - CDROMAUDIOBUFSIZ set the audio buffer size - DVD_READ_STRUCT Read structure - DVD_WRITE_STRUCT Write structure - DVD_AUTH Authentication - CDROM_SEND_PACKET send a packet to the drive - CDROM_NEXT_WRITABLE get next writable block - CDROM_LAST_WRITTEN get last block written on disc - ====================== =============================================== + ======================== =============================================== + CDROMPAUSE Pause Audio Operation + CDROMRESUME Resume paused Audio Operation + CDROMPLAYMSF Play Audio MSF (struct cdrom_msf) + CDROMPLAYTRKIND Play Audio Track/index (struct cdrom_ti) + CDROMREADTOCHDR Read TOC header (struct cdrom_tochdr) + CDROMREADTOCENTRY Read TOC entry (struct cdrom_tocentry) + CDROMSTOP Stop the cdrom drive + CDROMSTART Start the cdrom drive + CDROMEJECT Ejects the cdrom media + CDROMVOLCTRL Control output volume (struct cdrom_volctrl) + CDROMSUBCHNL Read subchannel data (struct cdrom_subchnl) + CDROMREADMODE2 Read CDROM mode 2 data (2336 Bytes) + (struct cdrom_read) + CDROMREADMODE1 Read CDROM mode 1 data (2048 Bytes) + (struct cdrom_read) + CDROMREADAUDIO (struct cdrom_read_audio) + CDROMEJECT_SW enable(1)/disable(0) auto-ejecting + CDROMMULTISESSION Obtain the start-of-last-session + address of multi session disks + (struct cdrom_multisession) + CDROM_GET_MCN Obtain the "Universal Product Code" + if available (struct cdrom_mcn) + CDROM_GET_UPC Deprecated, use CDROM_GET_MCN instead. + CDROMRESET hard-reset the drive + CDROMVOLREAD Get the drive's volume setting + (struct cdrom_volctrl) + CDROMREADRAW read data in raw mode (2352 Bytes) + (struct cdrom_read) + CDROMREADCOOKED read data in cooked mode + CDROMSEEK seek msf address + CDROMPLAYBLK scsi-cd only, (struct cdrom_blk) + CDROMREADALL read all 2646 bytes + CDROMGETSPINDOWN return 4-bit spindown value + CDROMSETSPINDOWN set 4-bit spindown value + CDROMCLOSETRAY pendant of CDROMEJECT + CDROM_SET_OPTIONS Set behavior options + CDROM_CLEAR_OPTIONS Clear behavior options + CDROM_SELECT_SPEED Set the CD-ROM speed + CDROM_SELECT_DISC Select disc (for juke-boxes) + CDROM_MEDIA_CHANGED Check is media changed + CDROM_TIMED_MEDIA_CHANGE Check if media changed + since given time + (struct cdrom_timed_media_change_info) + CDROM_DRIVE_STATUS Get tray position, etc. + CDROM_DISC_STATUS Get disc type, etc. + CDROM_CHANGER_NSLOTS Get number of slots + CDROM_LOCKDOOR lock or unlock door + CDROM_DEBUG Turn debug messages on/off + CDROM_GET_CAPABILITY get capabilities + CDROMAUDIOBUFSIZ set the audio buffer size + DVD_READ_STRUCT Read structure + DVD_WRITE_STRUCT Write structure + DVD_AUTH Authentication + CDROM_SEND_PACKET send a packet to the drive + CDROM_NEXT_WRITABLE get next writable block + CDROM_LAST_WRITTEN get last block written on disc + ======================== =============================================== The information that follows was determined from reading kernel source diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 2e8134059c87..6655d929a351 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -104,6 +104,7 @@ Code Seq# Include File Comments '8' all SNP8023 advanced NIC card <mailto:mcr@solidum.com> ';' 64-7F linux/vfio.h +'=' 00-3f uapi/linux/ptp_clock.h <mailto:richardcochran@gmail.com> '@' 00-0F linux/radeonfb.h conflict! '@' 00-0F drivers/video/aty/aty128fb.c conflict! 'A' 00-1F linux/apm_bios.h conflict! diff --git a/Documentation/userspace-api/media/drivers/cx2341x-uapi.rst b/Documentation/userspace-api/media/drivers/cx2341x-uapi.rst index 8a7977af79d5..debde65fb8cd 100644 --- a/Documentation/userspace-api/media/drivers/cx2341x-uapi.rst +++ b/Documentation/userspace-api/media/drivers/cx2341x-uapi.rst @@ -7,9 +7,7 @@ Non-compressed file format -------------------------- The cx23416 can produce (and the cx23415 can also read) raw YUV output. The -format of a YUV frame is specific to this chip and is called HM12. 'HM' stands -for 'Hauppauge Macroblock', which is a misnomer as 'Conexant Macroblock' would -be more accurate. +format of a YUV frame is 16x16 linear tiled NV12 (V4L2_PIX_FMT_NV12_16L16). The format is YUV 4:2:0 which uses 1 Y byte per pixel and 1 U and V byte per four pixels. @@ -34,8 +32,8 @@ second line of 8 UV pairs of the top-left block, etc. After transmitting this block the first line of the block on the right to the first block is transmitted, etc. -The code below is given as an example on how to convert HM12 to separate -Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels. +The code below is given as an example on how to convert V4L2_PIX_FMT_NV12_16L16 +to separate Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels. The width of a frame is always 720 pixels, regardless of the actual specified width. diff --git a/Documentation/userspace-api/media/v4l/buffer.rst b/Documentation/userspace-api/media/v4l/buffer.rst index e991ba73d873..4638ec64db00 100644 --- a/Documentation/userspace-api/media/v4l/buffer.rst +++ b/Documentation/userspace-api/media/v4l/buffer.rst @@ -676,8 +676,6 @@ Buffer Flags \normalsize -.. _memory-flags: - enum v4l2_memory ================ @@ -701,6 +699,44 @@ enum v4l2_memory - 4 - The buffer is used for :ref:`DMA shared buffer <dmabuf>` I/O. +.. _memory-flags: + +Memory Consistency Flags +------------------------ + +.. raw:: latex + + \small + +.. tabularcolumns:: |p{7.0cm}|p{2.1cm}|p{8.4cm}| + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + * .. _`V4L2-MEMORY-FLAG-NON-COHERENT`: + + - ``V4L2_MEMORY_FLAG_NON_COHERENT`` + - 0x00000001 + - A buffer is allocated either in coherent (it will be automatically + coherent between the CPU and the bus) or non-coherent memory. The + latter can provide performance gains, for instance the CPU cache + sync/flush operations can be avoided if the buffer is accessed by the + corresponding device only and the CPU does not read/write to/from that + buffer. However, this requires extra care from the driver -- it must + guarantee memory consistency by issuing a cache flush/sync when + consistency is needed. If this flag is set V4L2 will attempt to + allocate the buffer in non-coherent memory. The flag takes effect + only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the + queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS + <V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability. + +.. raw:: latex + + \normalsize Timecodes ========= diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 976d34445a24..e141f0e4eec9 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -3088,6 +3088,63 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - \normalsize +``V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX (struct)`` + Specifies the HEVC scaling matrix parameters used for the scaling process + for transform coefficients. + These matrix and parameters are defined according to :ref:`hevc`. + They are described in section 7.4.5 "Scaling list data semantics" of + the specification. + +.. c:type:: v4l2_ctrl_hevc_scaling_matrix + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{5.4cm}|p{6.8cm}|p{5.1cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_hevc_scaling_matrix + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``scaling_list_4x4[6][16]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_8x8[6][64]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_16x16[6][64]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_32x32[2][64]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_dc_coef_16x16[6]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_dc_coef_32x32[2]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + +.. raw:: latex + + \normalsize + .. c:type:: v4l2_hevc_dpb_entry .. raw:: latex diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst index de43f5c8486d..71f23f131f97 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst @@ -72,3 +72,23 @@ Image Source Control IDs * - __u32 - ``height`` - Height of the area. + +``V4L2_CID_NOTIFY_GAINS (integer array)`` + The sensor is notified what gains will be applied to the different + colour channels by subsequent processing (such as by an ISP). The + sensor is merely informed of these values in case it performs + processing that requires them, but it does not apply them itself to + the output pixels. + + Currently it is defined only for Bayer sensors, and is an array + control taking 4 gain values, being the gains for each of the + Bayer channels. The gains are always in the order B, Gb, Gr and R, + irrespective of the exact Bayer order of the sensor itself. + + The use of an array allows this control to be extended to sensors + with, for example, non-Bayer CFAs (colour filter arrays). + + The units for the gain values are linear, with the default value + representing a gain of exactly 1.0. For example, if this default value + is reported as being (say) 128, then a value of 192 would represent + a gain of exactly 1.5. diff --git a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst index 0b879c0da713..2f2133b4cd9c 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst @@ -48,14 +48,6 @@ please make a proposal on the linux-media mailing list. - ``V4L2_PIX_FMT_HI240`` - 'HI24' - 8 bit RGB format used by the BTTV driver. - * .. _V4L2-PIX-FMT-HM12: - - - ``V4L2_PIX_FMT_HM12`` - - 'HM12' - - YUV 4:2:0 format used by the IVTV driver. - - The format is documented in the kernel sources in the file - ``Documentation/userspace-api/media/drivers/cx2341x-uapi.rst`` * .. _V4L2-PIX-FMT-CPIA1: - ``V4L2_PIX_FMT_CPIA1`` @@ -246,20 +238,13 @@ please make a proposal on the linux-media mailing list. It is an opaque intermediate format and the MDP hardware must be used to convert ``V4L2_PIX_FMT_MT21C`` to ``V4L2_PIX_FMT_NV12M``, ``V4L2_PIX_FMT_YUV420M`` or ``V4L2_PIX_FMT_YVU420``. - * .. _V4L2-PIX-FMT-SUNXI-TILED-NV12: - - - ``V4L2_PIX_FMT_SUNXI_TILED_NV12`` - - 'ST12' - - Two-planar NV12-based format used by the video engine found on Allwinner - (codenamed sunxi) platforms, with 32x32 tiles for the luminance plane - and 32x64 tiles for the chrominance plane. The data in each tile is - stored in linear order, within the tile bounds. Each tile follows the - previous one linearly in memory (from left to right, top to bottom). - - The associated buffer dimensions are aligned to match an integer number - of tiles, resulting in 32-aligned resolutions for the luminance plane - and 16-aligned resolutions for the chrominance plane (with 2x2 - subsampling). + * .. _V4L2-PIX-FMT-MM21: + + - ``V4L2_PIX_FMT_MM21`` + - 'MM21' + - Non-compressed, tiled two-planar format used by Mediatek MT8183. + This is an opaque intermediate format and the MDP3 hardware can be + used to convert it to other formats. .. raw:: latex diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index 090c091affd2..3a09d93d405b 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -99,7 +99,7 @@ All components are stored with the same number of bits per component. - 4:2:0 - Cb, Cr - No - - 64x32 macroblocks + - 64x32 tiles Horizontal Z order * - V4L2_PIX_FMT_NV12MT_16X16 @@ -108,7 +108,7 @@ All components are stored with the same number of bits per component. - 4:2:2 - Cb, Cr - No - - 16x16 macroblocks + - 16x16 tiles * - V4L2_PIX_FMT_NV16 - 'NV16' - 8 @@ -254,27 +254,47 @@ of the luma plane. .. _V4L2-PIX-FMT-NV12MT: .. _V4L2-PIX-FMT-NV12MT-16X16: +.. _V4L2-PIX-FMT-NV12-4L4: +.. _V4L2-PIX-FMT-NV12-16L16: +.. _V4L2-PIX-FMT-NV12-32L32: -NV12MT and MV12MT_16X16 ------------------------ +Tiled NV12 +---------- Semi-planar YUV 4:2:0 formats, using macroblock tiling. The chroma plane is subsampled by 2 in each direction. Chroma lines contain half the number of pixels and the same number of bytes as luma lines, and the chroma plane -contains half the number of lines of the luma plane. +contains half the number of lines of the luma plane. Each tile follows the +previous one linearly in memory (from left to right, top to bottom). + +``V4L2_PIX_FMT_NV12MT_16X16`` is similar to ``V4L2_PIX_FMT_NV12M`` but stores +pixels in 2D 16x16 tiles, and stores tiles linearly in memory. +The line stride and image height must be aligned to a multiple of 16. +The layouts of the luma and chroma planes are identical. + +``V4L2_PIX_FMT_NV12MT`` is similar to ``V4L2_PIX_FMT_NV12M`` but stores +pixels in 2D 64x32 tiles, and stores 2x2 groups of tiles in +Z-order in memory, alternating Z and mirrored Z shapes horizontally. +The line stride must be a multiple of 128 pixels to ensure an +integer number of Z shapes. The image height must be a multiple of 32 pixels. +If the vertical resolution is an odd number of tiles, the last row of +tiles is stored in linear order. The layouts of the luma and chroma +planes are identical. + +``V4L2_PIX_FMT_NV12_4L4`` stores pixel in 4x4 tiles, and stores +tiles linearly in memory. The line stride and image height must be +aligned to a multiple of 4. The layouts of the luma and chroma planes are +identical. -``V4L2_PIX_FMT_NV12MT_16X16`` stores pixel in 2D 16x16 macroblocks, and stores -macroblocks linearly in memory. The line stride and image height must be +``V4L2_PIX_FMT_NV12_16L16`` stores pixel in 16x16 tiles, and stores +tiles linearly in memory. The line stride and image height must be aligned to a multiple of 16. The layouts of the luma and chroma planes are identical. -``V4L2_PIX_FMT_NV12MT`` stores pixels in 2D 64x32 macroblocks, and stores 2x2 -groups of macroblocks in Z-order in memory, alternating Z and mirrored Z shapes -horizontally. The line stride must be a multiple of 128 pixels to ensure an -integer number of Z shapes. The image height must be a multiple of 32 pixels. -If the vertical resolution is an odd number of macroblocks, the last row of -macroblocks is stored in linear order. The layouts of the luma and chroma -planes are identical. +``V4L2_PIX_FMT_NV12_32L32`` stores pixel in 32x32 tiles, and stores +tiles linearly in memory. The line stride and image height must be +aligned to a multiple of 32. The layouts of the luma and chroma planes are +identical. .. _nv12mt: @@ -290,7 +310,7 @@ planes are identical. :alt: nv12mt_example.svg :align: center - Example V4L2_PIX_FMT_NV12MT memory layout of macroblocks + Example V4L2_PIX_FMT_NV12MT memory layout of tiles .. _V4L2-PIX-FMT-NV16: diff --git a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst index f98f18c9e91c..a048a9f6b7b6 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst @@ -113,7 +113,12 @@ than the number requested. ``V4L2_MEMORY_MMAP`` and ``format.type`` to the buffer type. * - __u32 - - ``reserved``\ [7] + - ``flags`` + - Specifies additional buffer management attributes. + See :ref:`memory-flags`. + + * - __u32 + - ``reserved``\ [6] - A place holder for future extensions. Drivers and applications must set the array to zero. diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst index 80e8c63d530f..fd09677f64f8 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst @@ -95,3 +95,6 @@ EBUSY EACCES Attempt to set a read-only control or to get a write-only control. + + Or if there is an attempt to set an inactive control and the driver is + not capable of caching the new value until the control is active again. diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst index 2d6bc8d94380..fdde0ae6d521 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -470,3 +470,6 @@ EACCES Or the ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the device does not support requests. + + Or if there is an attempt to set an inactive control and the driver is + not capable of caching the new value until the control is active again. diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index f9ecf6276129..2f491c17dd5d 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -495,6 +495,12 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_ctrl_hevc_slice_params`, containing HEVC slice parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_HEVC_SCALING_MATRIX`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_hevc_scaling_matrix`, containing HEVC + scaling matrix for stateless video decoders. * - ``V4L2_CTRL_TYPE_VP8_FRAME`` - n/a - n/a diff --git a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst index 50ea72043bb0..099fa6695167 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst @@ -104,10 +104,13 @@ aborting or finishing any DMA in progress, an implicit ``V4L2_MEMORY_MMAP`` and ``type`` set to the buffer type. This will free any previously allocated buffers, so this is typically something that will be done at the start of the application. - * - __u32 - - ``reserved``\ [1] - - A place holder for future extensions. Drivers and applications - must set the array to zero. + * - __u8 + - ``flags`` + - Specifies additional buffer management attributes. + See :ref:`memory-flags`. + * - __u8 + - ``reserved``\ [3] + - Reserved for future extensions. .. _v4l2-buf-capabilities: .. _V4L2-BUF-CAP-SUPPORTS-MMAP: @@ -158,8 +161,9 @@ aborting or finishing any DMA in progress, an implicit - This capability is set by the driver to indicate that the queue supports cache and memory management hints. However, it's only valid when the queue is used for :ref:`memory mapping <mmap>` streaming I/O. See - :ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE <V4L2-BUF-FLAG-NO-CACHE-INVALIDATE>` and - :ref:`V4L2_BUF_FLAG_NO_CACHE_CLEAN <V4L2-BUF-FLAG-NO-CACHE-CLEAN>`. + :ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE <V4L2-BUF-FLAG-NO-CACHE-INVALIDATE>`, + :ref:`V4L2_BUF_FLAG_NO_CACHE_CLEAN <V4L2-BUF-FLAG-NO-CACHE-CLEAN>` and + :ref:`V4L2_MEMORY_FLAG_NON_COHERENT <V4L2-MEMORY-FLAG-NON-COHERENT>`. .. raw:: latex diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index 2217b56c2686..eb0b1cd37abd 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -187,6 +187,8 @@ replace define V4L2_CAP_IO_MC device-capabilities # V4L2 pix flags replace define V4L2_PIX_FMT_PRIV_MAGIC :c:type:`v4l2_pix_format` replace define V4L2_PIX_FMT_FLAG_PREMUL_ALPHA format-flags +replace define V4L2_PIX_FMT_HM12 :c:type:`v4l2_pix_format` +replace define V4L2_PIX_FMT_SUNXI_TILED_NV12 :c:type:`v4l2_pix_format` # V4L2 format flags replace define V4L2_FMT_FLAG_COMPRESSED fmtdesc-flags diff --git a/Documentation/userspace-api/vduse.rst b/Documentation/userspace-api/vduse.rst index 42ef59ea5314..bdb880e01132 100644 --- a/Documentation/userspace-api/vduse.rst +++ b/Documentation/userspace-api/vduse.rst @@ -18,7 +18,7 @@ types can be added after the security issue of corresponding device driver is clarified or fixed in the future. Create/Destroy VDUSE devices ------------------------- +---------------------------- VDUSE devices are created as follows: diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 383048396336..f498f1d36cd3 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -37,3 +37,4 @@ x86-specific Documentation sgx features elf_auxvec + xstate diff --git a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst index dd0ac96ff9ef..a608f667fb95 100644 --- a/Documentation/x86/sgx.rst +++ b/Documentation/x86/sgx.rst @@ -250,3 +250,38 @@ user wants to deploy SGX applications both on the host and in guests on the same machine, the user should reserve enough EPC (by taking out total virtual EPC size of all SGX VMs from the physical EPC size) for host SGX applications so they can run with acceptable performance. + +Architectural behavior is to restore all EPC pages to an uninitialized +state also after a guest reboot. Because this state can be reached only +through the privileged ``ENCLS[EREMOVE]`` instruction, ``/dev/sgx_vepc`` +provides the ``SGX_IOC_VEPC_REMOVE_ALL`` ioctl to execute the instruction +on all pages in the virtual EPC. + +``EREMOVE`` can fail for three reasons. Userspace must pay attention +to expected failures and handle them as follows: + +1. Page removal will always fail when any thread is running in the + enclave to which the page belongs. In this case the ioctl will + return ``EBUSY`` independent of whether it has successfully removed + some pages; userspace can avoid these failures by preventing execution + of any vcpu which maps the virtual EPC. + +2. Page removal will cause a general protection fault if two calls to + ``EREMOVE`` happen concurrently for pages that refer to the same + "SECS" metadata pages. This can happen if there are concurrent + invocations to ``SGX_IOC_VEPC_REMOVE_ALL``, or if a ``/dev/sgx_vepc`` + file descriptor in the guest is closed at the same time as + ``SGX_IOC_VEPC_REMOVE_ALL``; it will also be reported as ``EBUSY``. + This can be avoided in userspace by serializing calls to the ioctl() + and to close(), but in general it should not be a problem. + +3. Finally, page removal will fail for SECS metadata pages which still + have child pages. Child pages can be removed by executing + ``SGX_IOC_VEPC_REMOVE_ALL`` on all ``/dev/sgx_vepc`` file descriptors + mapped into the guest. This means that the ioctl() must be called + twice: an initial set of calls to remove child pages and a subsequent + set of calls to remove SECS pages. The second set of calls is only + required for those mappings that returned a nonzero value from the + first call. It indicates a bug in the kernel or the userspace client + if any of the second round of ``SGX_IOC_VEPC_REMOVE_ALL`` calls has + a return code other than 0. diff --git a/Documentation/x86/xstate.rst b/Documentation/x86/xstate.rst new file mode 100644 index 000000000000..65de3f054ba5 --- /dev/null +++ b/Documentation/x86/xstate.rst @@ -0,0 +1,65 @@ +Using XSTATE features in user space applications +================================================ + +The x86 architecture supports floating-point extensions which are +enumerated via CPUID. Applications consult CPUID and use XGETBV to +evaluate which features have been enabled by the kernel XCR0. + +Up to AVX-512 and PKRU states, these features are automatically enabled by +the kernel if available. Features like AMX TILE_DATA (XSTATE component 18) +are enabled by XCR0 as well, but the first use of related instruction is +trapped by the kernel because by default the required large XSTATE buffers +are not allocated automatically. + +Using dynamically enabled XSTATE features in user space applications +-------------------------------------------------------------------- + +The kernel provides an arch_prctl(2) based mechanism for applications to +request the usage of such features. The arch_prctl(2) options related to +this are: + +-ARCH_GET_XCOMP_SUPP + + arch_prctl(ARCH_GET_XCOMP_SUPP, &features); + + ARCH_GET_XCOMP_SUPP stores the supported features in userspace storage of + type uint64_t. The second argument is a pointer to that storage. + +-ARCH_GET_XCOMP_PERM + + arch_prctl(ARCH_GET_XCOMP_PERM, &features); + + ARCH_GET_XCOMP_PERM stores the features for which the userspace process + has permission in userspace storage of type uint64_t. The second argument + is a pointer to that storage. + +-ARCH_REQ_XCOMP_PERM + + arch_prctl(ARCH_REQ_XCOMP_PERM, feature_nr); + + ARCH_REQ_XCOMP_PERM allows to request permission for a dynamically enabled + feature or a feature set. A feature set can be mapped to a facility, e.g. + AMX, and can require one or more XSTATE components to be enabled. + + The feature argument is the number of the highest XSTATE component which + is required for a facility to work. + +When requesting permission for a feature, the kernel checks the +availability. The kernel ensures that sigaltstacks in the process's tasks +are large enough to accommodate the resulting large signal frame. It +enforces this both during ARCH_REQ_XCOMP_SUPP and during any subsequent +sigaltstack(2) calls. If an installed sigaltstack is smaller than the +resulting sigframe size, ARCH_REQ_XCOMP_SUPP results in -ENOSUPP. Also, +sigaltstack(2) results in -ENOMEM if the requested altstack is too small +for the permitted features. + +Permission, when granted, is valid per process. Permissions are inherited +on fork(2) and cleared on exec(3). + +The first use of an instruction related to a dynamically enabled feature is +trapped by the kernel. The trap handler checks whether the process has +permission to use the feature. If the process has no permission then the +kernel sends SIGILL to the application. If the process has permission then +the handler allocates a larger xstate buffer for the task so the large +state can be context switched. In the unlikely cases that the allocation +fails, the kernel sends SIGSEGV. |