diff options
Diffstat (limited to 'Documentation')
394 files changed, 13135 insertions, 2393 deletions
diff --git a/Documentation/ABI/removed/sysfs-firmware-efi-vars b/Documentation/ABI/removed/sysfs-firmware-efi-vars new file mode 100644 index 000000000000..8d97368b149b --- /dev/null +++ b/Documentation/ABI/removed/sysfs-firmware-efi-vars @@ -0,0 +1,12 @@ +What: /sys/firmware/efi/vars +Date: April 2004, removed March 2023 +Description: + This directory exposed interfaces for interacting with + EFI variables. For more information on EFI variables, + see 'Variable Services' in the UEFI specification + (section 7.2 in specification version 2.3 Errata D). + + The 'efivars' sysfs interface was removed in March of 2023, + after being considered deprecated no later than September + of 2020. Its functionality has been replaced by the + 'efivarfs' filesystem. diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block index 1fe9a553c37b..831f19a32e08 100644 --- a/Documentation/ABI/stable/sysfs-block +++ b/Documentation/ABI/stable/sysfs-block @@ -101,6 +101,16 @@ Description: devices that support receiving integrity metadata. +What: /sys/block/<disk>/partscan +Date: May 2024 +Contact: Christoph Hellwig <hch@lst.de> +Description: + The /sys/block/<disk>/partscan files reports if partition + scanning is enabled for the disk. It returns "1" if partition + scanning is enabled, or "0" if not. The value type is a 32-bit + unsigned integer, but only "0" and "1" are valid values. + + What: /sys/block/<disk>/<partition>/alignment_offset Date: April 2009 Contact: Martin K. Petersen <martin.petersen@oracle.com> @@ -584,18 +594,6 @@ Description: the data. If no such restriction exists, this file will contain '0'. This file is writable for testing purposes. - -What: /sys/block/<disk>/queue/throttle_sample_time -Date: March 2017 -Contact: linux-block@vger.kernel.org -Description: - [RW] This is the time window that blk-throttle samples data, in - millisecond. blk-throttle makes decision based on the - samplings. Lower time means cgroups have more smooth throughput, - but higher CPU overhead. This exists only when - CONFIG_BLK_DEV_THROTTLING_LOW is enabled. - - What: /sys/block/<disk>/queue/virt_boundary_mask Date: April 2021 Contact: linux-block@vger.kernel.org diff --git a/Documentation/ABI/stable/sysfs-firmware-efi-vars b/Documentation/ABI/stable/sysfs-firmware-efi-vars deleted file mode 100644 index 46ccd233e359..000000000000 --- a/Documentation/ABI/stable/sysfs-firmware-efi-vars +++ /dev/null @@ -1,79 +0,0 @@ -What: /sys/firmware/efi/vars -Date: April 2004 -Contact: Matt Domsch <Matt_Domsch@dell.com> -Description: - This directory exposes interfaces for interactive with - EFI variables. For more information on EFI variables, - see 'Variable Services' in the UEFI specification - (section 7.2 in specification version 2.3 Errata D). - - In summary, EFI variables are named, and are classified - into separate namespaces through the use of a vendor - GUID. They also have an arbitrary binary value - associated with them. - - The efivars module enumerates these variables and - creates a separate directory for each one found. Each - directory has a name of the form "<key>-<vendor guid>" - and contains the following files: - - =============== ======================================== - attributes: A read-only text file enumerating the - EFI variable flags. Potential values - include: - - EFI_VARIABLE_NON_VOLATILE - EFI_VARIABLE_BOOTSERVICE_ACCESS - EFI_VARIABLE_RUNTIME_ACCESS - EFI_VARIABLE_HARDWARE_ERROR_RECORD - EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS - - See the EFI documentation for an - explanation of each of these variables. - - data: A read-only binary file that can be read - to attain the value of the EFI variable - - guid: The vendor GUID of the variable. This - should always match the GUID in the - variable's name. - - raw_var: A binary file that can be read to obtain - a structure that contains everything - there is to know about the variable. - For structure definition see "struct - efi_variable" in the kernel sources. - - This file can also be written to in - order to update the value of a variable. - For this to work however, all fields of - the "struct efi_variable" passed must - match byte for byte with the structure - read out of the file, save for the value - portion. - - **Note** the efi_variable structure - read/written with this file contains a - 'long' type that may change widths - depending on your underlying - architecture. - - size: As ASCII representation of the size of - the variable's value. - =============== ======================================== - - - In addition, two other magic binary files are provided - in the top-level directory and are used for adding and - removing variables: - - =============== ======================================== - new_var: Takes a "struct efi_variable" and - instructs the EFI firmware to create a - new variable. - - del_var: Takes a "struct efi_variable" and - instructs the EFI firmware to remove any - variable that has a matching vendor GUID - and variable key name. - =============== ======================================== diff --git a/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon index 023fd82de3f7..d792a56f59ac 100644 --- a/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon +++ b/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon @@ -10,7 +10,7 @@ Description: RW. Card reactive sustained (PL1) power limit in microwatts. power limit is disabled, writing 0 disables the limit. Writing values > 0 and <= TDP will enable the power limit. - Only supported for particular Intel xe graphics platforms. + Only supported for particular Intel Xe graphics platforms. What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_rated_max Date: September 2023 @@ -18,53 +18,93 @@ KernelVersion: 6.5 Contact: intel-xe@lists.freedesktop.org Description: RO. Card default power limit (default TDP setting). - Only supported for particular Intel xe graphics platforms. + Only supported for particular Intel Xe graphics platforms. -What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_crit + +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/energy1_input Date: September 2023 KernelVersion: 6.5 Contact: intel-xe@lists.freedesktop.org -Description: RW. Card reactive critical (I1) power limit in microwatts. +Description: RO. Card energy input of device in microjoules. + + Only supported for particular Intel Xe graphics platforms. + +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_max_interval +Date: October 2023 +KernelVersion: 6.6 +Contact: intel-xe@lists.freedesktop.org +Description: RW. Card sustained power limit interval (Tau in PL1/Tau) in + milliseconds over which sustained power is averaged. + + Only supported for particular Intel Xe graphics platforms. + +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_max +Date: February 2024 +KernelVersion: 6.8 +Contact: intel-xe@lists.freedesktop.org +Description: RW. Package reactive sustained (PL1) power limit in microwatts. + + The power controller will throttle the operating frequency + if the power averaged over a window (typically seconds) + exceeds this limit. A read value of 0 means that the PL1 + power limit is disabled, writing 0 disables the + limit. Writing values > 0 and <= TDP will enable the power limit. + + Only supported for particular Intel Xe graphics platforms. + +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_rated_max +Date: February 2024 +KernelVersion: 6.8 +Contact: intel-xe@lists.freedesktop.org +Description: RO. Package default power limit (default TDP setting). - Card reactive critical (I1) power limit in microwatts is exposed + Only supported for particular Intel Xe graphics platforms. + +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_crit +Date: February 2024 +KernelVersion: 6.8 +Contact: intel-xe@lists.freedesktop.org +Description: RW. Package reactive critical (I1) power limit in microwatts. + + Package reactive critical (I1) power limit in microwatts is exposed for client products. The power controller will throttle the operating frequency if the power averaged over a window exceeds this limit. - Only supported for particular Intel xe graphics platforms. + Only supported for particular Intel Xe graphics platforms. -What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/curr1_crit -Date: September 2023 -KernelVersion: 6.5 +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/curr2_crit +Date: February 2024 +KernelVersion: 6.8 Contact: intel-xe@lists.freedesktop.org -Description: RW. Card reactive critical (I1) power limit in milliamperes. +Description: RW. Package reactive critical (I1) power limit in milliamperes. - Card reactive critical (I1) power limit in milliamperes is + Package reactive critical (I1) power limit in milliamperes is exposed for server products. The power controller will throttle the operating frequency if the power averaged over a window exceeds this limit. -What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/in0_input -Date: September 2023 -KernelVersion: 6.5 +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/energy2_input +Date: February 2024 +KernelVersion: 6.8 Contact: intel-xe@lists.freedesktop.org -Description: RO. Current Voltage in millivolt. +Description: RO. Package energy input of device in microjoules. - Only supported for particular Intel xe graphics platforms. + Only supported for particular Intel Xe graphics platforms. -What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/energy1_input -Date: September 2023 -KernelVersion: 6.5 +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_max_interval +Date: February 2024 +KernelVersion: 6.8 Contact: intel-xe@lists.freedesktop.org -Description: RO. Energy input of device in microjoules. +Description: RW. Package sustained power limit interval (Tau in PL1/Tau) in + milliseconds over which sustained power is averaged. - Only supported for particular Intel xe graphics platforms. + Only supported for particular Intel Xe graphics platforms. -What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_max_interval -Date: October 2023 -KernelVersion: 6.6 +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/in1_input +Date: February 2024 +KernelVersion: 6.8 Contact: intel-xe@lists.freedesktop.org -Description: RW. Sustained power limit interval (Tau in PL1/Tau) in - milliseconds over which sustained power is averaged. +Description: RO. Package current voltage in millivolt. - Only supported for particular Intel xe graphics platforms. + Only supported for particular Intel Xe graphics platforms. diff --git a/Documentation/ABI/testing/sysfs-driver-panfrost-profiling b/Documentation/ABI/testing/sysfs-driver-panfrost-profiling new file mode 100644 index 000000000000..7597c420e54b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-panfrost-profiling @@ -0,0 +1,10 @@ +What: /sys/bus/platform/drivers/panfrost/.../profiling +Date: February 2024 +KernelVersion: 6.8.0 +Contact: Adrian Larumbe <adrian.larumbe@collabora.com> +Description: + Get/set drm fdinfo's engine and cycles profiling status. + Valid values are: + 0: Don't enable fdinfo job profiling sources. + 1: Enable fdinfo job profiling sources, this enables both the GPU's + timestamp and cycle counter registers. diff --git a/Documentation/Makefile b/Documentation/Makefile index b68f8c816897..a961692baa12 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -28,6 +28,10 @@ BUILDDIR = $(obj)/output PDFLATEX = xelatex LATEXOPTS = -interaction=batchmode -no-shell-escape +# For denylisting "variable font" files +# Can be overridden by setting as an env variable +FONTS_CONF_DENY_VF ?= $(HOME)/deny-vf + ifeq ($(findstring 1, $(KBUILD_VERBOSE)),) SPHINXOPTS += "-q" endif @@ -151,10 +155,11 @@ pdfdocs: else # HAVE_PDFLATEX +pdfdocs: DENY_VF = XDG_CONFIG_HOME=$(FONTS_CONF_DENY_VF) pdfdocs: latexdocs @$(srctree)/scripts/sphinx-pre-install --version-check $(foreach var,$(SPHINXDIRS), \ - $(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit; \ + $(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" $(DENY_VF) -C $(BUILDDIR)/$(var)/latex || sh $(srctree)/scripts/check-variable-fonts.sh || exit; \ mkdir -p $(BUILDDIR)/$(var)/pdf; \ mv $(subst .tex,.pdf,$(wildcard $(BUILDDIR)/$(var)/latex/*.tex)) $(BUILDDIR)/$(var)/pdf/; \ ) diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index 872ac665223f..94838c65c7d9 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -427,7 +427,7 @@ their assorted primitives. This section shows a simple use of the core RCU API to protect a global pointer to a dynamically allocated structure. More-typical -uses of RCU may be found in listRCU.rst, arrayRCU.rst, and NMI-RCU.rst. +uses of RCU may be found in listRCU.rst and NMI-RCU.rst. :: struct foo { @@ -510,8 +510,8 @@ So, to sum up: data item. See checklist.rst for additional rules to follow when using RCU. -And again, more-typical uses of RCU may be found in listRCU.rst, -arrayRCU.rst, and NMI-RCU.rst. +And again, more-typical uses of RCU may be found in listRCU.rst +and NMI-RCU.rst. .. _4_whatisRCU: diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst index 9343148ee993..a3e2edb3d274 100644 --- a/Documentation/admin-guide/cgroup-v1/cgroups.rst +++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst @@ -570,7 +570,7 @@ visible to cgroup_for_each_child/descendant_*() iterators. The subsystem may choose to fail creation by returning -errno. This callback can be used to implement reliable state sharing and propagation along the hierarchy. See the comment on -cgroup_for_each_descendant_pre() for details. +cgroup_for_each_live_descendant_pre() for details. ``void css_offline(struct cgroup *cgrp);`` (cgroup_mutex held by caller) diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst index 1f128458ddea..9f8e27355cba 100644 --- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst +++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst @@ -102,7 +102,7 @@ Under below explanation, we assume CONFIG_SWAP=y. The logic is very clear. (About migration, see below) Note: - __remove_from_page_cache() is called by remove_from_page_cache() + __filemap_remove_folio() is called by filemap_remove_folio() and __remove_mapping(). 6. Shmem(tmpfs) Page Cache diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 17e6e9565156..f554df7ac649 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1058,12 +1058,15 @@ cpufreq governor about the minimum desired frequency which should always be provided by a CPU, as well as the maximum desired frequency, which should not be exceeded by a CPU. -WARNING: cgroup2 doesn't yet support control of realtime processes and -the cpu controller can only be enabled when all RT processes are in -the root cgroup. Be aware that system management software may already -have placed RT processes into nonroot cgroups during the system boot -process, and these processes may need to be moved to the root cgroup -before the cpu controller can be enabled. +WARNING: cgroup2 doesn't yet support control of realtime processes. For +a kernel built with the CONFIG_RT_GROUP_SCHED option enabled for group +scheduling of realtime processes, the cpu controller can only be enabled +when all RT processes are in the root cgroup. This limitation does +not apply if CONFIG_RT_GROUP_SCHED is disabled. Be aware that system +management software may already have placed RT processes into nonroot +cgroups during the system boot process, and these processes may need +to be moved to the root cgroup before the cpu controller can be enabled +with a CONFIG_RT_GROUP_SCHED enabled kernel. CPU Interface Files @@ -1572,6 +1575,15 @@ PAGE_SIZE multiple when read back. pglazyfreed (npn) Amount of reclaimed lazyfree pages + zswpin + Number of pages moved in to memory from zswap. + + zswpout + Number of pages moved out of memory to zswap. + + zswpwb + Number of pages written from zswap to swap. + thp_fault_alloc (npn) Number of transparent hugepages which were allocated to satisfy a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE @@ -2181,11 +2193,25 @@ PID Interface Files Hard limit of number of processes. pids.current - A read-only single value file which exists on all cgroups. + A read-only single value file which exists on non-root cgroups. The number of processes currently in the cgroup and its descendants. + pids.peak + A read-only single value file which exists on non-root cgroups. + + The maximum value that the number of processes in the cgroup and its + descendants has ever reached. + + pids.events + A read-only flat-keyed file which exists on non-root cgroups. The + following entries are defined. Unless specified otherwise, a value + change in this file generates a file modified event. + + max + Number of times fork failed because limit was hit. + Organisational operations are not blocked by cgroup policies, so it is possible to have pids.current > pids.max. This can be done by either setting the limit to be smaller than pids.current, or attaching enough diff --git a/Documentation/admin-guide/device-mapper/dm-crypt.rst b/Documentation/admin-guide/device-mapper/dm-crypt.rst index aa2d04d95df6..41f5f57f00eb 100644 --- a/Documentation/admin-guide/device-mapper/dm-crypt.rst +++ b/Documentation/admin-guide/device-mapper/dm-crypt.rst @@ -113,6 +113,11 @@ same_cpu_crypt The default is to use an unbound workqueue so that encryption work is automatically balanced between available CPUs. +high_priority + Set dm-crypt workqueues and the writer thread to high priority. This + improves throughput and latency of dm-crypt while degrading general + responsiveness of the system. + submit_from_crypt_cpus Disable offloading writes to a separate thread after encryption. There are some situations where offloading write bios from the diff --git a/Documentation/admin-guide/hw-vuln/core-scheduling.rst b/Documentation/admin-guide/hw-vuln/core-scheduling.rst index cf1eeefdfc32..a92e10ec402e 100644 --- a/Documentation/admin-guide/hw-vuln/core-scheduling.rst +++ b/Documentation/admin-guide/hw-vuln/core-scheduling.rst @@ -67,8 +67,8 @@ arg4: will be performed for all tasks in the task group of ``pid``. arg5: - userspace pointer to an unsigned long for storing the cookie returned by - ``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands. + userspace pointer to an unsigned long long for storing the cookie returned + by ``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands. In order for a process to push a cookie to, or pull a cookie from a process, it is required to have the ptrace access mode: `PTRACE_MODE_READ_REALCREDS` to the diff --git a/Documentation/admin-guide/hw-vuln/srso.rst b/Documentation/admin-guide/hw-vuln/srso.rst index e715bfc09879..4bd3ce3ba171 100644 --- a/Documentation/admin-guide/hw-vuln/srso.rst +++ b/Documentation/admin-guide/hw-vuln/srso.rst @@ -135,7 +135,7 @@ and does not want to suffer the performance impact, one can always disable the mitigation with spec_rstack_overflow=off. Similarly, 'Mitigation: IBPB' is another full mitigation type employing -an indrect branch prediction barrier after having applied the required +an indirect branch prediction barrier after having applied the required microcode patch for one's system. This mitigation comes also at a performance cost. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 213d0719e2b7..45d95614ec44 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -431,6 +431,9 @@ arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards Format: <io>,<irq>,<nodeID> + arm64.no32bit_el0 [ARM64] Unconditionally disable the execution of + 32 bit applications. + arm64.nobti [ARM64] Unconditionally disable Branch Target Identification support @@ -2251,6 +2254,8 @@ no_x2apic_optout BIOS x2APIC opt-out request will be ignored nopost disable Interrupt Posting + posted_msi + enable MSIs delivered as posted interrupts iomem= Disable strict checking of access to MMIO memory strict regions from userspace. @@ -4173,13 +4178,11 @@ page_alloc.shuffle= [KNL] Boolean flag to control whether the page allocator - should randomize its free lists. The randomization may - be automatically enabled if the kernel detects it is - running on a platform with a direct-mapped memory-side - cache, and this parameter can be used to - override/disable that behavior. The state of the flag - can be read from sysfs at: + should randomize its free lists. This parameter can be + used to enable/disable page randomization. The state of + the flag can be read from sysfs at: /sys/module/page_alloc/parameters/shuffle. + This parameter is only available if CONFIG_SHUFFLE_PAGE_ALLOCATOR=y. page_owner= [KNL,EARLY] Boot-time page_owner enabling option. Storage of the information about who allocated @@ -4594,9 +4597,10 @@ norid [S390] ignore the RID field and force use of one PCI domain per PCI function - pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power + pcie_aspm= [PCIE] Forcibly enable or ignore PCIe Active State Power Management. - off Disable ASPM. + off Don't touch ASPM configuration at all. Leave any + configuration done by firmware unchanged. force Enable ASPM even on devices that claim not to support it. WARNING: Forcing ASPM on may cause system lockups. @@ -4784,7 +4788,9 @@ prot_virt= [S390] enable hosting protected virtual machines isolated from the hypervisor (if hardware supports - that). + that). If enabled, the default kernel base address + might be overridden even when Kernel Address Space + Layout Randomization is disabled. Format: <bool> psi= [KNL] Enable or disable pressure stall information @@ -5095,6 +5101,20 @@ delay, memory pressure or callback list growing too big. + rcutree.rcu_normal_wake_from_gp= [KNL] + Reduces a latency of synchronize_rcu() call. This approach + maintains its own track of synchronize_rcu() callers, so it + does not interact with regular callbacks because it does not + use a call_rcu[_hurry]() path. Please note, this is for a + normal grace period. + + How to enable it: + + echo 1 > /sys/module/rcutree/parameters/rcu_normal_wake_from_gp + or pass a boot parameter "rcutree.rcu_normal_wake_from_gp=1" + + Default is 0. + rcuscale.gp_async= [KNL] Measure performance of asynchronous grace-period primitives such as call_rcu(). @@ -5811,6 +5831,7 @@ but is useful for debugging and performance tuning. sched_thermal_decay_shift= + [Deprecated] [KNL, SMP] Set a decay shift for scheduler thermal pressure signal. Thermal pressure signal follows the default decay period of other scheduler pelt @@ -6748,6 +6769,7 @@ - "tpm" - "tee" - "caam" + - "dcp" If not specified then it defaults to iterating through the trust source list starting with TPM and assigns the first trust source as a backend which is initialized @@ -6763,6 +6785,18 @@ If not specified, "default" is used. In this case, the RNG's choice is left to each individual trust source. + trusted.dcp_use_otp_key + This is intended to be used in combination with + trusted.source=dcp and will select the DCP OTP key + instead of the DCP UNIQUE key blob encryption. + + trusted.dcp_skip_zk_test + This is intended to be used in combination with + trusted.source=dcp and will disable the check if the + blob key is all zeros. This is helpful for situations where + having this key zero'ed is acceptable. E.g. in testing + scenarios. + tsc= Disable clocksource stability checks for TSC. Format: <string> [x86] reliable: mark tsc clocksource as reliable, this @@ -7323,7 +7357,7 @@ This can be changed after boot by writing to the matching /sys/module/workqueue/parameters file. All workqueues with the "default" affinity scope will be - updated accordignly. + updated accordingly. workqueue.debug_force_rr_cpu Workqueue used to implicitly guarantee that work diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst index a639cac12477..ad8e7a41f3b5 100644 --- a/Documentation/admin-guide/mm/ksm.rst +++ b/Documentation/admin-guide/mm/ksm.rst @@ -308,7 +308,7 @@ limited by the ``advisor_max_cpu`` parameter. In addition there is also the ``advisor_target_scan_time`` parameter. This parameter sets the target time to scan all the KSM candidate pages. The parameter ``advisor_target_scan_time`` decides how aggressive the scan time advisor scans candidate pages. Lower -values make the scan time advisor to scan more aggresively. This is the most +values make the scan time advisor to scan more aggressively. This is the most important parameter for the configuration of the scan time advisor. The initial value and the maximum value can be changed with diff --git a/Documentation/admin-guide/perf/hisi-pmu.rst b/Documentation/admin-guide/perf/hisi-pmu.rst index e0174d20809a..5cc248d18c63 100644 --- a/Documentation/admin-guide/perf/hisi-pmu.rst +++ b/Documentation/admin-guide/perf/hisi-pmu.rst @@ -20,7 +20,6 @@ interrupt, and the PMU driver shall register perf PMU drivers like L3C, HHA and DDRC etc. The available events and configuration options shall be described in the sysfs, see: -/sys/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>/, or /sys/bus/event_source/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>. The "perf list" command shall list the available events from sysfs. diff --git a/Documentation/admin-guide/perf/hns3-pmu.rst b/Documentation/admin-guide/perf/hns3-pmu.rst index 75a40846d47f..1195e570f2d6 100644 --- a/Documentation/admin-guide/perf/hns3-pmu.rst +++ b/Documentation/admin-guide/perf/hns3-pmu.rst @@ -16,7 +16,7 @@ HNS3 PMU driver The HNS3 PMU driver registers a perf PMU with the name of its sicl id.:: - /sys/devices/hns3_pmu_sicl_<sicl_id> + /sys/bus/event_source/devices/hns3_pmu_sicl_<sicl_id> PMU driver provides description of available events, filter modes, format, identifier and cpumask in sysfs. @@ -40,9 +40,9 @@ device. Example usage of checking event code and subevent code:: - $# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time + $# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time config=0x00204 - $# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num + $# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num config=0x10204 Each performance statistic has a pair of events to get two values to @@ -60,7 +60,7 @@ computation to calculate real performance data is::: Example usage of checking supported filter mode:: - $# cat /sys/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num + $# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num filter mode supported: global/port/port-tc/func/func-queue/ Example usage of perf:: diff --git a/Documentation/admin-guide/perf/qcom_l2_pmu.rst b/Documentation/admin-guide/perf/qcom_l2_pmu.rst index c130178a4a55..c37c6be9b8d8 100644 --- a/Documentation/admin-guide/perf/qcom_l2_pmu.rst +++ b/Documentation/admin-guide/perf/qcom_l2_pmu.rst @@ -10,7 +10,7 @@ There is one logical L2 PMU exposed, which aggregates the results from the physical PMUs. The driver provides a description of its available events and configuration -options in sysfs, see /sys/devices/l2cache_0. +options in sysfs, see /sys/bus/event_source/devices/l2cache_0. The "format" directory describes the format of the events. diff --git a/Documentation/admin-guide/perf/qcom_l3_pmu.rst b/Documentation/admin-guide/perf/qcom_l3_pmu.rst index a3d014a46bfd..a66556b7e985 100644 --- a/Documentation/admin-guide/perf/qcom_l3_pmu.rst +++ b/Documentation/admin-guide/perf/qcom_l3_pmu.rst @@ -9,7 +9,7 @@ PMU with device name l3cache_<socket>_<instance>. User space is responsible for aggregating across slices. The driver provides a description of its available events and configuration -options in sysfs, see /sys/devices/l3cache*. Given that these are uncore PMUs +options in sysfs, see /sys/bus/event_source/devices/l3cache*. Given that these are uncore PMUs the driver also exposes a "cpumask" sysfs attribute which contains a mask consisting of one CPU per socket which will be used to handle all the PMU events on that socket. diff --git a/Documentation/admin-guide/perf/thunderx2-pmu.rst b/Documentation/admin-guide/perf/thunderx2-pmu.rst index 01f158238ae1..9255f7bf9452 100644 --- a/Documentation/admin-guide/perf/thunderx2-pmu.rst +++ b/Documentation/admin-guide/perf/thunderx2-pmu.rst @@ -22,7 +22,7 @@ The thunderx2_pmu driver registers per-socket perf PMUs for the DMC and L3C devices. Each PMU can be used to count up to 4 (DMC/L3C) or up to 8 (CCPI2) events simultaneously. The PMUs provide a description of their available events and configuration options under sysfs, see -/sys/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id. +/sys/bus/event_source/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id. The driver does not support sampling, therefore "perf record" will not work. Per-task perf sessions are also not supported. diff --git a/Documentation/admin-guide/perf/xgene-pmu.rst b/Documentation/admin-guide/perf/xgene-pmu.rst index 644f8ed89152..98ccb8e777c4 100644 --- a/Documentation/admin-guide/perf/xgene-pmu.rst +++ b/Documentation/admin-guide/perf/xgene-pmu.rst @@ -13,7 +13,7 @@ PMU (perf) driver The xgene-pmu driver registers several perf PMU drivers. Each of the perf driver provides description of its available events and configuration options -in sysfs, see /sys/devices/<l3cX/iobX/mcbX/mcX>/. +in sysfs, see /sys/bus/event_source/devices/<l3cX/iobX/mcbX/mcX>/. The "format" directory describes format of the config (event ID), config1 (agent ID) fields of the perf_event_attr structure. The "events" diff --git a/Documentation/admin-guide/reporting-regressions.rst b/Documentation/admin-guide/reporting-regressions.rst index 76b246ecf21b..946518355a2c 100644 --- a/Documentation/admin-guide/reporting-regressions.rst +++ b/Documentation/admin-guide/reporting-regressions.rst @@ -42,12 +42,12 @@ The important basics -------------------- -What is a "regression" and what is the "no regressions rule"? +What is a "regression" and what is the "no regressions" rule? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's a regression if some application or practical use case running fine with one Linux kernel works worse or not at all with a newer version compiled using a -similar configuration. The "no regressions rule" forbids this to take place; if +similar configuration. The "no regressions" rule forbids this to take place; if it happens by accident, developers that caused it are expected to quickly fix the issue. @@ -173,7 +173,7 @@ Additional details about regressions ------------------------------------ -What is the goal of the "no regressions rule"? +What is the goal of the "no regressions" rule? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Users should feel safe when updating kernel versions and not have to worry @@ -199,8 +199,8 @@ Exceptions to this rule are extremely rare; in the past developers almost always turned out to be wrong when they assumed a particular situation was warranting an exception. -Who ensures the "no regressions" is actually followed? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Who ensures the "no regressions" rule is actually followed? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The subsystem maintainers should take care of that, which are watched and supported by the tree maintainers -- e.g. Linus Torvalds for mainline and diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst index 7250c0542828..7b0c4291c686 100644 --- a/Documentation/admin-guide/sysctl/net.rst +++ b/Documentation/admin-guide/sysctl/net.rst @@ -72,6 +72,7 @@ two flavors of JITs, the newer eBPF JIT currently supported on: - riscv64 - riscv32 - loongarch64 + - arc And the older cBPF JIT supported on the following archs: diff --git a/Documentation/arch/m68k/buddha-driver.rst b/Documentation/arch/m68k/buddha-driver.rst index 20e401413991..5d1bc824978b 100644 --- a/Documentation/arch/m68k/buddha-driver.rst +++ b/Documentation/arch/m68k/buddha-driver.rst @@ -173,7 +173,7 @@ When accessing IDE registers with A6=1 (for example $84x), the timing will always be mode 0 8-bit compatible, no matter what you have selected in the speed register: -781ns select, IOR/IOW after 4 clock cycles (=314ns) aktive. +781ns select, IOR/IOW after 4 clock cycles (=314ns) active. All the timings with a very short select-signal (the 355ns fast accesses) depend on the accelerator card used in the diff --git a/Documentation/arch/s390/index.rst b/Documentation/arch/s390/index.rst index 73c79bf586fd..e75a6e5d2505 100644 --- a/Documentation/arch/s390/index.rst +++ b/Documentation/arch/s390/index.rst @@ -8,6 +8,7 @@ s390 Architecture cds 3270 driver-model + mm monreader qeth s390dbf diff --git a/Documentation/arch/s390/mm.rst b/Documentation/arch/s390/mm.rst new file mode 100644 index 000000000000..084adad5eef9 --- /dev/null +++ b/Documentation/arch/s390/mm.rst @@ -0,0 +1,111 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +Memory Management +================= + +Virtual memory layout +===================== + +.. note:: + + - Some aspects of the virtual memory layout setup are not + clarified (number of page levels, alignment, DMA memory). + + - Unused gaps in the virtual memory layout could be present + or not - depending on how partucular system is configured. + No page tables are created for the unused gaps. + + - The virtual memory regions are tracked or untracked by KASAN + instrumentation, as well as the KASAN shadow memory itself is + created only when CONFIG_KASAN configuration option is enabled. + +:: + + ============================================================================= + | Physical | Virtual | VM area description + ============================================================================= + +- 0 --------------+- 0 --------------+ + | | S390_lowcore | Low-address memory + | +- 8 KB -----------+ + | | | + | | | + | | ... unused gap | KASAN untracked + | | | + +- AMODE31_START --+- AMODE31_START --+ .amode31 rand. phys/virt start + |.amode31 text/data|.amode31 text/data| KASAN untracked + +- AMODE31_END ----+- AMODE31_END ----+ .amode31 rand. phys/virt end (<2GB) + | | | + | | | + +- __kaslr_offset_phys | kernel rand. phys start + | | | + | kernel text/data | | + | | | + +------------------+ | kernel phys end + | | | + | | | + | | | + | | | + +- ident_map_size -+ | + | | + | ... unused gap | KASAN untracked + | | + +- __identity_base + identity mapping start (>= 2GB) + | | + | identity | phys == virt - __identity_base + | mapping | virt == phys + __identity_base + | | + | | KASAN tracked + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + +---- vmemmap -----+ 'struct page' array start + | | + | virtually mapped | + | memory map | KASAN untracked + | | + +- __abs_lowcore --+ + | | + | Absolute Lowcore | KASAN untracked + | | + +- __memcpy_real_area + | | + | Real Memory Copy| KASAN untracked + | | + +- VMALLOC_START --+ vmalloc area start + | | KASAN untracked or + | vmalloc area | KASAN shallowly populated in case + | | CONFIG_KASAN_VMALLOC=y + +- MODULES_VADDR --+ modules area start + | | KASAN allocated per module or + | modules area | KASAN shallowly populated in case + | | CONFIG_KASAN_VMALLOC=y + +- __kaslr_offset -+ kernel rand. virt start + | | KASAN tracked + | kernel text/data | phys == (kvirt - __kaslr_offset) + + | | __kaslr_offset_phys + +- kernel .bss end + kernel rand. virt end + | | + | ... unused gap | KASAN untracked + | | + +------------------+ UltraVisor Secure Storage limit + | | + | ... unused gap | KASAN untracked + | | + +KASAN_SHADOW_START+ KASAN shadow memory start + | | + | KASAN shadow | KASAN untracked + | | + +------------------+ ASCE limit diff --git a/Documentation/arch/s390/vfio-ap.rst b/Documentation/arch/s390/vfio-ap.rst index 929ee1c1c940..ea744cbc8687 100644 --- a/Documentation/arch/s390/vfio-ap.rst +++ b/Documentation/arch/s390/vfio-ap.rst @@ -380,6 +380,36 @@ matrix device. control_domains: A read-only file for displaying the control domain numbers assigned to the vfio_ap mediated device. + ap_config: + A read/write file that, when written to, allows all three of the + vfio_ap mediated device's ap matrix masks to be replaced in one shot. + Three masks are given, one for adapters, one for domains, and one for + control domains. If the given state cannot be set then no changes are + made to the vfio-ap mediated device. + + The format of the data written to ap_config is as follows: + {amask},{dmask},{cmask}\n + + \n is a newline character. + + amask, dmask, and cmask are masks identifying which adapters, domains, + and control domains should be assigned to the mediated device. + + The format of a mask is as follows: + 0xNN..NN + + Where NN..NN is 64 hexadecimal characters representing a 256-bit value. + The leftmost (highest order) bit represents adapter/domain 0. + + For an example set of masks that represent your mdev's current + configuration, simply cat ap_config. + + Setting an adapter or domain number greater than the maximum allowed for + the system will result in an error. + + This attribute is intended to be used by automation. End users would be + better served using the respective assign/unassign attributes for + adapters, domains, and control domains. * functions: @@ -550,7 +580,7 @@ These are the steps: following Kconfig elements selected: * IOMMU_SUPPORT * S390 - * ZCRYPT + * AP * VFIO * KVM diff --git a/Documentation/arch/sparc/oradax/dax-hv-api.txt b/Documentation/arch/sparc/oradax/dax-hv-api.txt index 7ecd0bf4957b..ef1a4c2bf08b 100644 --- a/Documentation/arch/sparc/oradax/dax-hv-api.txt +++ b/Documentation/arch/sparc/oradax/dax-hv-api.txt @@ -41,7 +41,7 @@ Chapter 36. Coprocessor services submissions until they succeed; waiting for an outstanding CCB to complete is not necessary, and would not be a guarantee that a future submission would succeed. - The availablility of DAX coprocessor command service is indicated by the presence of the DAX virtual + The availability of DAX coprocessor command service is indicated by the presence of the DAX virtual device node in the guest MD (Section 8.24.17, “Database Analytics Accelerators (DAX) virtual-device node”). diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst index 6c245582d8fb..627e23869bca 100644 --- a/Documentation/arch/x86/resctrl.rst +++ b/Documentation/arch/x86/resctrl.rst @@ -446,6 +446,12 @@ during mkdir. max_threshold_occupancy is a user configurable value to determine the occupancy at which an RMID can be freed. +The mon_llc_occupancy_limbo tracepoint gives the precise occupancy in bytes +for a subset of RMID that are not immediately available for allocation. +This can't be relied on to produce output every second, it may be necessary +to attempt to create an empty monitor group to force an update. Output may +only be produced if creation of a control or monitor group fails. + Schemata files - general concepts --------------------------------- Each line in the file describes one resource. The line starts with diff --git a/Documentation/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst index ae5c69e48b11..cec05ac464c1 100644 --- a/Documentation/arch/x86/xstate.rst +++ b/Documentation/arch/x86/xstate.rst @@ -138,7 +138,7 @@ Note this example does not include the sigaltstack preparation. Dynamic features in signal frames --------------------------------- -Dynamcally enabled features are not written to the signal frame upon signal +Dynamically enabled features are not written to the signal frame upon signal entry if the feature is in its initial configuration. This differs from non-dynamic features which are always written regardless of their configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt index d7adc6d543db..bee3b1bca9a7 100644 --- a/Documentation/atomic_t.txt +++ b/Documentation/atomic_t.txt @@ -171,14 +171,14 @@ The rule of thumb: - RMW operations that are conditional are unordered on FAILURE, otherwise the above rules apply. -Except of course when an operation has an explicit ordering like: +Except of course when a successful operation has an explicit ordering like: {}_relaxed: unordered {}_acquire: the R of the RMW (or atomic_read) is an ACQUIRE {}_release: the W of the RMW (or atomic_set) is a RELEASE Where 'unordered' is against other memory locations. Address dependencies are -not defeated. +not defeated. Conditional operations are still unordered on FAILURE. Fully ordered primitives are ordered against everything prior and everything subsequent. Therefore a fully ordered primitive is like having an smp_mb() diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index a5ab00ac0b14..997560abadab 100644 --- a/Documentation/bpf/standardization/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -5,7 +5,11 @@ BPF Instruction Set Architecture (ISA) ====================================== -This document specifies the BPF instruction set architecture (ISA). +eBPF (which is no longer an acronym for anything), also commonly +referred to as BPF, is a technology with origins in the Linux kernel +that can run untrusted programs in a privileged context such as an +operating system kernel. This document specifies the BPF instruction +set architecture (ISA). Documentation conventions ========================= @@ -43,7 +47,7 @@ a type's signedness (`S`) and bit width (`N`), respectively. ===== ========= For example, `u32` is a type whose valid values are all the 32-bit unsigned -numbers and `s16` is a types whose valid values are all the 16-bit signed +numbers and `s16` is a type whose valid values are all the 16-bit signed numbers. Functions @@ -108,7 +112,7 @@ conformance group means it must support all instructions in that conformance group. The use of named conformance groups enables interoperability between a runtime -that executes instructions, and tools as such compilers that generate +that executes instructions, and tools such as compilers that generate instructions for the runtime. Thus, capability discovery in terms of conformance groups might be done manually by users or automatically by tools. @@ -181,10 +185,13 @@ A basic instruction is encoded as follows:: (`64-bit immediate instructions`_ reuse this field for other purposes) **dst_reg** - destination register number (0-10) + destination register number (0-10), unless otherwise specified + (future instructions might reuse this field for other purposes) **offset** - signed integer offset used with pointer arithmetic + signed integer offset used with pointer arithmetic, except where + otherwise specified (some arithmetic instructions reuse this field + for other purposes) **imm** signed integer immediate value @@ -228,10 +235,12 @@ This is depicted in the following figure:: operation to perform, encoded as explained above **regs** - The source and destination register numbers, encoded as explained above + The source and destination register numbers (unless otherwise + specified), encoded as explained above **offset** - signed integer offset used with pointer arithmetic + signed integer offset used with pointer arithmetic, unless + otherwise specified **imm** signed integer immediate value @@ -342,8 +351,8 @@ where '(u32)' indicates that the upper 32 bits are zeroed. dst = dst ^ imm -Note that most instructions have instruction offset of 0. Only three instructions -(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero offset. +Note that most arithmetic instructions have 'offset' set to 0. Only three instructions +(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero 'offset'. Division, multiplication, and modulo operations for ``ALU`` are part of the "divmul32" conformance group, and division, multiplication, and @@ -365,15 +374,15 @@ Note that there are varying definitions of the signed modulo operation when the dividend or divisor are negative, where implementations often vary by language such that Python, Ruby, etc. differ from C, Go, Java, etc. This specification requires that signed modulo use truncated division -(where -13 % 3 == -1) as implemented in C, Go, etc.: +(where -13 % 3 == -1) as implemented in C, Go, etc.:: a % n = a - n * trunc(a / n) The ``MOVSX`` instruction does a move operation with sign extension. -``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into 32 -bit operands, and zeroes the remaining upper 32 bits. +``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into +32-bit operands, and zeroes the remaining upper 32 bits. ``{MOVSX, X, ALU64}`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit -operands into 64 bit operands. Unlike other arithmetic instructions, +operands into 64-bit operands. Unlike other arithmetic instructions, ``MOVSX`` is only defined for register source operands (``X``). The ``NEG`` instruction is only defined when the source bit is clear @@ -411,19 +420,19 @@ conformance group. Examples: -``{END, TO_LE, ALU}`` with imm = 16/32/64 means:: +``{END, TO_LE, ALU}`` with 'imm' = 16/32/64 means:: dst = htole16(dst) dst = htole32(dst) dst = htole64(dst) -``{END, TO_BE, ALU}`` with imm = 16/32/64 means:: +``{END, TO_BE, ALU}`` with 'imm' = 16/32/64 means:: dst = htobe16(dst) dst = htobe32(dst) dst = htobe64(dst) -``{END, TO_LE, ALU64}`` with imm = 16/32/64 means:: +``{END, TO_LE, ALU64}`` with 'imm' = 16/32/64 means:: dst = bswap16(dst) dst = bswap32(dst) @@ -438,27 +447,33 @@ otherwise identical operations, and indicates the base64 conformance group unless otherwise specified. The 'code' field encodes the operation as below: -======== ===== ======= =============================== =================================================== -code value src_reg description notes -======== ===== ======= =============================== =================================================== -JA 0x0 0x0 PC += offset {JA, K, JMP} only -JA 0x0 0x0 PC += imm {JA, K, JMP32} only +======== ===== ======= ================================= =================================================== +code value src_reg description notes +======== ===== ======= ================================= =================================================== +JA 0x0 0x0 PC += offset {JA, K, JMP} only +JA 0x0 0x0 PC += imm {JA, K, JMP32} only JEQ 0x1 any PC += offset if dst == src -JGT 0x2 any PC += offset if dst > src unsigned -JGE 0x3 any PC += offset if dst >= src unsigned +JGT 0x2 any PC += offset if dst > src unsigned +JGE 0x3 any PC += offset if dst >= src unsigned JSET 0x4 any PC += offset if dst & src JNE 0x5 any PC += offset if dst != src -JSGT 0x6 any PC += offset if dst > src signed -JSGE 0x7 any PC += offset if dst >= src signed -CALL 0x8 0x0 call helper function by address {CALL, K, JMP} only, see `Helper functions`_ -CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_ -CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_ -EXIT 0x9 0x0 return {CALL, K, JMP} only -JLT 0xa any PC += offset if dst < src unsigned -JLE 0xb any PC += offset if dst <= src unsigned -JSLT 0xc any PC += offset if dst < src signed -JSLE 0xd any PC += offset if dst <= src signed -======== ===== ======= =============================== =================================================== +JSGT 0x6 any PC += offset if dst > src signed +JSGE 0x7 any PC += offset if dst >= src signed +CALL 0x8 0x0 call helper function by static ID {CALL, K, JMP} only, see `Helper functions`_ +CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_ +CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_ +EXIT 0x9 0x0 return {CALL, K, JMP} only +JLT 0xa any PC += offset if dst < src unsigned +JLE 0xb any PC += offset if dst <= src unsigned +JSLT 0xc any PC += offset if dst < src signed +JSLE 0xd any PC += offset if dst <= src signed +======== ===== ======= ================================= =================================================== + +where 'PC' denotes the program counter, and the offset to increment by +is in units of 64-bit instructions relative to the instruction following +the jump instruction. Thus 'PC += 1' skips execution of the next +instruction if it's a basic instruction or results in undefined behavior +if the next instruction is a 128-bit wide instruction. The BPF program needs to store the return value into register R0 before doing an ``EXIT``. @@ -475,7 +490,7 @@ where 's>=' indicates a signed '>=' comparison. gotol +imm -where 'imm' means the branch offset comes from insn 'imm' field. +where 'imm' means the branch offset comes from the 'imm' field. Note that there are two flavors of ``JA`` instructions. The ``JMP`` class permits a 16-bit jump offset specified by the 'offset' @@ -493,26 +508,26 @@ Helper functions Helper functions are a concept whereby BPF programs can call into a set of function calls exposed by the underlying platform. -Historically, each helper function was identified by an address -encoded in the imm field. The available helper functions may differ -for each program type, but address values are unique across all program types. +Historically, each helper function was identified by a static ID +encoded in the 'imm' field. The available helper functions may differ +for each program type, but static IDs are unique across all program types. Platforms that support the BPF Type Format (BTF) support identifying -a helper function by a BTF ID encoded in the imm field, where the BTF ID +a helper function by a BTF ID encoded in the 'imm' field, where the BTF ID identifies the helper name and type. Program-local functions ~~~~~~~~~~~~~~~~~~~~~~~ Program-local functions are functions exposed by the same BPF program as the caller, and are referenced by offset from the call instruction, similar to -``JA``. The offset is encoded in the imm field of the call instruction. -A ``EXIT`` within the program-local function will return to the caller. +``JA``. The offset is encoded in the 'imm' field of the call instruction. +An ``EXIT`` within the program-local function will return to the caller. Load and store instructions =========================== For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the -8-bit 'opcode' field is divided as:: +8-bit 'opcode' field is divided as follows:: +-+-+-+-+-+-+-+-+ |mode |sz |class| @@ -580,7 +595,7 @@ instructions that transfer data between a register and memory. dst = *(signed size *) (src + offset) -Where size is one of: ``B``, ``H``, or ``W``, and +Where '<size>' is one of: ``B``, ``H``, or ``W``, and 'signed size' is one of: s8, s16, or s32. Atomic operations @@ -662,11 +677,11 @@ src_reg pseudocode imm type dst type ======= ========================================= =========== ============== 0x0 dst = (next_imm << 32) | imm integer integer 0x1 dst = map_by_fd(imm) map fd map -0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer -0x3 dst = var_addr(imm) variable id data pointer -0x4 dst = code_addr(imm) integer code pointer +0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data address +0x3 dst = var_addr(imm) variable id data address +0x4 dst = code_addr(imm) integer code address 0x5 dst = map_by_idx(imm) map index map -0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer +0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data address ======= ========================================= =========== ============== where diff --git a/Documentation/conf.py b/Documentation/conf.py index d148f3e8dd57..0c2205d536b3 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -75,6 +75,8 @@ if major >= 3: "__rcu", "__user", "__force", + "__counted_by_le", + "__counted_by_be", # include/linux/compiler_attributes.h: "__alias", diff --git a/Documentation/core-api/dma-api-howto.rst b/Documentation/core-api/dma-api-howto.rst index e8a55f9d61db..0bf31b6c4383 100644 --- a/Documentation/core-api/dma-api-howto.rst +++ b/Documentation/core-api/dma-api-howto.rst @@ -203,13 +203,33 @@ setting the DMA mask fails. In this manner, if a user of your driver reports that performance is bad or that the device is not even detected, you can ask them for the kernel messages to find out exactly why. -The standard 64-bit addressing device would do something like this:: +The 24-bit addressing device would do something like this:: - if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) { + if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(24))) { dev_warn(dev, "mydev: No suitable DMA available\n"); goto ignore_this_device; } +The standard 64-bit addressing device would do something like this:: + + dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)) + +dma_set_mask_and_coherent() never return fail when DMA_BIT_MASK(64). Typical +error code like:: + + /* Wrong code */ + if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) + dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32)) + +dma_set_mask_and_coherent() will never return failure when bigger than 32. +So typical code like:: + + /* Recommended code */ + if (support_64bit) + dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)); + else + dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32)); + If the device only supports 32-bit addressing for descriptors in the coherent allocations, but supports full 64-bits for streaming mappings it would look like this:: diff --git a/Documentation/core-api/entry.rst b/Documentation/core-api/entry.rst index e12f22ab33c7..a15f9b1767a2 100644 --- a/Documentation/core-api/entry.rst +++ b/Documentation/core-api/entry.rst @@ -18,7 +18,7 @@ exceptions`_, `NMI and NMI-like exceptions`_. Non-instrumentable code - noinstr --------------------------------- -Most instrumentation facilities depend on RCU, so intrumentation is prohibited +Most instrumentation facilities depend on RCU, so instrumentation is prohibited for entry code before RCU starts watching and exit code after RCU stops watching. In addition, many architectures must save and restore register state, which means that (for example) a breakpoint in the breakpoint entry code would diff --git a/Documentation/core-api/printk-index.rst b/Documentation/core-api/printk-index.rst index 3062f37d119b..1979c5dd32fe 100644 --- a/Documentation/core-api/printk-index.rst +++ b/Documentation/core-api/printk-index.rst @@ -4,7 +4,7 @@ Printk Index ============ -There are many ways how to monitor the state of the system. One important +There are many ways to monitor the state of the system. One important source of information is the system log. It provides a lot of information, including more or less important warnings and error messages. @@ -101,7 +101,7 @@ their own wrappers adding __printk_index_emit(). Only few subsystem specific wrappers have been updated so far, for example, dev_printk(). As a result, the printk formats from -some subsystes can be missing in the printk index. +some subsystems can be missing in the printk index. Subsystem specific prefix diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst index ed73c612174d..bcc370c876be 100644 --- a/Documentation/core-api/workqueue.rst +++ b/Documentation/core-api/workqueue.rst @@ -671,7 +671,7 @@ configuration, worker pools and how workqueues map to the pools: :: events_unbound unbound 9 9 10 10 8 events_freezable percpu 0 2 4 6 events_power_efficient percpu 0 2 4 6 - events_freezable_power_ percpu 0 2 4 6 + events_freezable_pwr_ef percpu 0 2 4 6 rcu_gp percpu 0 2 4 6 rcu_par_gp percpu 0 2 4 6 slub_flushwq percpu 0 2 4 6 @@ -694,7 +694,7 @@ Use tools/workqueue/wq_monitor.py to monitor workqueue operations: :: events_unbound 38306 0 0.1 - 7 - - events_freezable 0 0 0.0 0 0 - - events_power_efficient 29598 0 0.2 0 0 - - - events_freezable_power_ 10 0 0.0 0 0 - - + events_freezable_pwr_ef 10 0 0.0 0 0 - - sock_diag_events 0 0 0.0 0 0 - - total infl CPUtime CPUhog CMW/RPR mayday rescued @@ -704,7 +704,7 @@ Use tools/workqueue/wq_monitor.py to monitor workqueue operations: :: events_unbound 38322 0 0.1 - 7 - - events_freezable 0 0 0.0 0 0 - - events_power_efficient 29603 0 0.2 0 0 - - - events_freezable_power_ 10 0 0.0 0 0 - - + events_freezable_pwr_ef 10 0 0.0 0 0 - - sock_diag_events 0 0 0.0 0 0 - - ... diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index 94b6802ab0ab..02143f060b22 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -91,6 +91,16 @@ the below options are available: behaviour when encountering a data race is deemed safe. Please see `"Marking Shared-Memory Accesses" in the LKMM`_ for more information. +* Similar to ``data_race(...)``, the type qualifier ``__data_racy`` can be used + to document that all data races due to accesses to a variable are intended + and should be ignored by KCSAN:: + + struct foo { + ... + int __data_racy stats_counter; + ... + }; + * Disabling data race detection for entire functions can be accomplished by using the function attribute ``__no_kcsan``:: diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst index ff10dc6eef5d..dcf634e411bd 100644 --- a/Documentation/dev-tools/kselftest.rst +++ b/Documentation/dev-tools/kselftest.rst @@ -183,7 +183,7 @@ expected time it takes to run a test. If you have control over the systems which will run the tests you can configure a test runner on those systems to use a greater or lower timeout on the command line as with the `-o` or the `--override-timeout` argument. For example to use 165 seconds instead -one would use: +one would use:: $ ./run_kselftest.sh --override-timeout 165 diff --git a/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml b/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml new file mode 100644 index 000000000000..99e2865f0e46 --- /dev/null +++ b/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/access-controllers/access-controllers.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic Domain Access Controllers + +maintainers: + - Oleksii Moisieiev <oleksii_moisieiev@epam.com> + +description: |+ + Common access controllers properties + + Access controllers are in charge of stating which of the hardware blocks under + their responsibility (their domain) can be accesssed by which compartment. A + compartment can be a cluster of CPUs (or coprocessors), a range of addresses + or a group of hardware blocks. An access controller's domain is the set of + resources covered by the access controller. + + This device tree binding can be used to bind devices to their access + controller provided by access-controllers property. In this case, the device + is a consumer and the access controller is the provider. + + An access controller can be represented by any node in the device tree and + can provide one or more configuration parameters, needed to control parameters + of the consumer device. A consumer node can refer to the provider by phandle + and a set of phandle arguments, specified by '#access-controller-cells' + property in the access controller node. + + Access controllers are typically used to set/read the permissions of a + hardware block and grant access to it. Any of which depends on the access + controller. The capabilities of each access controller are defined by the + binding of the access controller device. + + Each node can be a consumer for the several access controllers. + +# always select the core schema +select: true + +properties: + "#access-controller-cells": + description: + Number of cells in an access-controllers specifier; + Can be any value as specified by device tree binding documentation + of a particular provider. The node is an access controller. + + access-controller-names: + $ref: /schemas/types.yaml#/definitions/string-array + description: + A list of access-controllers names, sorted in the same order as + access-controllers entries. Consumer drivers will use + access-controller-names to match with existing access-controllers entries. + + access-controllers: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + A list of access controller specifiers, as defined by the + bindings of the access-controllers provider. + +additionalProperties: true + +examples: + - | + clock_controller: access-controllers@50000 { + reg = <0x50000 0x400>; + #access-controller-cells = <2>; + }; + + bus_controller: bus@60000 { + reg = <0x60000 0x10000>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + #access-controller-cells = <3>; + + uart4: serial@60100 { + reg = <0x60100 0x400>; + clocks = <&clk_serial>; + access-controllers = <&clock_controller 1 2>, + <&bus_controller 1 3 5>; + access-controller-names = "clock", "bus"; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml index 4cc4e6754681..d925e7a3b5ef 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml @@ -53,6 +53,7 @@ properties: - description: BCM4709 based boards items: - enum: + - asus,rt-ac3200 - asus,rt-ac87u - buffalo,wxr-1900dhp - linksys,ea9200 @@ -67,6 +68,7 @@ properties: items: - enum: - asus,rt-ac3100 + - asus,rt-ac5300 - asus,rt-ac88u - dlink,dir-885l - dlink,dir-890l diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml index 39e3c248f5b7..1f84407a73e4 100644 --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml @@ -46,6 +46,30 @@ properties: - compatible - "#clock-cells" + gpio: + type: object + additionalProperties: false + + properties: + compatible: + const: raspberrypi,firmware-gpio + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: + The first cell is the pin number, and the second cell is used to + specify the gpio polarity (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW). + + gpio-line-names: + minItems: 8 + + required: + - compatible + - gpio-controller + - "#gpio-cells" + reset: type: object additionalProperties: false @@ -96,6 +120,12 @@ examples: #clock-cells = <1>; }; + expgpio: gpio { + compatible = "raspberrypi,firmware-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; + reset: reset { compatible = "raspberrypi,firmware-reset"; #reset-cells = <1>; diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 0027201e19f8..6d185d09cb6a 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -813,6 +813,14 @@ properties: - const: tq,imx6ull-tqma6ull2l # MCIMX6Y2, LGA SoM variant - const: fsl,imx6ull + - description: Seeed Stuido i.MX6ULL SoM on dev boards + items: + - enum: + - seeed,imx6ull-seeed-npi-emmc + - seeed,imx6ull-seeed-npi-nand + - const: seeed,imx6ull-seeed-npi + - const: fsl,imx6ull + - description: i.MX6ULZ based Boards items: - enum: @@ -1050,6 +1058,7 @@ properties: - enum: - beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit - dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC + - emcraft,imx8mp-navqp # i.MX8MP Emcraft Systems NavQ+ Kit - fsl,imx8mp-evk # i.MX8MP EVK Board - gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board - gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board @@ -1218,7 +1227,6 @@ properties: - enum: - einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board - fsl,imx8qxp-mek # i.MX8QXP MEK Board - - toradex,colibri-imx8x # Colibri iMX8X Modules - const: fsl,imx8qxp - description: i.MX8DXL based Boards @@ -1227,7 +1235,7 @@ properties: - fsl,imx8dxl-evk # i.MX8DXL EVK Board - const: fsl,imx8dxl - - description: i.MX8QXP Boards with Toradex Colibri iMX8X Modules + - description: i.MX8QXP/i.MX8DX Boards with Toradex Colibri iMX8X Modules items: - enum: - toradex,colibri-imx8x-aster # Colibri iMX8X Module on Aster Board @@ -1235,7 +1243,9 @@ properties: - toradex,colibri-imx8x-iris # Colibri iMX8X Module on Iris Board - toradex,colibri-imx8x-iris-v2 # Colibri iMX8X Module on Iris Board V2 - const: toradex,colibri-imx8x - - const: fsl,imx8qxp + - enum: + - fsl,imx8qxp + - fsl,imx8dx - description: TQMa8Xx is a series of SOM featuring NXP i.MX8X system-on-chip @@ -1536,6 +1546,12 @@ properties: - nxp,s32g274a-rdb2 - const: nxp,s32g2 + - description: S32G3 based Boards + items: + - enum: + - nxp,s32g399a-rdb3 + - const: nxp,s32g3 + - description: S32V234 based Boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml index c24ad0968f3e..7f06b1080244 100644 --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml @@ -61,10 +61,6 @@ properties: mboxes: minItems: 2 - ti,system-reboot-controller: - description: Determines If system reboot can be triggered by SoC reboot - type: boolean - ti,host-id: $ref: /schemas/types.yaml#/definitions/uint32 description: | @@ -94,7 +90,6 @@ examples: - | pmmc: system-controller@2921800 { compatible = "ti,k2g-sci"; - ti,system-reboot-controller; mbox-names = "rx", "tx"; mboxes = <&msgmgr 5 2>, <&msgmgr 0 0>; diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 66beaac60e1d..ae885414b181 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -137,6 +137,7 @@ properties: - microsoft,dempsey - microsoft,makepeace - microsoft,moneypenny + - motorola,falcon - samsung,s3ve3g - const: qcom,msm8226 @@ -184,13 +185,16 @@ properties: - oneplus,bacon - samsung,klte - sony,xperia-castor + - sony,xperia-leo - const: qcom,msm8974pro - const: qcom,msm8974 - items: - - const: qcom,msm8916-mtp - - const: qcom,msm8916-mtp/1 - - const: qcom,msm8916 + - enum: + - samsung,kltechn + - const: samsung,klte + - const: qcom,msm8974pro + - const: qcom,msm8974 - items: - enum: @@ -200,6 +204,8 @@ properties: - gplus,fl8005a - huawei,g7 - longcheer,l8910 + - longcheer,l8150 + - qcom,msm8916-mtp - samsung,a3u-eur - samsung,a5u-eur - samsung,e5 @@ -221,11 +227,6 @@ properties: - const: qcom,msm8916 - items: - - const: longcheer,l8150 - - const: qcom,msm8916-v1-qrd/9-v1 - - const: qcom,msm8916 - - - items: - enum: - motorola,potter - xiaomi,daisy @@ -1003,6 +1004,7 @@ properties: - qcom,sm8550-hdk - qcom,sm8550-mtp - qcom,sm8550-qrd + - sony,pdx234 - const: qcom,sm8550 - items: diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index fcf7316ecd74..e04c213a0dee 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -49,6 +49,11 @@ properties: - anbernic,rg-arc-s - const: rockchip,rk3566 + - description: ArmSoM Sige7 board + items: + - const: armsom,sige7 + - const: rockchip,rk3588 + - description: Asus Tinker board items: - const: asus,rk3288-tinker @@ -198,6 +203,13 @@ properties: - const: firefly,rk3568-roc-pc - const: rockchip,rk3568 + - description: Forlinx FET3588-C SoM + items: + - enum: + - forlinx,ok3588-c + - const: forlinx,fet3588-c + - const: rockchip,rk3588 + - description: FriendlyElec NanoPi R2 series boards items: - enum: @@ -236,6 +248,11 @@ properties: - const: friendlyarm,nanopc-t6 - const: rockchip,rk3588 + - description: GameForce Chi + items: + - const: gameforce,chi + - const: rockchip,rk3326 + - description: GeekBuying GeekBox items: - const: geekbuying,geekbox @@ -631,7 +648,7 @@ properties: - const: phytec,rk3288-phycore-som - const: rockchip,rk3288 - - description: Pine64 PinebookPro + - description: Pine64 Pinebook Pro items: - const: pine64,pinebook-pro - const: rockchip,rk3399 @@ -644,7 +661,7 @@ properties: - const: pine64,pinenote - const: rockchip,rk3566 - - description: Pine64 PinePhonePro + - description: Pine64 PinePhone Pro items: - const: pine64,pinephone-pro - const: rockchip,rk3399 @@ -682,7 +699,7 @@ properties: - const: pine64,quartzpro64 - const: rockchip,rk3588 - - description: Pine64 SoQuartz SoM + - description: Pine64 SOQuartz items: - enum: - pine64,soquartz-blade @@ -700,12 +717,17 @@ properties: - powkiddy,x55 - const: rockchip,rk3566 + - description: Protonic MECSBC board + items: + - const: prt,mecsbc + - const: rockchip,rk3568 + - description: QNAP TS-433-4G 4-Bay NAS items: - const: qnap,ts433 - const: rockchip,rk3568 - - description: Radxa Compute Module 3(CM3) + - description: Radxa Compute Module 3 (CM3) items: - enum: - radxa,cm3-io @@ -767,22 +789,27 @@ properties: - const: radxa,rockpis - const: rockchip,rk3308 - - description: Radxa Rock2 Square + - description: Radxa Rock 2 Square items: - const: radxa,rock2-square - const: rockchip,rk3288 - - description: Radxa ROCK3 Model A + - description: Radxa ROCK 3A items: - const: radxa,rock3a - const: rockchip,rk3568 - - description: Radxa ROCK 5 Model A + - description: Radxa ROCK 3C + items: + - const: radxa,rock-3c + - const: rockchip,rk3566 + + - description: Radxa ROCK 5A items: - const: radxa,rock-5a - const: rockchip,rk3588s - - description: Radxa ROCK 5 Model B + - description: Radxa ROCK 5B items: - const: radxa,rock-5b - const: rockchip,rk3588 @@ -927,6 +954,11 @@ properties: - const: turing,rk1 - const: rockchip,rk3588 + - description: WolfVision PF5 mainboard + items: + - const: wolfvision,rk3568-pf5 + - const: rockchip,rk3568 + - description: Xunlong Orange Pi 5 Plus items: - const: xunlong,orangepi-5-plus diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 09d835db6db5..c6d0d8d81ed4 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -56,6 +56,21 @@ properties: - const: anbernic,rg-nano - const: allwinner,sun8i-v3s + - description: Anbernic RG35XX (2024) + - items: + - const: anbernic,rg35xx-2024 + - const: allwinner,sun50i-h700 + + - description: Anbernic RG35XX Plus + - items: + - const: anbernic,rg35xx-plus + - const: allwinner,sun50i-h700 + + - description: Anbernic RG35XX H + - items: + - const: anbernic,rg35xx-h + - const: allwinner,sun50i-h700 + - description: Amarula A64 Relic items: - const: amarula,a64-relic @@ -774,6 +789,11 @@ properties: - const: pocketbook,touch-lux-3 - const: allwinner,sun5i-a13 + - description: PocketBook 614 Plus + items: + - const: pocketbook,614-plus + - const: allwinner,sun5i-a13 + - description: Point of View Protab2-IPS9 items: - const: pov,protab2-ips9 @@ -860,6 +880,11 @@ properties: - const: allwinner,sl631 - const: allwinner,sun8i-v3 + - description: Tanix TX1 + items: + - const: oranth,tanix-tx1 + - const: allwinner,sun50i-h616 + - description: Tanix TX6 items: - const: oranth,tanix-tx6 diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt b/Documentation/devicetree/bindings/ata/ahci-da850.txt deleted file mode 100644 index 5f8193417725..000000000000 --- a/Documentation/devicetree/bindings/ata/ahci-da850.txt +++ /dev/null @@ -1,18 +0,0 @@ -Device tree binding for the TI DA850 AHCI SATA Controller ---------------------------------------------------------- - -Required properties: - - compatible: must be "ti,da850-ahci" - - reg: physical base addresses and sizes of the two register regions - used by the controller: the register map as defined by the - AHCI 1.1 standard and the Power Down Control Register (PWRDN) - for enabling/disabling the SATA clock receiver - - interrupts: interrupt specifier (refer to the interrupt binding) - -Example: - - sata: sata@218000 { - compatible = "ti,da850-ahci"; - reg = <0x218000 0x2000>, <0x22c018 0x4>; - interrupts = <67>; - }; diff --git a/Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml b/Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml new file mode 100644 index 000000000000..324e2413bba8 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/fsl,imx-pata.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX PATA Controller + +maintainers: + - Animesh Agarwal <animeshagarwal28@gmail.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx31-pata + - fsl,imx51-pata + - const: fsl,imx27-pata + - const: fsl,imx27-pata + + reg: + maxItems: 1 + + interrupts: + items: + - description: PATA Controller interrupts + + clocks: + items: + - description: PATA Controller clocks + +additionalProperties: false + +examples: + - | + pata: pata@83fe0000 { + compatible = "fsl,imx51-pata", "fsl,imx27-pata"; + reg = <0x83fe0000 0x4000>; + interrupts = <70>; + clocks = <&clks 161>; + }; diff --git a/Documentation/devicetree/bindings/ata/imx-pata.txt b/Documentation/devicetree/bindings/ata/imx-pata.txt deleted file mode 100644 index f1172f00188a..000000000000 --- a/Documentation/devicetree/bindings/ata/imx-pata.txt +++ /dev/null @@ -1,16 +0,0 @@ -* Freescale i.MX PATA Controller - -Required properties: -- compatible: "fsl,imx27-pata" -- reg: Address range of the PATA Controller -- interrupts: The interrupt of the PATA Controller -- clocks: the clocks for the PATA Controller - -Example: - - pata: pata@83fe0000 { - compatible = "fsl,imx51-pata", "fsl,imx27-pata"; - reg = <0x83fe0000 0x4000>; - interrupts = <70>; - clocks = <&clks 161>; - }; diff --git a/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml b/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml new file mode 100644 index 000000000000..ce13c76bdffb --- /dev/null +++ b/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/ti,da850-ahci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI DA850 AHCI SATA Controller + +maintainers: + - Animesh Agarwal <animeshagarwal28@gmail.com> + +properties: + compatible: + const: ti,da850-ahci + + reg: + items: + - description: Address and size of the register map as defined by the AHCI 1.1 standard. + - description: + Address and size of Power Down Control Register (PWRDN) for enabling/disabling the SATA clock + receiver. + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + sata@218000 { + compatible = "ti,da850-ahci"; + reg = <0x218000 0x2000>, <0x22c018 0x4>; + interrupts = <67>; + }; diff --git a/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml b/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml new file mode 100644 index 000000000000..d12b62a3a5a8 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/st,stm32-etzpc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STM32 Extended TrustZone protection controller + +description: | + The ETZPC configures TrustZone security in a SoC having bus masters and + devices with programmable-security attributes (securable resources). + +maintainers: + - Gatien Chevallier <gatien.chevallier@foss.st.com> + +select: + properties: + compatible: + contains: + const: st,stm32-etzpc + required: + - compatible + +properties: + compatible: + items: + - const: st,stm32-etzpc + - const: simple-bus + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + + "#access-controller-cells": + const: 1 + description: + Contains the firewall ID associated to the peripheral. + +patternProperties: + "^.*@[0-9a-f]+$": + description: Peripherals + type: object + + additionalProperties: true + + required: + - access-controllers + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - "#access-controller-cells" + - ranges + +additionalProperties: false + +examples: + - | + // In this example, the usart2 device refers to rifsc as its access + // controller. + // Access rights are verified before creating devices. + + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/stm32mp13-clks.h> + #include <dt-bindings/reset/stm32mp13-resets.h> + + etzpc: bus@5c007000 { + compatible = "st,stm32-etzpc", "simple-bus"; + reg = <0x5c007000 0x400>; + #address-cells = <1>; + #size-cells = <1>; + #access-controller-cells = <1>; + ranges; + + usart2: serial@4c001000 { + compatible = "st,stm32h7-uart"; + reg = <0x4c001000 0x400>; + interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&rcc USART2_K>; + resets = <&rcc USART2_R>; + wakeup-source; + dmas = <&dmamux1 43 0x400 0x5>, + <&dmamux1 44 0x400 0x1>; + dma-names = "rx", "tx"; + access-controllers = <&etzpc 17>; + }; + }; diff --git a/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml new file mode 100644 index 000000000000..20acd1a6b173 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/st,stm32mp25-rifsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STM32 Resource isolation framework security controller + +maintainers: + - Gatien Chevallier <gatien.chevallier@foss.st.com> + +description: | + Resource isolation framework (RIF) is a comprehensive set of hardware blocks + designed to enforce and manage isolation of STM32 hardware resources like + memory and peripherals. + + The RIFSC (RIF security controller) is composed of three sets of registers, + each managing a specific set of hardware resources: + - RISC registers associated with RISUP logic (resource isolation device unit + for peripherals), assign all non-RIF aware peripherals to zero, one or + any security domains (secure, privilege, compartment). + - RIMC registers: associated with RIMU logic (resource isolation master + unit), assign all non RIF-aware bus master to one security domain by + setting secure, privileged and compartment information on the system bus. + Alternatively, the RISUP logic controlling the device port access to a + peripheral can assign target bus attributes to this peripheral master port + (supported attribute: CID). + - RISC registers associated with RISAL logic (resource isolation device unit + for address space - Lite version), assign address space subregions to one + security domains (secure, privilege, compartment). + +select: + properties: + compatible: + contains: + const: st,stm32mp25-rifsc + required: + - compatible + +properties: + compatible: + items: + - const: st,stm32mp25-rifsc + - const: simple-bus + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + + "#access-controller-cells": + const: 1 + description: + Contains the firewall ID associated to the peripheral. + +patternProperties: + "^.*@[0-9a-f]+$": + description: Peripherals + type: object + + additionalProperties: true + + required: + - access-controllers + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - "#access-controller-cells" + - ranges + +additionalProperties: false + +examples: + - | + // In this example, the usart2 device refers to rifsc as its domain + // controller. + // Access rights are verified before creating devices. + + #include <dt-bindings/interrupt-controller/arm-gic.h> + + rifsc: bus@42080000 { + compatible = "st,stm32mp25-rifsc", "simple-bus"; + reg = <0x42080000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + #access-controller-cells = <1>; + ranges; + + usart2: serial@400e0000 { + compatible = "st,stm32h7-uart"; + reg = <0x400e0000 0x400>; + interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&ck_flexgen_08>; + access-controllers = <&rifsc 32>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml index 1d2bcea41c85..caf442ead24b 100644 --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml @@ -30,16 +30,18 @@ properties: - google,gs101-cmu-top - google,gs101-cmu-apm - google,gs101-cmu-misc + - google,gs101-cmu-hsi0 + - google,gs101-cmu-hsi2 - google,gs101-cmu-peric0 - google,gs101-cmu-peric1 clocks: minItems: 1 - maxItems: 3 + maxItems: 5 clock-names: minItems: 1 - maxItems: 3 + maxItems: 5 "#clock-cells": const: 1 @@ -76,6 +78,55 @@ allOf: properties: compatible: contains: + const: google,gs101-cmu-hsi0 + + then: + properties: + clocks: + items: + - description: External reference clock (24.576 MHz) + - description: HSI0 bus clock (from CMU_TOP) + - description: DPGTC (from CMU_TOP) + - description: USB DRD controller clock (from CMU_TOP) + - description: USB Display Port debug clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: bus + - const: dpgtc + - const: usb31drd + - const: usbdpdbg + + - if: + properties: + compatible: + contains: + enum: + - google,gs101-cmu-hsi2 + + then: + properties: + clocks: + items: + - description: External reference clock (24.576 MHz) + - description: High Speed Interface bus clock (from CMU_TOP) + - description: High Speed Interface pcie clock (from CMU_TOP) + - description: High Speed Interface ufs clock (from CMU_TOP) + - description: High Speed Interface mmc clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: bus + - const: pcie + - const: ufs + - const: mmc + + - if: + properties: + compatible: + contains: const: google,gs101-cmu-misc then: diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml index 56fc71d6a081..1e9797f96410 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -38,6 +38,7 @@ properties: - qcom,sc7280-cpufreq-epss - qcom,sc8280xp-cpufreq-epss - qcom,sdx75-cpufreq-epss + - qcom,sm4450-cpufreq-epss - qcom,sm6375-cpufreq-epss - qcom,sm8250-cpufreq-epss - qcom,sm8350-cpufreq-epss @@ -133,6 +134,7 @@ allOf: - qcom,sc8280xp-cpufreq-epss - qcom,sdm670-cpufreq-hw - qcom,sdm845-cpufreq-hw + - qcom,sm4450-cpufreq-epss - qcom,sm6115-cpufreq-hw - qcom,sm6350-cpufreq-hw - qcom,sm6375-cpufreq-epss diff --git a/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml new file mode 100644 index 000000000000..cb47ae2889b6 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/nvidia,tegra234-se-aes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Security Engine for AES algorithms + +description: + The Tegra Security Engine accelerates the following AES encryption/decryption + algorithms - AES-ECB, AES-CBC, AES-OFB, AES-XTS, AES-CTR, AES-GCM, AES-CCM, + AES-CMAC + +maintainers: + - Akhil R <akhilrajeev@nvidia.com> + +properties: + compatible: + const: nvidia,tegra234-se-aes + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + iommus: + maxItems: 1 + + dma-coherent: true + +required: + - compatible + - reg + - clocks + - iommus + +additionalProperties: false + +examples: + - | + #include <dt-bindings/memory/tegra234-mc.h> + #include <dt-bindings/clock/tegra234-clock.h> + + crypto@15820000 { + compatible = "nvidia,tegra234-se-aes"; + reg = <0x15820000 0x10000>; + clocks = <&bpmp TEGRA234_CLK_SE>; + iommus = <&smmu TEGRA234_SID_SES_SE1>; + dma-coherent; + }; +... diff --git a/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml new file mode 100644 index 000000000000..f57ef10645e2 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/nvidia,tegra234-se-hash.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Security Engine for HASH algorithms + +description: + The Tegra Security HASH Engine accelerates the following HASH functions - + SHA1, SHA224, SHA256, SHA384, SHA512, SHA3-224, SHA3-256, SHA3-384, SHA3-512 + HMAC(SHA224), HMAC(SHA256), HMAC(SHA384), HMAC(SHA512) + +maintainers: + - Akhil R <akhilrajeev@nvidia.com> + +properties: + compatible: + const: nvidia,tegra234-se-hash + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + iommus: + maxItems: 1 + + dma-coherent: true + +required: + - compatible + - reg + - clocks + - iommus + +additionalProperties: false + +examples: + - | + #include <dt-bindings/memory/tegra234-mc.h> + #include <dt-bindings/clock/tegra234-clock.h> + + crypto@15840000 { + compatible = "nvidia,tegra234-se-hash"; + reg = <0x15840000 0x10000>; + clocks = <&bpmp TEGRA234_CLK_SE>; + iommus = <&smmu TEGRA234_SID_SES_SE2>; + dma-coherent; + }; +... diff --git a/Documentation/devicetree/bindings/crypto/omap-sham.txt b/Documentation/devicetree/bindings/crypto/omap-sham.txt deleted file mode 100644 index ad9115569611..000000000000 --- a/Documentation/devicetree/bindings/crypto/omap-sham.txt +++ /dev/null @@ -1,28 +0,0 @@ -OMAP SoC SHA crypto Module - -Required properties: - -- compatible : Should contain entries for this and backward compatible - SHAM versions: - - "ti,omap2-sham" for OMAP2 & OMAP3. - - "ti,omap4-sham" for OMAP4 and AM33XX. - - "ti,omap5-sham" for OMAP5, DRA7 and AM43XX. -- ti,hwmods: Name of the hwmod associated with the SHAM module -- reg : Offset and length of the register set for the module -- interrupts : the interrupt-specifier for the SHAM module. - -Optional properties: -- dmas: DMA specifiers for the rx dma. See the DMA client binding, - Documentation/devicetree/bindings/dma/dma.txt -- dma-names: DMA request name. Should be "rx" if a dma is present. - -Example: - /* AM335x */ - sham: sham@53100000 { - compatible = "ti,omap4-sham"; - ti,hwmods = "sham"; - reg = <0x53100000 0x200>; - interrupts = <109>; - dmas = <&edma 36>; - dma-names = "rx"; - }; diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml index e91bc7dc6ad3..0304f074cf08 100644 --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml @@ -15,6 +15,7 @@ properties: - enum: - qcom,sa8775p-inline-crypto-engine - qcom,sc7180-inline-crypto-engine + - qcom,sc7280-inline-crypto-engine - qcom,sm8450-inline-crypto-engine - qcom,sm8550-inline-crypto-engine - qcom,sm8650-inline-crypto-engine diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml index 0ddeb8a9a7a0..27354658d054 100644 --- a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml +++ b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml @@ -46,6 +46,10 @@ properties: power-domains: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml index ac480765cde0..822318414095 100644 --- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml +++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml @@ -51,6 +51,10 @@ properties: power-domains: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml b/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml index 71a2876bd6e4..7ccb6e1641d0 100644 --- a/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml +++ b/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml @@ -12,7 +12,9 @@ maintainers: properties: compatible: - const: starfive,jh7110-crypto + enum: + - starfive,jh7110-crypto + - starfive,jh8100-crypto reg: maxItems: 1 @@ -28,7 +30,10 @@ properties: - const: ahb interrupts: - maxItems: 1 + minItems: 1 + items: + - description: SHA2 module irq + - description: SM3 module irq resets: maxItems: 1 @@ -54,6 +59,27 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + const: starfive,jh7110-crypto + + then: + properties: + interrupts: + maxItems: 1 + + - if: + properties: + compatible: + const: starfive,jh8100-crypto + + then: + properties: + interrupts: + minItems: 2 + examples: - | crypto: crypto@16000000 { diff --git a/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml b/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml new file mode 100644 index 000000000000..d69b50228009 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/ti,omap-sham.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OMAP SoC SHA crypto Module + +maintainers: + - Animesh Agarwal <animeshagarwal28@gmail.com> + +properties: + compatible: + enum: + - ti,omap2-sham + - ti,omap4-sham + - ti,omap5-sham + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + const: rx + + ti,hwmods: + description: Name of the hwmod associated with the SHAM module + $ref: /schemas/types.yaml#/definitions/string + enum: [sham] + +dependencies: + dmas: [dma-names] + +additionalProperties: false + +required: + - compatible + - ti,hwmods + - reg + - interrupts + +examples: + - | + sham@53100000 { + compatible = "ti,omap4-sham"; + ti,hwmods = "sham"; + reg = <0x53100000 0x200>; + interrupts = <109>; + dmas = <&edma 36>; + dma-names = "rx"; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml index c9a882ee6d98..c4469f463978 100644 --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml @@ -9,6 +9,9 @@ title: ITE it6505 maintainers: - Allen Chen <allen.chen@ite.com.tw> +allOf: + - $ref: /schemas/sound/dai-common.yaml# + description: | The IT6505 is a high-performance DisplayPort 1.1a transmitter, fully compliant with DisplayPort 1.1a, HDCP 1.3 specifications. @@ -52,6 +55,9 @@ properties: maxItems: 1 description: extcon specifier for the Power Delivery + "#sound-dai-cells": + const: 0 + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -105,7 +111,7 @@ required: - extcon - ports -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 84aafcbf0919..6ceeed76e88e 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -41,6 +41,7 @@ properties: - enum: - ti,ds90cf364a # For the DS90CF364A FPD-Link LVDS Receiver - ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver + - ti,sn65lvds94 # For the SN65DS94 LVDS serdes - const: lvds-decoder # Generic LVDS decoders compatible fallback - enum: - thine,thc63lvdm83d # For the THC63LVDM83D LVDS serializer diff --git a/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml new file mode 100644 index 000000000000..862ef441ac9f --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/microchip,sam9x75-lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip SAM9X75 LVDS Controller + +maintainers: + - Dharma Balasubiramani <dharma.b@microchip.com> + +description: + The Low Voltage Differential Signaling Controller (LVDSC) manages data + format conversion from the LCD Controller internal DPI bus to OpenLDI + LVDS output signals. LVDSC functions include bit mapping, balanced mode + management, and serializer. + +properties: + compatible: + const: microchip,sam9x75-lvds + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Peripheral Bus Clock + + clock-names: + items: + - const: pclk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/at91.h> + lvds-controller@f8060000 { + compatible = "microchip,sam9x75-lvds"; + reg = <0xf8060000 0x100>; + interrupts = <56 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 56>; + clock-names = "pclk"; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml index d879c700594a..258dd9cfd770 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml @@ -10,7 +10,7 @@ maintainers: - Vinay Simha BN <simhavcs@gmail.com> description: | - This binding supports DSI to LVDS bridge TC358775 + This binding supports DSI to LVDS bridges TC358765 and TC358775 MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane. Video frame size: @@ -21,7 +21,9 @@ description: | properties: compatible: - const: toshiba,tc358775 + enum: + - toshiba,tc358765 + - toshiba,tc358775 reg: maxItems: 1 @@ -46,11 +48,27 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: | DSI Input. The remote endpoint phandle should be a reference to a valid mipi_dsi_host device node. + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + port@1: $ref: /schemas/graph.yaml#/properties/port description: | @@ -70,10 +88,19 @@ required: - reg - vdd-supply - vddio-supply - - stby-gpios - reset-gpios - ports +allOf: + - if: + properties: + compatible: + contains: + const: toshiba,tc358765 + then: + properties: + stby-gpios: false + additionalProperties: false examples: @@ -108,6 +135,7 @@ examples: reg = <0>; d2l_in_test: endpoint { remote-endpoint = <&dsi0_out>; + data-lanes = <1 2 3 4>; }; }; @@ -132,7 +160,6 @@ examples: reg = <1>; dsi0_out: endpoint { remote-endpoint = <&d2l_in_test>; - data-lanes = <0 1 2 3>; }; }; }; @@ -167,6 +194,7 @@ examples: reg = <0>; d2l_in_dual: endpoint { remote-endpoint = <&dsi0_out_dual>; + data-lanes = <1 2 3 4>; }; }; @@ -198,7 +226,6 @@ examples: reg = <1>; dsi0_out_dual: endpoint { remote-endpoint = <&d2l_in_dual>; - data-lanes = <0 1 2 3>; }; }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index c6641acd75d6..b8b8e83ebc3f 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -24,6 +24,7 @@ properties: - enum: - mediatek,mt8173-disp-gamma - mediatek,mt8183-disp-gamma + - mediatek,mt8195-disp-gamma - items: - enum: - mediatek,mt6795-disp-gamma @@ -35,6 +36,10 @@ properties: - mediatek,mt8192-disp-gamma - mediatek,mt8195-disp-gamma - const: mediatek,mt8183-disp-gamma + - items: + - enum: + - mediatek,mt8188-disp-gamma + - const: mediatek,mt8195-disp-gamma reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index ae53cbfb2193..97993feda193 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -29,6 +29,7 @@ properties: - qcom,sm8650-dp - items: - enum: + - qcom,sm6350-dp - qcom,sm8150-dp - qcom,sm8250-dp - qcom,sm8450-dp diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml index c9ba1fae8042..bba666bdffe5 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml @@ -53,6 +53,15 @@ patternProperties: compatible: const: qcom,sm6350-dpu + "^displayport-controller@[0-9a-f]+$": + type: object + additionalProperties: true + + properties: + compatible: + contains: + const: qcom,sm6350-dp + "^dsi@[0-9a-f]+$": type: object additionalProperties: true diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml index b1e624be3e33..a015dce72f60 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml @@ -19,6 +19,7 @@ properties: - ampire,am8001280g - bananapi,lhr050h41 - feixin,k101-im2byl02 + - startek,kd050hdfia020 - tdo,tl050hdv35 - wanchanglong,w552946aba - const: ilitek,ili9881c diff --git a/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml b/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml new file mode 100644 index 000000000000..1e08648f5bc7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/lg,sw43408.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LG SW43408 1080x2160 DSI panel + +maintainers: + - Caleb Connolly <caleb.connolly@linaro.org> + +description: + This panel is used on the Pixel 3, it is a 60hz OLED panel which + required DSC (Display Stream Compression) and has rounded corners. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - const: lg,sw43408 + + reg: true + port: true + vddi-supply: true + vpnl-supply: true + reset-gpios: true + +required: + - compatible + - vddi-supply + - vpnl-supply + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "lg,sw43408"; + reg = <0>; + + vddi-supply = <&vreg_l14a_1p88>; + vpnl-supply = <&vreg_l28a_3p0>; + + reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>; + + port { + endpoint { + remote-endpoint = <&mdss_dsi0_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml index 377a05d48a02..7cac93b20944 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml @@ -19,7 +19,7 @@ description: | either bilinear interpolation or pixel duplication. allOf: - - $ref: panel-common.yaml# + - $ref: panel-common-dual.yaml# properties: compatible: @@ -59,6 +59,7 @@ required: - avee-supply - dvdd-supply - vddio-supply + - ports additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml index 5f7e4c486094..bbeea8cfa5fb 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml @@ -14,9 +14,6 @@ description: | panels. Support video mode panels from China Star Optoelectronics Technology (CSOT) and BOE Technology. -allOf: - - $ref: panel-common.yaml# - properties: compatible: oneOf: @@ -38,7 +35,6 @@ properties: description: regulator that supplies the I/O voltage reg: true - ports: true rotation: true backlight: true @@ -47,7 +43,26 @@ required: - reg - vddio-supply - reset-gpios - - ports + +allOf: + - $ref: panel-common-dual.yaml# + - if: + properties: + compatible: + contains: + enum: + - novatek,nt36523w + then: + properties: + ports: + properties: + port@1: false + else: + properties: + port: false + ports: + required: + - port@1 unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/display/panel/panel-common-dual.yaml b/Documentation/devicetree/bindings/display/panel/panel-common-dual.yaml new file mode 100644 index 000000000000..cc7ea3c35c77 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-common-dual.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-common-dual.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common Properties for Dual-Link Display Panels + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + +description: + Properties common for Panel IC supporting dual link panels. Devices might + support also single link. + +allOf: + - $ref: panel-common.yaml# + +properties: + ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: First link + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Second link + + "#address-cells": true + "#size-cells": true + + required: + - port@0 + +# Single-panel setups are still allowed. +oneOf: + - required: + - ports + - required: + - port + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index f9160d7bac3c..db5acd2807ed 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -36,6 +36,8 @@ properties: - jdi,fhd-r63452 # Khadas TS050 5" 1080x1920 LCD panel - khadas,ts050 + # Khadas TS050 V2 5" 1080x1920 LCD panel + - khadas,ts050v2 # Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel - kingdisplay,kd097d04 # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel @@ -50,6 +52,8 @@ properties: - panasonic,vvx10f004b00 # Panasonic 10" WUXGA TFT LCD panel - panasonic,vvx10f034n00 + # Samsung s6e3fa7 1080x2220 based AMS559NK06 AMOLED panel + - samsung,s6e3fa7-ams559nk06 # Samsung s6e3fc2x01 1080x2340 AMOLED panel - samsung,s6e3fc2x01 # Samsung sofef00 1080x2280 AMOLED panel diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index a95445f40870..5067f5c0a272 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -91,6 +91,8 @@ properties: - boe,nv133fhm-n62 # BOE NV140FHM-N49 14.0" FHD a-Si FT panel - boe,nv140fhmn49 + # Crystal Clear Technology CMT430B19N00 4.3" 480x272 TFT-LCD panel + - cct,cmt430b19n00 # CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel - cdtech,s043wq26h-ct7 # CDTech(H.K.) Electronics Limited 7" WSVGA (1024x600) TFT LCD Panel @@ -188,6 +190,8 @@ properties: - innolux,g121i1-l01 # Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel - innolux,g121x1-l03 + # Innolux Corporation 12.1" G121XCE-L01 XGA (1024x768) TFT LCD panel + - innolux,g121xce-l01 # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel - innolux,n116bca-ea1 # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel @@ -272,6 +276,8 @@ properties: - osddisplays,osd070t1718-19ts # One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel - osddisplays,osd101t2045-53ts + # POWERTIP PH128800T006-ZHC01 10.1" WXGA TFT LCD panel + - powertip,ph128800t006-zhc01 # POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel - powertip,ph800480t013-idf02 # QiaoDian XianShi Corporation 4"3 TFT LCD panel @@ -348,15 +354,6 @@ properties: # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel - yes-optoelectronics,ytc700tlag-05-201c - backlight: true - ddc-i2c-bus: true - enable-gpios: true - port: true - power-supply: true - no-hpd: true - hpd-gpios: true - data-mapping: true - if: not: properties: @@ -367,7 +364,7 @@ then: properties: data-mapping: false -additionalProperties: false +unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml new file mode 100644 index 000000000000..b17765b2b351 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Raydium RM69380-based DSI display panels + +maintainers: + - David Wronek <david@mainlining.org> + +description: + The Raydium RM69380 is a generic DSI panel IC used to control + OLED panels. + +allOf: + - $ref: panel-common-dual.yaml# + +properties: + compatible: + items: + - enum: + - lenovo,j716f-edo-rm69380 + - const: raydium,rm69380 + description: This indicates the panel manufacturer of the panel + that is in turn using the RM69380 panel driver. The compatible + string determines how the RM69380 panel driver shall be configured + to work with the indicated panel. The raydium,rm69380 compatible shall + always be provided as a fallback. + + avdd-supply: + description: Analog voltage rail + + vddio-supply: + description: I/O voltage rail + + reset-gpios: + maxItems: 1 + description: phandle of gpio for reset line - This should be active low + + reg: true + +required: + - compatible + - reg + - avdd-supply + - vddio-supply + - reset-gpios + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "lenovo,j716f-edo-rm69380", "raydium,rm69380"; + reg = <0>; + + avdd-supply = <&panel_avdd_regulator>; + vddio-supply = <&vreg_l14a>; + reset-gpios = <&tlmm 75 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + panel_in_0: endpoint { + remote-endpoint = <&mdss_dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + panel_in_1: endpoint { + remote-endpoint = <&mdss_dsi1_out>; + }; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml index 6ec471284f97..4ae152cc55e0 100644 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml @@ -22,6 +22,8 @@ properties: enum: # Anberic RG353V-V2 5.0" 640x480 TFT LCD panel - anbernic,rg353v-panel-v2 + # GameForce Chi 3.5" 640x480 TFT LCD panel + - gameforce,chi-panel # Powkiddy RGB10MAX3 5.0" 720x1280 TFT LCD panel - powkiddy,rgb10max3-panel # Powkiddy RGB30 3.0" 720x720 TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml b/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml index b6b885b4c22d..07bce556ad40 100644 --- a/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml +++ b/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml @@ -23,6 +23,8 @@ properties: reg: true backlight: true + width-mm: true + height-mm: true vddio-supply: description: VDDIO 1.8V supply diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml index af638b6c0d21..2aac62219ff6 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml @@ -15,6 +15,7 @@ description: | allOf: - $ref: ../bridge/synopsys,dw-hdmi.yaml# + - $ref: /schemas/sound/dai-common.yaml# properties: compatible: @@ -124,6 +125,9 @@ properties: description: phandle to the GRF to mux vopl/vopb. + "#sound-dai-cells": + const: 0 + required: - compatible - reg @@ -153,6 +157,7 @@ examples: ddc-i2c-bus = <&i2c5>; power-domains = <&power RK3288_PD_VIO>; rockchip,grf = <&grf>; + #sound-dai-cells = <0>; ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml index be78dcfa1c76..5b87b0f1963e 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml @@ -37,6 +37,9 @@ properties: power-domains: maxItems: 1 + "#sound-dai-cells": + const: 0 + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -66,6 +69,7 @@ required: - ports allOf: + - $ref: /schemas/sound/dai-common.yaml# - if: properties: compatible: @@ -106,6 +110,7 @@ examples: clock-names = "pclk"; pinctrl-names = "default"; pinctrl-0 = <&hdmi_ctl>; + #sound-dai-cells = <0>; ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml index 1a68a940d165..6d4b78a36576 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml @@ -10,6 +10,9 @@ maintainers: - Sandy Huang <hjc@rock-chips.com> - Heiko Stuebner <heiko@sntech.de> +allOf: + - $ref: /schemas/sound/dai-common.yaml# + properties: compatible: const: rockchip,rk3066-hdmi @@ -34,6 +37,9 @@ properties: description: This soc uses GRF regs to switch the HDMI TX input between vop0 and vop1. + "#sound-dai-cells": + const: 0 + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -83,6 +89,7 @@ examples: pinctrl-names = "default"; power-domains = <&power RK3066_PD_VIO>; rockchip,grf = <&grf>; + #sound-dai-cells = <0>; ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml index 94c5242c03b2..3563378a01af 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml @@ -182,6 +182,15 @@ allOf: compatible: contains: enum: + - nvidia,tegra194-host1x + then: + properties: + dma-coherent: true + - if: + properties: + compatible: + contains: + enum: - nvidia,tegra234-host1x then: properties: @@ -226,6 +235,8 @@ allOf: use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to usable stream IDs. + dma-coherent: true + required: - reg-names diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml index 329847ef096a..ff935a0068ec 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml @@ -82,6 +82,10 @@ properties: description: if defined, it indicates that the controller supports memory-to-memory transfer + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml index e722fbcd8a5f..ddf82bf1e71a 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml @@ -28,6 +28,10 @@ properties: resets: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 4591523b51a0..7de2c29606e5 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -247,6 +247,37 @@ properties: reg: const: 0x18 + protocol@19: + type: object + allOf: + - $ref: '#/$defs/protocol-node' + - $ref: /schemas/pinctrl/pinctrl.yaml + + unevaluatedProperties: false + + properties: + reg: + const: 0x19 + + patternProperties: + '-pins$': + type: object + allOf: + - $ref: /schemas/pinctrl/pincfg-node.yaml# + - $ref: /schemas/pinctrl/pinmux-node.yaml# + unevaluatedProperties: false + + description: + A pin multiplexing sub-node describes how to configure a + set of pins in some desired function. + A single sub-node may define several pin configurations. + This sub-node is using the default pinctrl bindings to configure + pin multiplexing and using SCMI protocol to apply a specified + configuration. + + required: + - reg + additionalProperties: false $defs: @@ -355,7 +386,7 @@ examples: scmi_dvfs: protocol@13 { reg = <0x13>; - #clock-cells = <1>; + #power-domain-cells = <1>; mboxes = <&mhuB 1 0>, <&mhuB 1 1>; @@ -401,6 +432,25 @@ examples: scmi_powercap: protocol@18 { reg = <0x18>; }; + + scmi_pinctrl: protocol@19 { + reg = <0x19>; + + i2c2-pins { + groups = "g_i2c2_a", "g_i2c2_b"; + function = "f_i2c2"; + }; + + mdio-pins { + groups = "g_avb_mdio"; + drive-strength = <24>; + }; + + keys_pins: keys-pins { + pins = "gpio_5_17", "gpio_5_20", "gpio_5_22", "gpio_2_1"; + bias-pull-up; + }; + }; }; }; @@ -468,7 +518,7 @@ examples: reg = <0x13>; linaro,optee-channel-id = <1>; shmem = <&cpu_optee_lpri0>; - #clock-cells = <1>; + #power-domain-cells = <1>; }; scmi_clk0: protocol@14 { diff --git a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml index a1e71c974e79..f096f286da19 100644 --- a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml @@ -62,6 +62,8 @@ properties: interrupt-controller: true + gpio-ranges: true + wakeup-source: type: boolean description: > @@ -88,6 +90,7 @@ examples: interrupt-parent = <&irq0_intc>; interrupts = <0x6>; brcm,gpio-bank-widths = <32 32 32 24>; + gpio-ranges = <&pinctrl 0 0 120>; }; upg_gio_aon: gpio@f04172c0 { diff --git a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml index d481e78958a7..d61569b3f15b 100644 --- a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml @@ -14,6 +14,7 @@ properties: items: - enum: - microchip,mpfs-gpio + - microchip,coregpio-rtl-v3 reg: maxItems: 1 @@ -43,6 +44,7 @@ properties: default: 32 gpio-controller: true + gpio-line-names: true patternProperties: "^.+-hog(-[0-9]+)?$": @@ -62,12 +64,21 @@ patternProperties: - gpio-hog - gpios +allOf: + - if: + properties: + compatible: + contains: + const: microchip,mpfs-gpio + then: + required: + - interrupts + - "#interrupt-cells" + - interrupt-controller + required: - compatible - reg - - interrupts - - "#interrupt-cells" - - interrupt-controller - "#gpio-cells" - gpio-controller - clocks diff --git a/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt b/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt deleted file mode 100644 index ce97265e23ba..000000000000 --- a/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt +++ /dev/null @@ -1,30 +0,0 @@ -Raspberry Pi GPIO expander - -The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware. The -firmware exposes a mailbox interface that allows the ARM core to control the -GPIO lines on the expander. - -The Raspberry Pi GPIO expander node must be a child node of the Raspberry Pi -firmware node. - -Required properties: - -- compatible : Should be "raspberrypi,firmware-gpio" -- gpio-controller : Marks the device node as a gpio controller -- #gpio-cells : Should be two. The first cell is the pin number, and - the second cell is used to specify the gpio polarity: - 0 = active high - 1 = active low - -Example: - -firmware: firmware-rpi { - compatible = "raspberrypi,bcm2835-firmware"; - mboxes = <&mailbox>; - - expgpio: gpio { - compatible = "raspberrypi,firmware-gpio"; - gpio-controller; - #gpio-cells = <2>; - }; -}; diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml new file mode 100644 index 000000000000..a5b4e0021758 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml @@ -0,0 +1,147 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpu/arm,mali-valhall-csf.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Mali Valhall GPU + +maintainers: + - Liviu Dudau <liviu.dudau@arm.com> + - Boris Brezillon <boris.brezillon@collabora.com> + +properties: + $nodename: + pattern: '^gpu@[a-f0-9]+$' + + compatible: + oneOf: + - items: + - enum: + - rockchip,rk3588-mali + - const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable + + reg: + maxItems: 1 + + interrupts: + items: + - description: Job interrupt + - description: MMU interrupt + - description: GPU interrupt + + interrupt-names: + items: + - const: job + - const: mmu + - const: gpu + + clocks: + minItems: 1 + maxItems: 3 + + clock-names: + minItems: 1 + items: + - const: core + - const: coregroup + - const: stacks + + mali-supply: true + + operating-points-v2: true + opp-table: + type: object + + power-domains: + minItems: 1 + maxItems: 5 + + power-domain-names: + minItems: 1 + maxItems: 5 + + sram-supply: true + + "#cooling-cells": + const: 2 + + dynamic-power-coefficient: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + A u32 value that represents the running time dynamic + power coefficient in units of uW/MHz/V^2. The + coefficient can either be calculated from power + measurements or derived by analysis. + + The dynamic power consumption of the GPU is + proportional to the square of the Voltage (V) and + the clock frequency (f). The coefficient is used to + calculate the dynamic power as below - + + Pdyn = dynamic-power-coefficient * V^2 * f + + where voltage is in V, frequency is in MHz. + + dma-coherent: true + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - mali-supply + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3588-mali + then: + properties: + clocks: + minItems: 3 + power-domains: + maxItems: 1 + power-domain-names: false + +examples: + - | + #include <dt-bindings/clock/rockchip,rk3588-cru.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/rk3588-power.h> + + gpu: gpu@fb000000 { + compatible = "rockchip,rk3588-mali", "arm,mali-valhall-csf"; + reg = <0xfb000000 0x200000>; + interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH 0>, + <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH 0>, + <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH 0>; + interrupt-names = "job", "mmu", "gpu"; + clock-names = "core", "coregroup", "stacks"; + clocks = <&cru CLK_GPU>, <&cru CLK_GPU_COREGROUP>, + <&cru CLK_GPU_STACKS>; + power-domains = <&power RK3588_PD_GPU>; + operating-points-v2 = <&gpu_opp_table>; + mali-supply = <&vdd_gpu_s0>; + sram-supply = <&vdd_gpu_mem_s0>; + + gpu_opp_table: opp-table { + compatible = "operating-points-v2"; + opp-300000000 { + opp-hz = /bits/ 64 <300000000>; + opp-microvolt = <675000 675000 850000>; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <675000 675000 850000>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/hwmon/adc128d818.txt b/Documentation/devicetree/bindings/hwmon/adc128d818.txt deleted file mode 100644 index d0ae46d7bac3..000000000000 --- a/Documentation/devicetree/bindings/hwmon/adc128d818.txt +++ /dev/null @@ -1,38 +0,0 @@ -TI ADC128D818 ADC System Monitor With Temperature Sensor --------------------------------------------------------- - -Operation modes: - - - Mode 0: 7 single-ended voltage readings (IN0-IN6), - 1 temperature reading (internal) - - Mode 1: 8 single-ended voltage readings (IN0-IN7), - no temperature - - Mode 2: 4 pseudo-differential voltage readings - (IN0-IN1, IN3-IN2, IN4-IN5, IN7-IN6), - 1 temperature reading (internal) - - Mode 3: 4 single-ended voltage readings (IN0-IN3), - 2 pseudo-differential voltage readings - (IN4-IN5, IN7-IN6), - 1 temperature reading (internal) - -If no operation mode is configured via device tree, the driver keeps the -currently active chip operation mode (default is mode 0). - - -Required node properties: - - - compatible: must be set to "ti,adc128d818" - - reg: I2C address of the device - -Optional node properties: - - - ti,mode: Operation mode (u8) (see above). - - -Example (operation mode 2): - - adc128d818@1d { - compatible = "ti,adc128d818"; - reg = <0x1d>; - ti,mode = /bits/ 8 <2>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml index b68061294964..5b076d677395 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml @@ -5,7 +5,7 @@ $id: http://devicetree.org/schemas/hwmon/adi,adm1275.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Analog Devices ADM1075/ADM127x/ADM129x digital power monitors +title: Analog Devices ADM1075/ADM127x/ADM1281/ADM129x digital power monitors maintainers: - Krzysztof Kozlowski <krzk@kernel.org> @@ -27,6 +27,7 @@ properties: - adi,adm1275 - adi,adm1276 - adi,adm1278 + - adi,adm1281 - adi,adm1293 - adi,adm1294 @@ -91,6 +92,7 @@ allOf: contains: enum: - adi,adm1278 + - adi,adm1281 - adi,adm1293 - adi,adm1294 then: diff --git a/Documentation/devicetree/bindings/hwmon/as370.txt b/Documentation/devicetree/bindings/hwmon/as370.txt deleted file mode 100644 index d102fe765124..000000000000 --- a/Documentation/devicetree/bindings/hwmon/as370.txt +++ /dev/null @@ -1,11 +0,0 @@ -Bindings for Synaptics AS370 PVT sensors - -Required properties: -- compatible : "syna,as370-hwmon" -- reg : address and length of the register set. - -Example: - hwmon@ea0810 { - compatible = "syna,as370-hwmon"; - reg = <0xea0810 0xc>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml b/Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml new file mode 100644 index 000000000000..376ee7f1cdb7 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/ibm,opal-sensor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IBM POWERNV platform sensors + +maintainers: + - Javier Carrasco <javier.carrasco.cruz@gmail.com> + +properties: + compatible: + enum: + - ibm,opal-sensor-cooling-fan + - ibm,opal-sensor-amb-temp + - ibm,opal-sensor-power-supply + - ibm,opal-sensor-power + + sensor-id: + description: + An opaque id provided by the firmware to the kernel, identifies a + given sensor and its attribute data. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - sensor-id + +additionalProperties: false + +examples: + - | + sensor { + compatible = "ibm,opal-sensor-cooling-fan"; + sensor-id = <0x7052107>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt b/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt deleted file mode 100644 index 5dc5d2e2573d..000000000000 --- a/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt +++ /dev/null @@ -1,25 +0,0 @@ -Device-tree bindings for I2C-based On-Chip Controller hwmon device ------------------------------------------------------------------- - -Required properties: - - compatible = "ibm,p8-occ-hwmon"; - - reg = <I2C address>; : I2C bus address - -Examples: - - i2c-bus@100 { - #address-cells = <1>; - #size-cells = <0>; - clock-frequency = <100000>; - < more properties > - - occ-hwmon@1 { - compatible = "ibm,p8-occ-hwmon"; - reg = <0x50>; - }; - - occ-hwmon@2 { - compatible = "ibm,p8-occ-hwmon"; - reg = <0x51>; - }; - }; diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt deleted file mode 100644 index f93242be60a1..000000000000 --- a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt +++ /dev/null @@ -1,23 +0,0 @@ -IBM POWERNV platform sensors ----------------------------- - -Required node properties: -- compatible: must be one of - "ibm,opal-sensor-cooling-fan" - "ibm,opal-sensor-amb-temp" - "ibm,opal-sensor-power-supply" - "ibm,opal-sensor-power" -- sensor-id: an opaque id provided by the firmware to the kernel, identifies a - given sensor and its attribute data - -Example sensors node: - -cooling-fan#8-data { - sensor-id = <0x7052107>; - compatible = "ibm,opal-sensor-cooling-fan"; -}; - -amb-temp#1-thrs { - sensor-id = <0x5096000>; - compatible = "ibm,opal-sensor-amb-temp"; -}; diff --git a/Documentation/devicetree/bindings/hwmon/lm87.txt b/Documentation/devicetree/bindings/hwmon/lm87.txt deleted file mode 100644 index 758ff398b67b..000000000000 --- a/Documentation/devicetree/bindings/hwmon/lm87.txt +++ /dev/null @@ -1,30 +0,0 @@ -*LM87 hwmon sensor. - -Required properties: -- compatible: Should be - "ti,lm87" - -- reg: I2C address - -optional properties: -- has-temp3: This configures pins 18 and 19 to be used as a second - remote temperature sensing channel. By default the pins - are configured as voltage input pins in0 and in5. - -- has-in6: When set, pin 5 is configured to be used as voltage input - in6. Otherwise the pin is set as FAN1 input. - -- has-in7: When set, pin 6 is configured to be used as voltage input - in7. Otherwise the pin is set as FAN2 input. - -- vcc-supply: a Phandle for the regulator supplying power, can be - configured to measure 5.0V power supply. Default is 3.3V. - -Example: - -lm87@2e { - compatible = "ti,lm87"; - reg = <0x2e>; - has-temp3; - vcc-supply = <®_5v0>; -}; diff --git a/Documentation/devicetree/bindings/hwmon/max6650.txt b/Documentation/devicetree/bindings/hwmon/max6650.txt deleted file mode 100644 index f6bd87d8e284..000000000000 --- a/Documentation/devicetree/bindings/hwmon/max6650.txt +++ /dev/null @@ -1,28 +0,0 @@ -Bindings for MAX6651 and MAX6650 I2C fan controllers - -Reference: -[1] https://datasheets.maximintegrated.com/en/ds/MAX6650-MAX6651.pdf - -Required properties: -- compatible : One of "maxim,max6650" or "maxim,max6651" -- reg : I2C address, one of 0x1b, 0x1f, 0x4b, 0x48. - -Optional properties, default is to retain the chip's current setting: -- maxim,fan-microvolt : The supply voltage of the fan, either 5000000 uV or - 12000000 uV. -- maxim,fan-prescale : Pre-scaling value, as per datasheet [1]. Lower values - allow more fine-grained control of slower fans. - Valid: 1, 2, 4, 8, 16. -- maxim,fan-target-rpm: Initial requested fan rotation speed. If specified, the - driver selects closed-loop mode and the requested speed. - This ensures the fan is already running before userspace - takes over. - -Example: - fan-max6650: max6650@1b { - reg = <0x1b>; - compatible = "maxim,max6650"; - maxim,fan-microvolt = <12000000>; - maxim,fan-prescale = <4>; - maxim,fan-target-rpm = <1200>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml new file mode 100644 index 000000000000..2c26104a5e16 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/hwmon/maxim,max6650.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX6650 and MAX6651 I2C Fan Controllers + +maintainers: + - Javier Carrasco <javier.carrasco.cruz@gmail.com> + +description: | + The MAX6650 and MAX6651 regulate and monitor the speed + of 5VDC/12VDC burshless fans with built-in tachometers. + + Datasheets: + https://datasheets.maximintegrated.com/en/ds/MAX6650-MAX6651.pdf + +properties: + compatible: + enum: + - maxim,max6650 + - maxim,max6651 + + reg: + maxItems: 1 + + maxim,fan-microvolt: + description: + The supply voltage of the fan, either 5000000 uV or + 12000000 uV. + enum: [5000000, 12000000] + + maxim,fan-prescale: + description: + Pre-scaling value, as per datasheet. Lower values + allow more fine-grained control of slower fans. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8, 16] + + maxim,fan-target-rpm: + description: + Initial requested fan rotation speed. If specified, the + driver selects closed-loop mode and the requested speed. + This ensures the fan is already running before userspace + takes over. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 30000 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + fan-controller@1b { + compatible = "maxim,max6650"; + reg = <0x1b>; + maxim,fan-microvolt = <12000000>; + maxim,fan-prescale = <4>; + maxim,fan-target-rpm = <1200>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,adp1050.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,adp1050.yaml new file mode 100644 index 000000000000..10c2204bc3df --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,adp1050.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/pmbus/adi,adp1050.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADP1050 digital controller with PMBus interface + +maintainers: + - Radu Sabau <radu.sabau@analog.com> + +description: | + The ADP1050 is used to monitor system voltages, currents and temperatures. + Through the PMBus interface, the ADP1050 targets isolated power supplies + and has four individual monitors for input/output voltage, input current + and temperature. + Datasheet: + https://www.analog.com/en/products/adp1050.html + +properties: + compatible: + const: adi,adp1050 + + reg: + maxItems: 1 + + vcc-supply: true + +required: + - compatible + - reg + - vcc-supply + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + clock-frequency = <100000>; + + hwmon@70 { + compatible = "adi,adp1050"; + reg = <0x70>; + vcc-supply = <&vcc>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt deleted file mode 100644 index 48886f0ce415..000000000000 --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt +++ /dev/null @@ -1 +0,0 @@ -This file has moved to pwm-fan.yaml. diff --git a/Documentation/devicetree/bindings/hwmon/st,stts751.yaml b/Documentation/devicetree/bindings/hwmon/st,stts751.yaml new file mode 100644 index 000000000000..9c825adbed58 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/st,stts751.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/st,stts751.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STTS751 Thermometer + +maintainers: + - Javier Carrasco <javier.carrasco.cruz@gmail.com> + +properties: + compatible: + const: st,stts751 + + reg: + maxItems: 1 + + smbus-timeout-disable: + description: + When set, the smbus timeout function will be disabled. + $ref: /schemas/types.yaml#/definitions/flag + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + thermometer@48 { + compatible = "st,stts751"; + reg = <0x48>; + smbus-timeout-disable; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/stts751.txt b/Documentation/devicetree/bindings/hwmon/stts751.txt deleted file mode 100644 index 3ee1dc30e72f..000000000000 --- a/Documentation/devicetree/bindings/hwmon/stts751.txt +++ /dev/null @@ -1,15 +0,0 @@ -* STTS751 thermometer. - -Required node properties: -- compatible: "stts751" -- reg: I2C bus address of the device - -Optional properties: -- smbus-timeout-disable: when set, the smbus timeout function will be disabled - -Example stts751 node: - -temp-sensor { - compatible = "stts751"; - reg = <0x48>; -} diff --git a/Documentation/devicetree/bindings/hwmon/syna,as370.yaml b/Documentation/devicetree/bindings/hwmon/syna,as370.yaml new file mode 100644 index 000000000000..1f7005f55247 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/syna,as370.yaml @@ -0,0 +1,32 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/syna,as370.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synaptics AS370 PVT sensors + +maintainers: + - Javier Carrasco <javier.carrasco.cruz@gmail.com> + +properties: + compatible: + const: syna,as370-hwmon + + reg: + description: + Address and length of the register set. + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + sensor@ea0810 { + compatible = "syna,as370-hwmon"; + reg = <0xea0810 0xc>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml b/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml new file mode 100644 index 000000000000..a32035409cee --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/hwmon/ti,adc128d818.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments ADC128D818 ADC System Monitor With Temperature Sensor + +maintainers: + - Javier Carrasco <javier.carrasco.cruz@gmail.com> + +description: | + The ADC128D818 is a 12-Bit, 8-Channel Analog to Digital Converter (ADC) + with a temperature sensor and an I2C interface. + + Datasheets: + https://www.ti.com/product/ADC128D818 + +properties: + compatible: + const: ti,adc128d818 + + reg: + maxItems: 1 + + ti,mode: + $ref: /schemas/types.yaml#/definitions/uint8 + description: | + Operation mode. + Mode 0 - 7 single-ended voltage readings (IN0-IN6), 1 temperature + reading (internal). + Mode 1 - 8 single-ended voltage readings (IN0-IN7), no temperature. + Mode 2 - 4 pseudo-differential voltage readings + (IN0-IN1, IN3-IN2, IN4-IN5, IN7-IN6), 1 temperature reading (internal). + Mode 3 - 4 single-ended voltage readings (IN0-IN3), 2 pseudo-differential + voltage readings (IN4-IN5, IN7-IN6), 1 temperature reading (internal). + default: 0 + + vref-supply: + description: + The regulator to use as an external reference. If it does not exist, the + internal reference will be used. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + adc@1d { + compatible = "ti,adc128d818"; + reg = <0x1d>; + vref-supply = <&vref>; + ti,mode = /bits/ 8 <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml b/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml new file mode 100644 index 000000000000..f553235a7321 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/hwmon/ti,lm87.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments LM87 Hardware Monitor + +maintainers: + - Javier Carrasco <javier.carrasco.cruz@gmail.com> + +description: | + The LM87 is a serial interface system hardware monitor + with remote diode temperature sensing. + + Datasheets: + https://www.ti.com/product/LM87 + +properties: + compatible: + const: ti,lm87 + + reg: + maxItems: 1 + + has-temp3: + $ref: /schemas/types.yaml#/definitions/flag + description: + This configures pins 18 and 19 to be used as a second + remote temperature sensing channel. By default the pins + are configured as voltage input pins in0 and in5. + + has-in6: + $ref: /schemas/types.yaml#/definitions/flag + description: + When set, pin 5 is configured to be used as voltage input + in6. Otherwise the pin is set as FAN1 input. + + has-in7: + $ref: /schemas/types.yaml#/definitions/flag + description: + When set, pin 6 is configured to be used as voltage input + in7. Otherwise the pin is set as FAN2 input. + + vcc-supply: + description: + Regulator supplying power, can be configured to measure + 5.0V power supply. Default is 3.3V. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + hwmon@2e { + compatible = "ti,lm87"; + reg = <0x2e>; + has-temp3; + vcc-supply = <®_5v0>; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml index 1b31b87c1800..8fd8be76875e 100644 --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml @@ -127,6 +127,10 @@ properties: wakeup-source: true + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml index 995cbf8cefc6..ec34c48d4878 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml @@ -93,6 +93,10 @@ properties: '#size-cells': const: 0 + access-controllers: + minItems: 1 + maxItems: 2 + allOf: - if: properties: diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index 1970503389aa..c1b1324fa132 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml @@ -59,6 +59,10 @@ properties: If not, SPI CLKOUT frequency will not be accurate. maximum: 20000000 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml index 04045b932bd2..b15de4eb209c 100644 --- a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml +++ b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml @@ -45,6 +45,10 @@ properties: '#size-cells': const: 0 + access-controllers: + minItems: 1 + maxItems: 2 + additionalProperties: false required: diff --git a/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml b/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml index c13c10c8d65d..eed0df9d3a23 100644 --- a/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml +++ b/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml @@ -42,7 +42,7 @@ allOf: properties: compatible: contains: - const: maxim,max30100 + const: maxim,max30102 then: properties: maxim,green-led-current-microamp: false diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml new file mode 100644 index 000000000000..190a6499c932 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml @@ -0,0 +1,172 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/riscv,aplic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RISC-V Advanced Platform Level Interrupt Controller (APLIC) + +maintainers: + - Anup Patel <anup@brainfault.org> + +description: + The RISC-V advanced interrupt architecture (AIA) defines an advanced + platform level interrupt controller (APLIC) for handling wired interrupts + in a RISC-V platform. The RISC-V AIA specification can be found at + https://github.com/riscv/riscv-aia. + + The RISC-V APLIC is implemented as hierarchical APLIC domains where all + interrupt sources connect to the root APLIC domain and a parent APLIC + domain can delegate interrupt sources to it's child APLIC domains. There + is one device tree node for each APLIC domain. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + items: + - enum: + - qemu,aplic + - const: riscv,aplic + + reg: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + interrupts-extended: + minItems: 1 + maxItems: 16384 + description: + Given APLIC domain directly injects external interrupts to a set of + RISC-V HARTS (or CPUs). Each node pointed to should be a riscv,cpu-intc + node, which has a CPU node (i.e. RISC-V HART) as parent. + + msi-parent: + description: + Given APLIC domain forwards wired interrupts as MSIs to a AIA incoming + message signaled interrupt controller (IMSIC). If both "msi-parent" and + "interrupts-extended" properties are present then it means the APLIC + domain supports both MSI mode and Direct mode in HW. In this case, the + APLIC driver has to choose between MSI mode or Direct mode. + + riscv,num-sources: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 1023 + description: + Specifies the number of wired interrupt sources supported by this + APLIC domain. + + riscv,children: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 1024 + items: + maxItems: 1 + description: + A list of child APLIC domains for the given APLIC domain. Each child + APLIC domain is assigned a child index in increasing order, with the + first child APLIC domain assigned child index 0. The APLIC domain child + index is used by firmware to delegate interrupts from the given APLIC + domain to a particular child APLIC domain. + + riscv,delegation: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 1024 + items: + items: + - description: child APLIC domain phandle + - description: first interrupt number of the parent APLIC domain (inclusive) + - description: last interrupt number of the parent APLIC domain (inclusive) + description: + A interrupt delegation list where each entry is a triple consisting + of child APLIC domain phandle, first interrupt number of the parent + APLIC domain, and last interrupt number of the parent APLIC domain. + Firmware must configure interrupt delegation registers based on + interrupt delegation list. + +dependencies: + riscv,delegation: [ "riscv,children" ] + +required: + - compatible + - reg + - interrupt-controller + - "#interrupt-cells" + - riscv,num-sources + +anyOf: + - required: + - interrupts-extended + - required: + - msi-parent + +unevaluatedProperties: false + +examples: + - | + // Example 1 (APLIC domains directly injecting interrupt to HARTs): + + interrupt-controller@c000000 { + compatible = "qemu,aplic", "riscv,aplic"; + interrupts-extended = <&cpu1_intc 11>, + <&cpu2_intc 11>, + <&cpu3_intc 11>, + <&cpu4_intc 11>; + reg = <0xc000000 0x4080>; + interrupt-controller; + #interrupt-cells = <2>; + riscv,num-sources = <63>; + riscv,children = <&aplic1>, <&aplic2>; + riscv,delegation = <&aplic1 1 63>; + }; + + aplic1: interrupt-controller@d000000 { + compatible = "qemu,aplic", "riscv,aplic"; + interrupts-extended = <&cpu1_intc 9>, + <&cpu2_intc 9>; + reg = <0xd000000 0x4080>; + interrupt-controller; + #interrupt-cells = <2>; + riscv,num-sources = <63>; + }; + + aplic2: interrupt-controller@e000000 { + compatible = "qemu,aplic", "riscv,aplic"; + interrupts-extended = <&cpu3_intc 9>, + <&cpu4_intc 9>; + reg = <0xe000000 0x4080>; + interrupt-controller; + #interrupt-cells = <2>; + riscv,num-sources = <63>; + }; + + - | + // Example 2 (APLIC domains forwarding interrupts as MSIs): + + interrupt-controller@c000000 { + compatible = "qemu,aplic", "riscv,aplic"; + msi-parent = <&imsic_mlevel>; + reg = <0xc000000 0x4000>; + interrupt-controller; + #interrupt-cells = <2>; + riscv,num-sources = <63>; + riscv,children = <&aplic3>; + riscv,delegation = <&aplic3 1 63>; + }; + + aplic3: interrupt-controller@d000000 { + compatible = "qemu,aplic", "riscv,aplic"; + msi-parent = <&imsic_slevel>; + reg = <0xd000000 0x4000>; + interrupt-controller; + #interrupt-cells = <2>; + riscv,num-sources = <63>; + }; +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml new file mode 100644 index 000000000000..84976f17a4a1 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml @@ -0,0 +1,172 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/riscv,imsics.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RISC-V Incoming MSI Controller (IMSIC) + +maintainers: + - Anup Patel <anup@brainfault.org> + +description: | + The RISC-V advanced interrupt architecture (AIA) defines a per-CPU incoming + MSI controller (IMSIC) for handling MSIs in a RISC-V platform. The RISC-V + AIA specification can be found at https://github.com/riscv/riscv-aia. + + The IMSIC is a per-CPU (or per-HART) device with separate interrupt file + for each privilege level (machine or supervisor). The configuration of + a IMSIC interrupt file is done using AIA CSRs and it also has a 4KB MMIO + space to receive MSIs from devices. Each IMSIC interrupt file supports a + fixed number of interrupt identities (to distinguish MSIs from devices) + which is same for given privilege level across CPUs (or HARTs). + + The device tree of a RISC-V platform will have one IMSIC device tree node + for each privilege level (machine or supervisor) which collectively describe + IMSIC interrupt files at that privilege level across CPUs (or HARTs). + + The arrangement of IMSIC interrupt files in MMIO space of a RISC-V platform + follows a particular scheme defined by the RISC-V AIA specification. A IMSIC + group is a set of IMSIC interrupt files co-located in MMIO space and we can + have multiple IMSIC groups (i.e. clusters, sockets, chiplets, etc) in a + RISC-V platform. The MSI target address of a IMSIC interrupt file at given + privilege level (machine or supervisor) encodes group index, HART index, + and guest index (shown below). + + XLEN-1 > (HART Index MSB) 12 0 + | | | | + ------------------------------------------------------------- + |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index| 0 | + ------------------------------------------------------------- + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + - $ref: /schemas/interrupt-controller/msi-controller.yaml# + +properties: + compatible: + items: + - enum: + - qemu,imsics + - const: riscv,imsics + + reg: + minItems: 1 + maxItems: 16384 + description: + Base address of each IMSIC group. + + interrupt-controller: true + + "#interrupt-cells": + const: 0 + + msi-controller: true + + "#msi-cells": + const: 0 + + interrupts-extended: + minItems: 1 + maxItems: 16384 + description: + This property represents the set of CPUs (or HARTs) for which given + device tree node describes the IMSIC interrupt files. Each node pointed + to should be a riscv,cpu-intc node, which has a CPU node (i.e. RISC-V + HART) as parent. + + riscv,num-ids: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 63 + maximum: 2047 + description: + Number of interrupt identities supported by IMSIC interrupt file. + + riscv,num-guest-ids: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 63 + maximum: 2047 + description: + Number of interrupt identities are supported by IMSIC guest interrupt + file. When not specified it is assumed to be same as specified by the + riscv,num-ids property. + + riscv,guest-index-bits: + minimum: 0 + maximum: 7 + default: 0 + description: + Number of guest index bits in the MSI target address. + + riscv,hart-index-bits: + minimum: 0 + maximum: 15 + description: + Number of HART index bits in the MSI target address. When not + specified it is calculated based on the interrupts-extended property. + + riscv,group-index-bits: + minimum: 0 + maximum: 7 + default: 0 + description: + Number of group index bits in the MSI target address. + + riscv,group-index-shift: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 55 + default: 24 + description: + The least significant bit position of the group index bits in the + MSI target address. + +required: + - compatible + - reg + - interrupt-controller + - msi-controller + - "#msi-cells" + - interrupts-extended + - riscv,num-ids + +unevaluatedProperties: false + +examples: + - | + // Example 1 (Machine-level IMSIC files with just one group): + + interrupt-controller@24000000 { + compatible = "qemu,imsics", "riscv,imsics"; + interrupts-extended = <&cpu1_intc 11>, + <&cpu2_intc 11>, + <&cpu3_intc 11>, + <&cpu4_intc 11>; + reg = <0x28000000 0x4000>; + interrupt-controller; + #interrupt-cells = <0>; + msi-controller; + #msi-cells = <0>; + riscv,num-ids = <127>; + }; + + - | + // Example 2 (Supervisor-level IMSIC files with two groups): + + interrupt-controller@28000000 { + compatible = "qemu,imsics", "riscv,imsics"; + interrupts-extended = <&cpu1_intc 9>, + <&cpu2_intc 9>, + <&cpu3_intc 9>, + <&cpu4_intc 9>; + reg = <0x28000000 0x2000>, /* Group0 IMSICs */ + <0x29000000 0x2000>; /* Group1 IMSICs */ + interrupt-controller; + #interrupt-cells = <0>; + msi-controller; + #msi-cells = <0>; + riscv,num-ids = <127>; + riscv,group-index-bits = <1>; + riscv,group-index-shift = <24>; + }; +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml index 00c10a8258f1..9967e57b449b 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml @@ -89,8 +89,23 @@ examples: reg = <0x5000d000 0x400>; }; + - | //Example 2 - exti2: interrupt-controller@40013c00 { + #include <dt-bindings/interrupt-controller/arm-gic.h> + exti2: interrupt-controller@5000d000 { + compatible = "st,stm32mp1-exti", "syscon"; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0x5000d000 0x400>; + interrupts-extended = + <&intc GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <0>, + <&intc GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>; + }; + + - | + //Example 3 + exti3: interrupt-controller@40013c00 { compatible = "st,stm32-exti"; interrupt-controller; #interrupt-cells = <2>; diff --git a/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml index 2314a9a14650..1d930d9e10fd 100644 --- a/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml +++ b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml @@ -29,6 +29,10 @@ properties: - const: cec - const: hdmi-cec + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml index 6b3e413cedb2..34147127192f 100644 --- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml @@ -36,6 +36,10 @@ properties: resets: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml index b8611bc8756c..73726c65cfb9 100644 --- a/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml +++ b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml @@ -30,6 +30,10 @@ properties: clocks: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml new file mode 100644 index 000000000000..c0e47055f28c --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/samsung,s5pv210-dmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5Pv210 SoC Dynamic Memory Controller + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +description: + Dynamic Memory Controller interfaces external JEDEC DDR-type SDRAM. + +properties: + compatible: + const: samsung,s5pv210-dmc + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + memory-controller@f0000000 { + compatible = "samsung,s5pv210-dmc"; + reg = <0xf0000000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml index 84ac6f50a6fc..706e45eb4d27 100644 --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml @@ -50,6 +50,10 @@ properties: Reflects the memory layout with four integer values per bank. Format: <bank-number> 0 <address of the bank> <size> + access-controllers: + minItems: 1 + maxItems: 2 + patternProperties: "^.*@[0-4],[a-f0-9]+$": additionalProperties: true diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml index 27329c5dc38e..d41308856408 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml @@ -44,6 +44,10 @@ properties: wakeup-source: true + access-controllers: + minItems: 1 + maxItems: 2 + pwm: type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml index f84e09a5743b..b0e438ff4950 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml @@ -67,6 +67,10 @@ properties: "#size-cells": const: 0 + access-controllers: + minItems: 1 + maxItems: 2 + pwm: type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml index 06f1779835a1..b8e8db0d58e9 100644 --- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml @@ -83,6 +83,7 @@ allOf: enum: - x-powers,axp313a - x-powers,axp15060 + - x-powers,axp717 then: properties: @@ -99,6 +100,7 @@ properties: - x-powers,axp221 - x-powers,axp223 - x-powers,axp313a + - x-powers,axp717 - x-powers,axp803 - x-powers,axp806 - x-powers,axp809 diff --git a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml index 940b12688167..8f62e2c7fa64 100644 --- a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml +++ b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml @@ -79,6 +79,10 @@ properties: - const: rx - const: tx + access-controllers: + minItems: 1 + maxItems: 2 + power-domains: true resets: diff --git a/Documentation/devicetree/bindings/net/airoha,en8811h.yaml b/Documentation/devicetree/bindings/net/airoha,en8811h.yaml new file mode 100644 index 000000000000..ecb5149ec6b0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/airoha,en8811h.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/airoha,en8811h.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Airoha EN8811H PHY + +maintainers: + - Eric Woudstra <ericwouds@gmail.com> + +description: + The Airoha EN8811H PHY has the ability to reverse polarity + on the lines to and/or from the MAC. It is reversed by + the booleans in the devicetree node of the phy. + +allOf: + - $ref: ethernet-phy.yaml# + +properties: + compatible: + enum: + - ethernet-phy-id03a2.a411 + + reg: + maxItems: 1 + + airoha,pnswap-rx: + type: boolean + description: + Reverse rx polarity of the SERDES. This is the receiving + side of the lines from the MAC towards the EN881H. + + airoha,pnswap-tx: + type: boolean + description: + Reverse tx polarity of SERDES. This is the transmitting + side of the lines from EN8811H towards the MAC. + +required: + - reg + +unevaluatedProperties: false + +examples: + - | + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@1 { + compatible = "ethernet-phy-id03a2.a411"; + reg = <1>; + airoha,pnswap-rx; + }; + }; diff --git a/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7921s-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7921s-bluetooth.yaml new file mode 100644 index 000000000000..67ff7caad599 --- /dev/null +++ b/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7921s-bluetooth.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/bluetooth/mediatek,mt7921s-bluetooth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek MT7921S Bluetooth + +maintainers: + - Sean Wang <sean.wang@mediatek.com> + +description: + MT7921S is an SDIO-attached dual-radio WiFi+Bluetooth Combo chip; each + function is its own SDIO function on a shared SDIO interface. The chip + has two dedicated reset lines, one for each function core. + This binding only covers the Bluetooth SDIO function, with one device + node describing only this SDIO function. + +allOf: + - $ref: bluetooth-controller.yaml# + +properties: + compatible: + enum: + - mediatek,mt7921s-bluetooth + + reg: + const: 2 + + reset-gpios: + maxItems: 1 + description: + An active-low reset line for the Bluetooth core; on typical M.2 + key E modules this is the W_DISABLE2# pin. + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + mmc { + #address-cells = <1>; + #size-cells = <0>; + + bluetooth@2 { + compatible = "mediatek,mt7921s-bluetooth"; + reg = <2>; + reset-gpios = <&pio 8 GPIO_ACTIVE_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml index cc70b00c6ce5..4a1bfc2b3584 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml @@ -14,20 +14,25 @@ description: properties: compatible: - enum: - - brcm,bcm20702a1 - - brcm,bcm4329-bt - - brcm,bcm4330-bt - - brcm,bcm4334-bt - - brcm,bcm43430a0-bt - - brcm,bcm43430a1-bt - - brcm,bcm43438-bt - - brcm,bcm4345c5 - - brcm,bcm43540-bt - - brcm,bcm4335a0 - - brcm,bcm4349-bt - - cypress,cyw4373a0-bt - - infineon,cyw55572-bt + oneOf: + - items: + - enum: + - infineon,cyw43439-bt + - const: brcm,bcm4329-bt + - enum: + - brcm,bcm20702a1 + - brcm,bcm4329-bt + - brcm,bcm4330-bt + - brcm,bcm4334-bt + - brcm,bcm43430a0-bt + - brcm,bcm43430a1-bt + - brcm,bcm43438-bt + - brcm,bcm4345c5 + - brcm,bcm43540-bt + - brcm,bcm4335a0 + - brcm,bcm4349-bt + - cypress,cyw4373a0-bt + - infineon,cyw55572-bt shutdown-gpios: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index f9ffb963d6b1..c4887522e8fe 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -118,6 +118,10 @@ properties: phys: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml index e74502a0afe8..3202dc7967c5 100644 --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml @@ -337,8 +337,8 @@ allOf: minItems: 4 clocks: - minItems: 34 - maxItems: 34 + minItems: 24 + maxItems: 24 clock-names: items: @@ -351,18 +351,6 @@ allOf: - const: ethwarp_wocpu1 - const: ethwarp_wocpu0 - const: esw - - const: netsys0 - - const: netsys1 - - const: sgmii_tx250m - - const: sgmii_rx250m - - const: sgmii2_tx250m - - const: sgmii2_rx250m - - const: top_usxgmii0_sel - - const: top_usxgmii1_sel - - const: top_sgm0_sel - - const: top_sgm1_sel - - const: top_xfi_phy0_xtal_sel - - const: top_xfi_phy1_xtal_sel - const: top_eth_gmii_sel - const: top_eth_refck_50m_sel - const: top_eth_sys_200m_sel @@ -375,16 +363,10 @@ allOf: - const: top_netsys_sync_250m_sel - const: top_netsys_ppefb_250m_sel - const: top_netsys_warp_sel - - const: wocpu1 - - const: wocpu0 - const: xgp1 - const: xgp2 - const: xgp3 - mediatek,sgmiisys: - minItems: 2 - maxItems: 2 - patternProperties: "^mac@[0-1]$": type: object diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml index 4c01cae7c93a..87bc4416eadf 100644 --- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -66,6 +66,10 @@ properties: Should be phandle/offset pair. The phandle to the syscon node which encompases the GPR register, and the offset of the GPR register. + nvmem-cells: true + + nvmem-cell-names: true + snps,rmii_refclk_ext: $ref: /schemas/types.yaml#/definitions/flag description: diff --git a/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml new file mode 100644 index 000000000000..828439398fdf --- /dev/null +++ b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml @@ -0,0 +1,169 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/pse-pd/microchip,pd692x0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip PD692x0 Power Sourcing Equipment controller + +maintainers: + - Kory Maincent <kory.maincent@bootlin.com> + +allOf: + - $ref: pse-controller.yaml# + +properties: + compatible: + enum: + - microchip,pd69200 + - microchip,pd69210 + - microchip,pd69220 + + reg: + maxItems: 1 + + managers: + type: object + description: + List of the PD69208T4/PD69204T4/PD69208M PSE managers. Each manager + have 4 or 8 physical ports according to the chip version. No need to + specify the SPI chip select as it is automatically detected by the + PD692x0 PSE controller. The PSE managers have to be described from + the lowest chip select to the greatest one, which is the detection + behavior of the PD692x0 PSE controller. The PD692x0 support up to + 12 PSE managers which can expose up to 96 physical ports. All + physical ports available on a manager have to be described in the + incremental order even if they are not used. + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + required: + - "#address-cells" + - "#size-cells" + + patternProperties: + "^manager@0[0-9a-b]$": + type: object + description: + PD69208T4/PD69204T4/PD69208M PSE manager exposing 4 or 8 physical + ports. + + properties: + reg: + description: + Incremental index of the PSE manager starting from 0, ranging + from lowest to highest chip select, up to 11. + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + '^port@[0-7]$': + type: object + required: + - reg + additionalProperties: false + + required: + - reg + - "#address-cells" + - "#size-cells" + +required: + - compatible + - reg + - pse-pis + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-pse@3c { + compatible = "microchip,pd69200"; + reg = <0x3c>; + + managers { + #address-cells = <1>; + #size-cells = <0>; + + manager@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + phys0: port@0 { + reg = <0>; + }; + + phys1: port@1 { + reg = <1>; + }; + + phys2: port@2 { + reg = <2>; + }; + + phys3: port@3 { + reg = <3>; + }; + }; + + manager@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + phys4: port@0 { + reg = <0>; + }; + + phys5: port@1 { + reg = <1>; + }; + + phys6: port@2 { + reg = <2>; + }; + + phys7: port@3 { + reg = <3>; + }; + }; + }; + + pse-pis { + #address-cells = <1>; + #size-cells = <0>; + + pse_pi0: pse-pi@0 { + reg = <0>; + #pse-cells = <0>; + pairset-names = "alternative-a", "alternative-b"; + pairsets = <&phys0>, <&phys1>; + polarity-supported = "MDI", "S"; + vpwr-supply = <&vpwr1>; + }; + pse_pi1: pse-pi@1 { + reg = <1>; + #pse-cells = <0>; + pairset-names = "alternative-a"; + pairsets = <&phys2>; + polarity-supported = "MDI"; + vpwr-supply = <&vpwr2>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml index 2d382faca0e6..a12cda8aa764 100644 --- a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml +++ b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml @@ -13,6 +13,7 @@ description: Binding for the Power Sourcing Equipment (PSE) as defined in the maintainers: - Oleksij Rempel <o.rempel@pengutronix.de> + - Kory Maincent <kory.maincent@bootlin.com> properties: $nodename: @@ -22,11 +23,105 @@ properties: description: Used to uniquely identify a PSE instance within an IC. Will be 0 on PSE nodes with only a single output and at least 1 on nodes - controlling several outputs. + controlling several outputs which are not described in the pse-pis + subnode. This property is deprecated, please use pse-pis instead. enum: [0, 1] -required: - - "#pse-cells" + pse-pis: + type: object + description: + Overview of the PSE PIs provided by the controller. + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + required: + - "#address-cells" + - "#size-cells" + + patternProperties: + "^pse-pi@[0-9a-f]+$": + type: object + description: + PSE PI for power delivery via pairsets, compliant with IEEE + 802.3-2022, Section 145.2.4. Each pairset comprises a positive and + a negative VPSE pair, adhering to the pinout configurations + detailed in the standard. + See Documentation/networking/pse-pd/pse-pi.rst for details. + + properties: + reg: + description: + Address describing the PSE PI index. + maxItems: 1 + + "#pse-cells": + const: 0 + + pairset-names: + $ref: /schemas/types.yaml#/definitions/string-array + description: + Names of the pairsets as per IEEE 802.3-2022, Section 145.2.4. + Each name should correspond to a phandle in the 'pairset' + property pointing to the power supply for that pairset. + minItems: 1 + maxItems: 2 + items: + enum: + - alternative-a + - alternative-b + + pairsets: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + List of phandles, each pointing to the power supply for the + corresponding pairset named in 'pairset-names'. This property + aligns with IEEE 802.3-2022, Section 33.2.3 and 145.2.4. + PSE Pinout Alternatives (as per IEEE 802.3-2022 Table 145\u20133) + |-----------|---------------|---------------|---------------|---------------| + | Conductor | Alternative A | Alternative A | Alternative B | Alternative B | + | | (MDI-X) | (MDI) | (X) | (S) | + |-----------|---------------|---------------|---------------|---------------| + | 1 | Negative VPSE | Positive VPSE | - | - | + | 2 | Negative VPSE | Positive VPSE | - | - | + | 3 | Positive VPSE | Negative VPSE | - | - | + | 4 | - | - | Negative VPSE | Positive VPSE | + | 5 | - | - | Negative VPSE | Positive VPSE | + | 6 | Positive VPSE | Negative VPSE | - | - | + | 7 | - | - | Positive VPSE | Negative VPSE | + | 8 | - | - | Positive VPSE | Negative VPSE | + minItems: 1 + maxItems: 2 + + polarity-supported: + $ref: /schemas/types.yaml#/definitions/string-array + description: + Polarity configuration supported by the PSE PI pairsets. + minItems: 1 + maxItems: 4 + items: + enum: + - MDI-X + - MDI + - X + - S + + vpwr-supply: + description: Regulator power supply for the PSE PI. + + required: + - reg + - "#pse-cells" + +oneOf: + - required: + - "#pse-cells" + - required: + - pse-pis additionalProperties: true diff --git a/Documentation/devicetree/bindings/net/pse-pd/ti,tps23881.yaml b/Documentation/devicetree/bindings/net/pse-pd/ti,tps23881.yaml new file mode 100644 index 000000000000..4147adb11e10 --- /dev/null +++ b/Documentation/devicetree/bindings/net/pse-pd/ti,tps23881.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/pse-pd/ti,tps23881.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI TPS23881 Power Sourcing Equipment controller + +maintainers: + - Kory Maincent <kory.maincent@bootlin.com> + +allOf: + - $ref: pse-controller.yaml# + +properties: + compatible: + enum: + - ti,tps23881 + + reg: + maxItems: 1 + + '#pse-cells': + const: 1 + + channels: + description: each set of 8 ports can be assigned to one physical + channels or two for PoE4. This parameter describes the configuration + of the ports conversion matrix that establishes relationship between + the logical ports and the physical channels. + type: object + + patternProperties: + '^channel@[0-7]$': + type: object + required: + - reg + +unevaluatedProperties: false + +required: + - compatible + - reg + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-pse@20 { + compatible = "ti,tps23881"; + reg = <0x20>; + + channels { + #address-cells = <1>; + #size-cells = <0>; + + phys0: channel@0 { + reg = <0>; + }; + + phys1: channel@1 { + reg = <1>; + }; + + phys2: channel@2 { + reg = <2>; + }; + }; + + pse-pis { + #address-cells = <1>; + #size-cells = <0>; + + pse_pi0: pse-pi@0 { + reg = <0>; + #pse-cells = <0>; + pairset-names = "alternative-a", "alternative-b"; + pairsets = <&phys0>, <&phys1>; + polarity-supported = "MDI", "S"; + vpwr-supply = <&vpwr1>; + }; + + pse_pi1: pse-pi@1 { + reg = <1>; + #pse-cells = <0>; + pairset-names = "alternative-a"; + pairsets = <&phys2>; + polarity-supported = "MDI"; + vpwr-supply = <&vpwr2>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml index 0029e197a825..a94480e819ac 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml @@ -20,6 +20,7 @@ properties: - enum: - qcom,ipq6018-mdio - qcom,ipq8074-mdio + - qcom,ipq9574-mdio - const: qcom,ipq4019-mdio "#address-cells": @@ -76,6 +77,7 @@ allOf: - qcom,ipq5018-mdio - qcom,ipq6018-mdio - qcom,ipq8074-mdio + - qcom,ipq9574-mdio then: required: - clocks diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index de7ba7f345a9..21a92f179093 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -88,10 +88,16 @@ properties: '#address-cells': description: Number of address cells for the MDIO bus. const: 1 + deprecated: true '#size-cells': description: Number of size cells on the MDIO bus. const: 0 + deprecated: true + + mdio: + $ref: /schemas/net/mdio.yaml# + unevaluatedProperties: false renesas,no-ether-link: type: boolean @@ -110,9 +116,13 @@ properties: tx-internal-delay-ps: enum: [0, 2000] +# In older bindings there where no mdio child-node to describe the MDIO bus +# and the PHY. To not fail older bindings accept any node with an address. New +# users should describe the PHY inside the mdio child-node. patternProperties: "@[0-9a-f]$": type: object + deprecated: true required: - compatible @@ -123,8 +133,6 @@ required: - resets - phy-mode - phy-handle - - '#address-cells' - - '#size-cells' allOf: - $ref: ethernet-controller.yaml# diff --git a/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml b/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml index ea35d19be829..b4680a1d0a06 100644 --- a/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml +++ b/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml @@ -71,16 +71,8 @@ properties: enum: [0, 2000] default: 0 - '#address-cells': - const: 1 - - '#size-cells': - const: 0 - -patternProperties: - "^ethernet-phy@[0-9a-f]$": - type: object - $ref: ethernet-phy.yaml# + mdio: + $ref: /schemas/net/mdio.yaml# unevaluatedProperties: false required: @@ -94,8 +86,7 @@ required: - resets - phy-mode - phy-handle - - '#address-cells' - - '#size-cells' + - mdio additionalProperties: false @@ -122,14 +113,18 @@ examples: tx-internal-delay-ps = <2000>; phy-handle = <&phy3>; - #address-cells = <1>; - #size-cells = <0>; + mdio { + #address-cells = <1>; + #size-cells = <0>; - phy3: ethernet-phy@3 { - compatible = "ethernet-phy-ieee802.3-c45"; - reg = <0>; - interrupt-parent = <&gpio4>; - interrupts = <3 IRQ_TYPE_LEVEL_LOW>; reset-gpios = <&gpio1 23 GPIO_ACTIVE_LOW>; + reset-post-delay-us = <4000>; + + phy3: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c45"; + reg = <0>; + interrupt-parent = <&gpio4>; + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; + }; }; }; diff --git a/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml b/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml new file mode 100644 index 000000000000..d9a8d586e260 --- /dev/null +++ b/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/renesas,rzn1-gmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas GMAC + +maintainers: + - Romain Gantois <romain.gantois@bootlin.com> + +select: + properties: + compatible: + contains: + enum: + - renesas,r9a06g032-gmac + - renesas,rzn1-gmac + required: + - compatible + +allOf: + - $ref: snps,dwmac.yaml# + +properties: + compatible: + items: + - enum: + - renesas,r9a06g032-gmac + - const: renesas,rzn1-gmac + - const: snps,dwmac + + pcs-handle: + description: + phandle pointing to a PCS sub-node compatible with + renesas,rzn1-miic.yaml# + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r9a06g032-sysctrl.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + ethernet@44000000 { + compatible = "renesas,r9a06g032-gmac", "renesas,rzn1-gmac", "snps,dwmac"; + reg = <0x44000000 0x2000>; + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq", "eth_wake_irq", "eth_lpi"; + clock-names = "stmmaceth"; + clocks = <&sysctrl R9A06G032_HCLK_GMAC0>; + power-domains = <&sysctrl>; + snps,multicast-filter-bins = <256>; + snps,perfect-filter-entries = <128>; + tx-fifo-depth = <2048>; + rx-fifo-depth = <4096>; + pcs-handle = <&mii_conv1>; + phy-mode = "mii"; + }; + +... diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml index 70bbc4220e2a..6bbe96e35250 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml @@ -137,8 +137,6 @@ examples: assigned-clock-parents = <&ext_gmac>; rockchip,grf = <&grf>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; clock_in_out = "input"; - tx_delay = <0x30>; - rx_delay = <0x10>; }; diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 6b0341a8e0ea..21cc27e75f50 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -242,7 +242,8 @@ properties: type: boolean description: Multicast & Broadcast Packets snps,priority: - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 1 description: Bitmask of the tagged frames priorities assigned to the queue allOf: - if: @@ -327,9 +328,6 @@ properties: snps,tx-sched-dwrr: type: boolean description: Deficit Weighted Round Robin - snps,tx-sched-sp: - type: boolean - description: Strict priority allOf: - if: required: @@ -338,7 +336,6 @@ properties: properties: snps,tx-sched-wfq: false snps,tx-sched-dwrr: false - snps,tx-sched-sp: false - if: required: - snps,tx-sched-wfq @@ -346,7 +343,6 @@ properties: properties: snps,tx-sched-wrr: false snps,tx-sched-dwrr: false - snps,tx-sched-sp: false - if: required: - snps,tx-sched-dwrr @@ -354,15 +350,6 @@ properties: properties: snps,tx-sched-wrr: false snps,tx-sched-wfq: false - snps,tx-sched-sp: false - - if: - required: - - snps,tx-sched-sp - then: - properties: - snps,tx-sched-wrr: false - snps,tx-sched-wfq: false - snps,tx-sched-dwrr: false patternProperties: "^queue[0-9]$": description: Each subnode represents a queue. @@ -393,7 +380,8 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 description: max read outstanding req. limit snps,priority: - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 1 description: Bitmask of the tagged frames priorities assigned to the queue. When a PFC frame is received with priorities matching the bitmask, diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml index 0d1962980f57..313a15331661 100644 --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml @@ -30,6 +30,10 @@ properties: - items: - const: starfive,jh7110-dwmac - const: snps,dwmac-5.20 + - items: + - const: starfive,jh8100-dwmac + - const: starfive,jh7110-dwmac + - const: snps,dwmac-5.20 reg: maxItems: 1 @@ -116,11 +120,25 @@ allOf: minItems: 3 maxItems: 3 - resets: - minItems: 2 - - reset-names: - minItems: 2 + if: + properties: + compatible: + contains: + const: starfive,jh8100-dwmac + then: + properties: + resets: + maxItems: 1 + + reset-names: + const: stmmaceth + else: + properties: + resets: + minItems: 2 + + reset-names: + minItems: 2 unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index fc8c96b08d7d..7ccf75676b6d 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -82,6 +82,13 @@ properties: Should be phandle/offset pair. The phandle to the syscon node which encompases the glue register, and the offset of the control register + st,ext-phyclk: + description: + set this property in RMII mode when you have PHY without crystal 50MHz and want to + select RCC clock instead of ETH_REF_CLK. OR in RGMII mode when you want to select + RCC clock instead of ETH_CLK125. + type: boolean + st,eth-clk-sel: description: set this property in RGMII PHY when you want to select RCC clock instead of ETH_CLK125. @@ -93,6 +100,10 @@ properties: select RCC clock instead of ETH_REF_CLK. type: boolean + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - clocks diff --git a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml index 229c8f32019f..e253fa786092 100644 --- a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml +++ b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml @@ -13,14 +13,12 @@ description: Ethernet based on the Programmable Real-Time Unit and Industrial Communication Subsystem. -allOf: - - $ref: /schemas/remoteproc/ti,pru-consumer.yaml# - properties: compatible: enum: - - ti,am642-icssg-prueth # for AM64x SoC family - - ti,am654-icssg-prueth # for AM65x SoC family + - ti,am642-icssg-prueth # for AM64x SoC family + - ti,am654-icssg-prueth # for AM65x SoC family + - ti,am654-sr1-icssg-prueth # for AM65x SoC family, SR1.0 sram: $ref: /schemas/types.yaml#/definitions/phandle @@ -28,9 +26,11 @@ properties: phandle to MSMC SRAM node dmas: - maxItems: 10 + minItems: 10 + maxItems: 12 dma-names: + minItems: 10 items: - const: tx0-0 - const: tx0-1 @@ -42,6 +42,8 @@ properties: - const: tx1-3 - const: rx0 - const: rx1 + - const: rxmgm0 + - const: rxmgm1 ti,mii-g-rt: $ref: /schemas/types.yaml#/definitions/phandle @@ -132,6 +134,27 @@ required: - interrupts - interrupt-names +allOf: + - $ref: /schemas/remoteproc/ti,pru-consumer.yaml# + + - if: + properties: + compatible: + contains: + const: ti,am654-sr1-icssg-prueth + then: + properties: + dmas: + minItems: 12 + dma-names: + minItems: 12 + else: + properties: + dmas: + maxItems: 10 + dma-names: + maxItems: 10 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml index 4aa521f1be8c..e564f20d8f41 100644 --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml @@ -44,6 +44,7 @@ properties: - brcm,bcm4366-fmac - cypress,cyw4373-fmac - cypress,cyw43012-fmac + - infineon,cyw43439-fmac - const: brcm,bcm4329-fmac - enum: - brcm,bcm4329-fmac diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml index 9b3ef4bc3732..5c4498b762c8 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml @@ -73,6 +73,12 @@ properties: - sky85703-11 - sky85803 + firmware-name: + maxItems: 1 + description: + If present, a board or platform specific string used to lookup firmware + files for the device. + wifi-firmware: type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index 672282cdfc2f..a2d55bf4c7a5 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -59,6 +59,8 @@ properties: minItems: 1 maxItems: 2 + ieee80211-freq-limit: true + wifi-firmware: type: object description: | @@ -88,6 +90,7 @@ required: additionalProperties: false allOf: + - $ref: ieee80211.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml index 51f62c3ae194..ec5e424bb3c8 100644 --- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml +++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml @@ -13,25 +13,25 @@ maintainers: description: | For some SoCs, the CPU frequency subset and voltage value of each OPP varies based on the silicon variant in use. Allwinner Process - Voltage Scaling Tables defines the voltage and frequency value based - on the speedbin blown in the efuse combination. The - sun50i-cpufreq-nvmem driver reads the efuse value from the SoC to - provide the OPP framework with required information. + Voltage Scaling Tables define the voltage and frequency values based + on the speedbin blown in the efuse combination. allOf: - $ref: opp-v2-base.yaml# properties: compatible: - const: allwinner,sun50i-h6-operating-points + enum: + - allwinner,sun50i-h6-operating-points + - allwinner,sun50i-h616-operating-points nvmem-cells: description: | A phandle pointing to a nvmem-cells node representing the efuse - registers that has information about the speedbin that is used + register that has information about the speedbin that is used to select the right frequency/voltage value pair. Please refer - the for nvmem-cells bindings - Documentation/devicetree/bindings/nvmem/nvmem.txt and also + to the nvmem-cells bindings in + Documentation/devicetree/bindings/nvmem/nvmem.yaml and also the examples below. opp-shared: true @@ -47,15 +47,18 @@ patternProperties: properties: opp-hz: true clock-latency-ns: true + opp-microvolt: true + opp-supported-hw: + maxItems: 1 + description: + A single 32 bit bitmap value, representing compatible HW, one + bit per speed bin index. patternProperties: "^opp-microvolt-speed[0-9]$": true required: - opp-hz - - opp-microvolt-speed0 - - opp-microvolt-speed1 - - opp-microvolt-speed2 unevaluatedProperties: false @@ -77,58 +80,54 @@ examples: opp-microvolt-speed2 = <800000>; }; - opp-720000000 { + opp-1080000000 { clock-latency-ns = <244144>; /* 8 32k periods */ - opp-hz = /bits/ 64 <720000000>; + opp-hz = /bits/ 64 <1080000000>; - opp-microvolt-speed0 = <880000>; - opp-microvolt-speed1 = <820000>; - opp-microvolt-speed2 = <800000>; + opp-microvolt-speed0 = <1060000>; + opp-microvolt-speed1 = <880000>; + opp-microvolt-speed2 = <840000>; }; - opp-816000000 { + opp-1488000000 { clock-latency-ns = <244144>; /* 8 32k periods */ - opp-hz = /bits/ 64 <816000000>; + opp-hz = /bits/ 64 <1488000000>; - opp-microvolt-speed0 = <880000>; - opp-microvolt-speed1 = <820000>; - opp-microvolt-speed2 = <800000>; + opp-microvolt-speed0 = <1160000>; + opp-microvolt-speed1 = <1000000>; + opp-microvolt-speed2 = <960000>; }; + }; - opp-888000000 { - clock-latency-ns = <244144>; /* 8 32k periods */ - opp-hz = /bits/ 64 <888000000>; - - opp-microvolt-speed0 = <940000>; - opp-microvolt-speed1 = <820000>; - opp-microvolt-speed2 = <800000>; - }; + - | + opp-table { + compatible = "allwinner,sun50i-h616-operating-points"; + nvmem-cells = <&speedbin_efuse>; + opp-shared; - opp-1080000000 { + opp-480000000 { clock-latency-ns = <244144>; /* 8 32k periods */ - opp-hz = /bits/ 64 <1080000000>; + opp-hz = /bits/ 64 <480000000>; - opp-microvolt-speed0 = <1060000>; - opp-microvolt-speed1 = <880000>; - opp-microvolt-speed2 = <840000>; + opp-microvolt = <900000>; + opp-supported-hw = <0x1f>; }; - opp-1320000000 { + opp-792000000 { clock-latency-ns = <244144>; /* 8 32k periods */ - opp-hz = /bits/ 64 <1320000000>; + opp-hz = /bits/ 64 <792000000>; - opp-microvolt-speed0 = <1160000>; - opp-microvolt-speed1 = <940000>; - opp-microvolt-speed2 = <900000>; + opp-microvolt-speed1 = <900000>; + opp-microvolt-speed4 = <940000>; + opp-supported-hw = <0x12>; }; - opp-1488000000 { + opp-1512000000 { clock-latency-ns = <244144>; /* 8 32k periods */ - opp-hz = /bits/ 64 <1488000000>; + opp-hz = /bits/ 64 <1512000000>; - opp-microvolt-speed0 = <1160000>; - opp-microvolt-speed1 = <1000000>; - opp-microvolt-speed2 = <960000>; + opp-microvolt = <1100000>; + opp-supported-hw = <0x0a>; }; }; diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml index 24a3dbde223b..ceea122ae1a6 100644 --- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml +++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml @@ -55,6 +55,10 @@ properties: description: number of clock cells for ck_usbo_48m consumer const: 0 + access-controllers: + minItems: 1 + maxItems: 2 + # Required child nodes: patternProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index d476de82e5c3..4d5a957fa232 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -120,7 +120,9 @@ additionalProperties: slew-rate: true gpio-hog: true gpios: true + input: true input-enable: true + output-enable: true output-high: true output-low: true line-name: true diff --git a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml index d84268b59784..96cd6f3c3546 100644 --- a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml @@ -25,6 +25,9 @@ properties: - items: - const: microchip,sama7g5-pwm - const: atmel,sama5d2-pwm + - items: + - const: microchip,sam9x7-pwm + - const: microchip,sam9x60-pwm reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml index 3afe1480df52..f7bc84b05a87 100644 --- a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml @@ -35,7 +35,6 @@ properties: required: - compatible - - '#pwm-cells' additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/marvell,pxa-pwm.yaml b/Documentation/devicetree/bindings/pwm/marvell,pxa-pwm.yaml index ba6325575ea0..9ee1946dc2e1 100644 --- a/Documentation/devicetree/bindings/pwm/marvell,pxa-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/marvell,pxa-pwm.yaml @@ -34,7 +34,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - clocks additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml index a5c308801619..d515c09e1021 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml @@ -66,7 +66,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - clocks - clock-names diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml index bc813fe74fab..195e4371196b 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -31,6 +31,7 @@ properties: - mediatek,mt8188-disp-pwm - mediatek,mt8192-disp-pwm - mediatek,mt8195-disp-pwm + - mediatek,mt8365-disp-pwm - const: mediatek,mt8183-disp-pwm reg: @@ -58,7 +59,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - clocks - clock-names diff --git a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml index 15e7fd98defc..9dc25f38fb94 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml @@ -29,7 +29,6 @@ required: - compatible - reg - clocks - - "#pwm-cells" additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml index 4d0b5964443d..7523a89a1773 100644 --- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml +++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml @@ -51,7 +51,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - clocks - clock-names diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml new file mode 100644 index 000000000000..ec6695c8d2e3 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-system-ldos.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner D1 System LDOs + +maintainers: + - Samuel Holland <samuel@sholland.org> + +description: + Allwinner D1 contains a pair of general-purpose LDOs which are designed to + supply power inside and outside the SoC. They are controlled by a register + within the system control MMIO space. + +properties: + compatible: + enum: + - allwinner,sun20i-d1-system-ldos + + reg: + maxItems: 1 + +patternProperties: + "^ldo[ab]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +... diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml index 9ff9abf2691a..51e2f6fb7a5a 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml @@ -41,6 +41,13 @@ allOf: - gpios properties: + $nodename: + anyOf: + - description: Preferred name is 'regulator-[0-9]v[0-9]' + pattern: '^regulator(-[0-9]+v[0-9]+|-[0-9a-z-]+)?$' + - description: Any name allowed + deprecated: true + compatible: enum: - regulator-fixed diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml index 3d469b8e9774..849bfa50bdba 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml @@ -28,6 +28,7 @@ properties: - nxp,pca9450a - nxp,pca9450b - nxp,pca9450c + - nxp,pca9451a reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml index 33ae1f786802..fcefc722ee2a 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml @@ -26,6 +26,7 @@ properties: - enum: - qcom,pm4125-vbus-reg - qcom,pm6150-vbus-reg + - qcom,pm7250b-vbus-reg - qcom,pmi632-vbus-reg - const: qcom,pm8150b-vbus-reg diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml index 05f4ad2c7d3a..6ceaffb45dc9 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml @@ -30,6 +30,10 @@ properties: vdda-supply: description: phandle to the vdda input analog voltage. + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml index 717f6b321f88..340d01d481d1 100644 --- a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml +++ b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml @@ -37,6 +37,10 @@ properties: description: If set, the RNG configuration in RNG_CR, RNG_HTCR and RNG_NSCR will be locked. + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml index 62f97da1b2fd..2ed526139269 100644 --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml @@ -73,6 +73,10 @@ properties: enum: [1, 2, 4, 8, 12, 14, 16] default: 8 + access-controllers: + minItems: 1 + maxItems: 2 + allOf: - $ref: rs485.yaml# - $ref: serial.yaml# diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml index 4310bae6c58e..4512390f90f0 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml @@ -58,20 +58,6 @@ patternProperties: required: - compatible -allOf: - - if: - not: - properties: - compatible: - contains: - enum: - - qcom,sm8450-pmic-glink - - qcom,sm8550-pmic-glink - - qcom,x1e80100-pmic-glink - then: - properties: - orientation-gpios: false - additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml index 74bb92e31554..fd6db0ca98eb 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml @@ -116,8 +116,8 @@ examples: bluetooth { compatible = "qcom,wcnss-bt"; - /* BD address 00:11:22:33:44:55 */ - local-bd-address = [ 55 44 33 22 11 00 ]; + /* Updated by boot firmware (little-endian order) */ + local-bd-address = [ 00 00 00 00 00 00 ]; }; wifi { diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml new file mode 100644 index 000000000000..ebbf0c9109ce --- /dev/null +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/renesas/renesas,r9a09g057-sys.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/V2H(P) System Controller (SYS) + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: | + The RZ/V2H(P) SYS (System Controller) controls the overall + configuration of the LSI and supports the following functions, + - Trust zone control + - Extend access by specific masters to address beyond 4GB space + - GBETH configuration + - Control of settings and states of SRAM/PCIe/CM33/CA55/CR8/xSPI/ADC/TSU + - LSI version + - WDT stop control + - General registers + +properties: + compatible: + const: renesas,r9a09g057-sys + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - resets + +additionalProperties: false + +examples: + - | + sys: system-controller@10430000 { + compatible = "renesas,r9a09g057-sys"; + reg = <0x10430000 0x10000>; + clocks = <&cpg 1>; + resets = <&cpg 1>; + }; diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index c1ce4da2dc32..09d3ce97efa2 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -513,6 +513,14 @@ properties: - renesas,rzv2mevk2 # RZ/V2M Eval Board v2.0 - const: renesas,r9a09g011 + - description: RZ/V2H(P) (R9A09G057) + items: + - enum: + - renesas,r9a09g057h41 # RZ/V2H + - renesas,r9a09g057h42 # RZ/V2H with Mali-G31 support + - renesas,r9a09g057h44 # RZ/V2HP with Mali-G31 + Mali-C55 support + - const: renesas,r9a09g057 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml index c0c6ce8fc786..3ca220582897 100644 --- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml @@ -15,6 +15,7 @@ properties: - items: - enum: - google,gs101-apm-sysreg + - google,gs101-hsi2-sysreg - google,gs101-peric0-sysreg - google,gs101-peric1-sysreg - samsung,exynos3-sysreg @@ -72,6 +73,7 @@ allOf: compatible: contains: enum: + - google,gs101-hsi2-sysreg - google,gs101-peric0-sysreg - google,gs101-peric1-sysreg - samsung,exynos850-cmgp-sysreg diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt b/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt deleted file mode 100644 index 3ffc2562fb31..000000000000 --- a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt +++ /dev/null @@ -1,50 +0,0 @@ -Texas Instruments DaVinci McBSP module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This binding describes the "Multi-channel Buffered Serial Port" (McBSP) -audio interface found in some TI DaVinci processors like the OMAP-L138 or AM180x. - - -Required properties: -~~~~~~~~~~~~~~~~~~~~ -- compatible : - "ti,da850-mcbsp" : for DA850, AM180x and OPAM-L138 platforms - -- reg : physical base address and length of the controller memory mapped - region(s). -- reg-names : Should contain: - * "mpu" for the main registers (required). - * "dat" for the data FIFO (optional). - -- dmas: three element list of DMA controller phandles, DMA request line and - TC channel ordered triplets. -- dma-names: identifier string for each DMA request line in the dmas property. - These strings correspond 1:1 with the ordered pairs in dmas. The dma - identifiers must be "rx" and "tx". - -Optional properties: -~~~~~~~~~~~~~~~~~~~~ -- interrupts : Interrupt numbers for McBSP -- interrupt-names : Known interrupt names are "rx" and "tx" - -- pinctrl-0: Should specify pin control group used for this controller. -- pinctrl-names: Should contain only one value - "default", for more details - please refer to pinctrl-bindings.txt - -Example (AM1808): -~~~~~~~~~~~~~~~~~ - -mcbsp0: mcbsp@1d10000 { - compatible = "ti,da850-mcbsp"; - pinctrl-names = "default"; - pinctrl-0 = <&mcbsp0_pins>; - - reg = <0x00110000 0x1000>, - <0x00310000 0x1000>; - reg-names = "mpu", "dat"; - interrupts = <97 98>; - interrupt-names = "rx", "tx"; - dmas = <&edma0 3 1 - &edma0 2 1>; - dma-names = "tx", "rx"; -}; diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml b/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml new file mode 100644 index 000000000000..4fa677023827 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/davinci-mcbsp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: McBSP Controller for TI SoCs + +maintainers: + - Bastien Curutchet <bastien.curutchet@bootlin.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - ti,da850-mcbsp + + reg: + minItems: 1 + items: + - description: CFG registers + - description: data registers + + reg-names: + minItems: 1 + items: + - const: mpu + - const: dat + + dmas: + items: + - description: transmission DMA channel + - description: reception DMA channel + + dma-names: + items: + - const: tx + - const: rx + + interrupts: + items: + - description: RX interrupt + - description: TX interrupt + + interrupt-names: + items: + - const: rx + - const: tx + + clocks: + minItems: 1 + items: + - description: functional clock + - description: external input clock for sample rate generator. + + clock-names: + minItems: 1 + items: + - const: fck + - const: clks + + power-domains: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + ti,T1-framing-tx: + $ref: /schemas/types.yaml#/definitions/flag + description: + If the property is present, tx data delay is set to 2 bit clock periods. + McBSP will insert a blank period (high-impedance period) before the first + data bit. This can be used to interface to T1-framing devices. + + ti,T1-framing-rx: + $ref: /schemas/types.yaml#/definitions/flag + description: + If the property is present, rx data delay is set to 2 bit clock periods. + McBSP will discard the bit preceding the data stream (called framing bit). + This can be used to interface to T1-framing devices. + +required: + - "#sound-dai-cells" + - compatible + - reg + - reg-names + - dmas + - dma-names + - clocks + +unevaluatedProperties: false + +examples: + - | + mcbsp0@1d10000 { + #sound-dai-cells = <0>; + compatible = "ti,da850-mcbsp"; + pinctrl-names = "default"; + pinctrl-0 = <&mcbsp0_pins>; + + reg = <0x111000 0x1000>, + <0x311000 0x1000>; + reg-names = "mpu", "dat"; + interrupts = <97>, <98>; + interrupt-names = "rx", "tx"; + dmas = <&edma0 3 1>, + <&edma0 2 1>; + dma-names = "tx", "rx"; + + clocks = <&psc1 14>; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl,audmix.txt b/Documentation/devicetree/bindings/sound/fsl,audmix.txt deleted file mode 100644 index 840b7e0d6a63..000000000000 --- a/Documentation/devicetree/bindings/sound/fsl,audmix.txt +++ /dev/null @@ -1,50 +0,0 @@ -NXP Audio Mixer (AUDMIX). - -The Audio Mixer is a on-chip functional module that allows mixing of two -audio streams into a single audio stream. Audio Mixer has two input serial -audio interfaces. These are driven by two Synchronous Audio interface -modules (SAI). Each input serial interface carries 8 audio channels in its -frame in TDM manner. Mixer mixes audio samples of corresponding channels -from two interfaces into a single sample. Before mixing, audio samples of -two inputs can be attenuated based on configuration. The output of the -Audio Mixer is also a serial audio interface. Like input interfaces it has -the same TDM frame format. This output is used to drive the serial DAC TDM -interface of audio codec and also sent to the external pins along with the -receive path of normal audio SAI module for readback by the CPU. - -The output of Audio Mixer can be selected from any of the three streams - - serial audio input 1 - - serial audio input 2 - - mixed audio - -Mixing operation is independent of audio sample rate but the two audio -input streams must have same audio sample rate with same number of channels -in TDM frame to be eligible for mixing. - -Device driver required properties: -================================= - - compatible : Compatible list, contains "fsl,imx8qm-audmix" - - - reg : Offset and length of the register set for the device. - - - clocks : Must contain an entry for each entry in clock-names. - - - clock-names : Must include the "ipg" for register access. - - - power-domains : Must contain the phandle to AUDMIX power domain node - - - dais : Must contain a list of phandles to AUDMIX connected - DAIs. The current implementation requires two phandles - to SAI interfaces to be provided, the first SAI in the - list being used to route the AUDMIX output. - -Device driver configuration example: -====================================== - audmix: audmix@59840000 { - compatible = "fsl,imx8qm-audmix"; - reg = <0x0 0x59840000 0x0 0x10000>; - clocks = <&clk IMX8QXP_AUD_AUDMIX_IPG>; - clock-names = "ipg"; - power-domains = <&pd_audmix>; - dais = <&sai4>, <&sai5>; - }; diff --git a/Documentation/devicetree/bindings/sound/fsl,audmix.yaml b/Documentation/devicetree/bindings/sound/fsl,audmix.yaml new file mode 100644 index 000000000000..9413b901cf77 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,audmix.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,audmix.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Audio Mixer (AUDMIX). + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + - Frank Li <Frank.Li@nxp.com> + +description: | + The Audio Mixer is a on-chip functional module that allows mixing of two + audio streams into a single audio stream. Audio Mixer has two input serial + audio interfaces. These are driven by two Synchronous Audio interface + modules (SAI). Each input serial interface carries 8 audio channels in its + frame in TDM manner. Mixer mixes audio samples of corresponding channels + from two interfaces into a single sample. Before mixing, audio samples of + two inputs can be attenuated based on configuration. The output of the + Audio Mixer is also a serial audio interface. Like input interfaces it has + the same TDM frame format. This output is used to drive the serial DAC TDM + interface of audio codec and also sent to the external pins along with the + receive path of normal audio SAI module for readback by the CPU. + + The output of Audio Mixer can be selected from any of the three streams + - serial audio input 1 + - serial audio input 2 + - mixed audio + + Mixing operation is independent of audio sample rate but the two audio + input streams must have same audio sample rate with same number of channels + in TDM frame to be eligible for mixing. + +properties: + compatible: + const: fsl,imx8qm-audmix + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ipg + + power-domains: + maxItems: 1 + + dais: + description: contain a list of phandles to AUDMIX connected DAIs. + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 2 + items: + - description: the AUDMIX output + maxItems: 1 + - description: serial audio input 1 + maxItems: 1 + - description: serial audio input 2 + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + - dais + +unevaluatedProperties: false + +examples: + - | + audmix@59840000 { + compatible = "fsl,imx8qm-audmix"; + reg = <0x59840000 0x10000>; + clocks = <&amix_lpcg 0>; + clock-names = "ipg"; + power-domains = <&pd_audmix>; + dais = <&sai4>, <&sai5>; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt deleted file mode 100644 index 90112ca1ff42..000000000000 --- a/Documentation/devicetree/bindings/sound/fsl,esai.txt +++ /dev/null @@ -1,68 +0,0 @@ -Freescale Enhanced Serial Audio Interface (ESAI) Controller - -The Enhanced Serial Audio Interface (ESAI) provides a full-duplex serial port -for serial communication with a variety of serial devices, including industry -standard codecs, Sony/Phillips Digital Interface (S/PDIF) transceivers, and -other DSPs. It has up to six transmitters and four receivers. - -Required properties: - - - compatible : Compatible list, should contain one of the following - compatibles: - "fsl,imx35-esai", - "fsl,vf610-esai", - "fsl,imx6ull-esai", - "fsl,imx8qm-esai", - - - reg : Offset and length of the register set for the device. - - - interrupts : Contains the spdif interrupt. - - - dmas : Generic dma devicetree binding as described in - Documentation/devicetree/bindings/dma/dma.txt. - - - dma-names : Two dmas have to be defined, "tx" and "rx". - - - clocks : Contains an entry for each entry in clock-names. - - - clock-names : Includes the following entries: - "core" The core clock used to access registers - "extal" The esai baud clock for esai controller used to - derive HCK, SCK and FS. - "fsys" The system clock derived from ahb clock used to - derive HCK, SCK and FS. - "spba" The spba clock is required when ESAI is placed as a - bus slave of the Shared Peripheral Bus and when two - or more bus masters (CPU, DMA or DSP) try to access - it. This property is optional depending on the SoC - design. - - - fsl,fifo-depth : The number of elements in the transmit and receive - FIFOs. This number is the maximum allowed value for - TFCR[TFWM] or RFCR[RFWM]. - - - fsl,esai-synchronous: This is a boolean property. If present, indicating - that ESAI would work in the synchronous mode, which - means all the settings for Receiving would be - duplicated from Transmission related registers. - -Optional properties: - - - big-endian : If this property is absent, the native endian mode - will be in use as default, or the big endian mode - will be in use for all the device registers. - -Example: - -esai: esai@2024000 { - compatible = "fsl,imx35-esai"; - reg = <0x02024000 0x4000>; - interrupts = <0 51 0x04>; - clocks = <&clks 208>, <&clks 118>, <&clks 208>; - clock-names = "core", "extal", "fsys"; - dmas = <&sdma 23 21 0>, <&sdma 24 21 0>; - dma-names = "rx", "tx"; - fsl,fifo-depth = <128>; - fsl,esai-synchronous; - big-endian; -}; diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.yaml b/Documentation/devicetree/bindings/sound/fsl,esai.yaml new file mode 100644 index 000000000000..f99ed20fa684 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,esai.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,esai.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Enhanced Serial Audio Interface (ESAI) Controller + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + - Frank Li <Frank.Li@nxp.com> + +description: + The Enhanced Serial Audio Interface (ESAI) provides a full-duplex serial port + for serial communication with a variety of serial devices, including industry + standard codecs, Sony/Phillips Digital Interface (S/PDIF) transceivers, and + other DSPs. It has up to six transmitters and four receivers. + +properties: + compatible: + enum: + - fsl,imx35-esai + - fsl,imx6ull-esai + - fsl,imx8qm-esai + - fsl,vf610-esai + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 3 + items: + - description: + The core clock used to access registers. + - description: + The esai baud clock for esai controller used to + derive HCK, SCK and FS. + - description: + The system clock derived from ahb clock used to + derive HCK, SCK and FS. + - description: + The spba clock is required when ESAI is placed as a + bus slave of the Shared Peripheral Bus and when two + or more bus masters (CPU, DMA or DSP) try to access + it. This property is optional depending on the SoC + design. + + clock-names: + minItems: 3 + items: + - const: core + - const: extal + - const: fsys + - const: spba + + dmas: + minItems: 2 + maxItems: 2 + + dma-names: + items: + - const: rx + - const: tx + + fsl,fifo-depth: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 64 + description: + The number of elements in the transmit and receive + FIFOs. This number is the maximum allowed value for + TFCR[TFWM] or RFCR[RFWM]. + + fsl,esai-synchronous: + $ref: /schemas/types.yaml#/definitions/flag + description: + This is a boolean property. If present, indicating + that ESAI would work in the synchronous mode, which + means all the settings for Receiving would be + duplicated from Transmission related registers. + + big-endian: + $ref: /schemas/types.yaml#/definitions/flag + description: + If this property is absent, the native endian mode + will be in use as default, or the big endian mode + will be in use for all the device registers. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + +unevaluatedProperties: false + +allOf: + - $ref: dai-common.yaml# + +examples: + - | + esai@2024000 { + compatible = "fsl,imx35-esai"; + reg = <0x02024000 0x4000>; + interrupts = <0 51 0x04>; + clocks = <&clks 208>, <&clks 118>, <&clks 208>; + clock-names = "core", "extal", "fsys"; + dmas = <&sdma 23 21 0>, <&sdma 24 21 0>; + dma-names = "rx", "tx"; + fsl,fifo-depth = <128>; + fsl,esai-synchronous; + big-endian; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml index bfef2fcb75b1..76aa1f248488 100644 --- a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml @@ -74,6 +74,9 @@ properties: - const: asrck_f - const: spba + power-domains: + maxItems: 1 + fsl,asrc-rate: $ref: /schemas/types.yaml#/definitions/uint32 description: The mutual sample rate used by DPCM Back Ends @@ -131,6 +134,17 @@ allOf: properties: fsl,asrc-clk-map: false + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8qm-asrc + - fsl,imx8qxp-asrc + then: + required: + - power-domains + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml new file mode 100644 index 000000000000..5fc543d02ecb --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,imx-audio-spdif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX audio complex with S/PDIF transceiver + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx-sabreauto-spdif + - fsl,imx6sx-sdb-spdif + - const: fsl,imx-audio-spdif + - enum: + - fsl,imx-audio-spdif + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + spdif-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the i.MX S/PDIF controller + + spdif-out: + type: boolean + description: + If present, the transmitting function of S/PDIF will be enabled, + indicating there's a physical S/PDIF out connector or jack on the + board or it's connecting to some other IP block, such as an HDMI + encoder or display-controller. + + spdif-in: + type: boolean + description: + If present, the receiving function of S/PDIF will be enabled, + indicating there is a physical S/PDIF in connector/jack on the board. + +required: + - compatible + - model + - spdif-controller + +anyOf: + - required: + - spdif-in + - required: + - spdif-out + +additionalProperties: false + +examples: + - | + sound-spdif { + compatible = "fsl,imx-audio-spdif"; + model = "imx-spdif"; + spdif-controller = <&spdif>; + spdif-out; + spdif-in; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml index 2456d958adee..a5d9c246cc47 100644 --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml @@ -81,14 +81,12 @@ properties: dmas: minItems: 1 - items: - - description: DMA controller phandle and request line for RX - - description: DMA controller phandle and request line for TX + maxItems: 2 dma-names: minItems: 1 items: - - const: rx + - enum: [ rx, tx ] - const: tx interrupts: diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml index 1d64e8337aa4..204f361cea27 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml @@ -31,7 +31,10 @@ properties: maxItems: 1 interrupts: - maxItems: 1 + minItems: 1 + items: + - description: Combined or receive interrupt + - description: Transmit interrupt dmas: items: @@ -86,6 +89,9 @@ properties: registers. Set this flag for HCDs with big endian descriptors and big endian registers. + power-domains: + maxItems: 1 + required: - compatible - reg @@ -97,6 +103,33 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + enum: + - fsl,imx8qm-spdif + - fsl,imx8qxp-spdif + then: + properties: + interrupts: + minItems: 2 + else: + properties: + interrupts: + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8qm-spdif + - fsl,imx8qxp-spdif + then: + required: + - power-domains + examples: - | spdif@2004000 { diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt deleted file mode 100644 index 7e15a85cecd2..000000000000 --- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt +++ /dev/null @@ -1,87 +0,0 @@ -Freescale Synchronous Serial Interface - -The SSI is a serial device that communicates with audio codecs. It can -be programmed in AC97, I2S, left-justified, or right-justified modes. - -Required properties: -- compatible: Compatible list, should contain one of the following - compatibles: - fsl,mpc8610-ssi - fsl,imx51-ssi - fsl,imx35-ssi - fsl,imx21-ssi -- cell-index: The SSI, <0> = SSI1, <1> = SSI2, and so on. -- reg: Offset and length of the register set for the device. -- interrupts: <a b> where a is the interrupt number and b is a - field that represents an encoding of the sense and - level information for the interrupt. This should be - encoded based on the information in section 2) - depending on the type of interrupt controller you - have. -- fsl,fifo-depth: The number of elements in the transmit and receive FIFOs. - This number is the maximum allowed value for SFCSR[TFWM0]. - - clocks: "ipg" - Required clock for the SSI unit - "baud" - Required clock for SSI master mode. Otherwise this - clock is not used - -Required are also ac97 link bindings if ac97 is used. See -Documentation/devicetree/bindings/sound/soc-ac97link.txt for the necessary -bindings. - -Optional properties: -- codec-handle: Phandle to a 'codec' node that defines an audio - codec connected to this SSI. This node is typically - a child of an I2C or other control node. -- fsl,fiq-stream-filter: Bool property. Disabled DMA and use FIQ instead to - filter the codec stream. This is necessary for some boards - where an incompatible codec is connected to this SSI, e.g. - on pca100 and pcm043. -- dmas: Generic dma devicetree binding as described in - Documentation/devicetree/bindings/dma/dma.txt. -- dma-names: Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq - is not defined. -- fsl,mode: The operating mode for the AC97 interface only. - "ac97-slave" - AC97 mode, SSI is clock slave - "ac97-master" - AC97 mode, SSI is clock master -- fsl,ssi-asynchronous: - If specified, the SSI is to be programmed in asynchronous - mode. In this mode, pins SRCK, STCK, SRFS, and STFS must - all be connected to valid signals. In synchronous mode, - SRCK and SRFS are ignored. Asynchronous mode allows - playback and capture to use different sample sizes and - sample rates. Some drivers may require that SRCK and STCK - be connected together, and SRFS and STFS be connected - together. This would still allow different sample sizes, - but not different sample rates. -- fsl,playback-dma: Phandle to a node for the DMA channel to use for - playback of audio. This is typically dictated by SOC - design. See the notes below. - Only used on Power Architecture. -- fsl,capture-dma: Phandle to a node for the DMA channel to use for - capture (recording) of audio. This is typically dictated - by SOC design. See the notes below. - Only used on Power Architecture. - -Child 'codec' node required properties: -- compatible: Compatible list, contains the name of the codec - -Child 'codec' node optional properties: -- clock-frequency: The frequency of the input clock, which typically comes - from an on-board dedicated oscillator. - -Notes on fsl,playback-dma and fsl,capture-dma: - -On SOCs that have an SSI, specific DMA channels are hard-wired for playback -and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for -playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for -playback and DMA channel 3 for capture. The developer can choose which -DMA controller to use, but the channels themselves are hard-wired. The -purpose of these two properties is to represent this hardware design. - -The device tree nodes for the DMA channels that are referenced by -"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with -"fsl,ssi-dma-channel". The SOC-specific compatible string (e.g. -"fsl,mpc8610-dma-channel") can remain. If these nodes are left as -"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA -drivers (fsldma) will attempt to use them, and it will conflict with the -sound drivers. diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.yaml b/Documentation/devicetree/bindings/sound/fsl,ssi.yaml new file mode 100644 index 000000000000..4ab10cd3b520 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,ssi.yaml @@ -0,0 +1,194 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,ssi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Synchronous Serial Interface + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + +description: + Notes on fsl,playback-dma and fsl,capture-dma + On SOCs that have an SSI, specific DMA channels are hard-wired for playback + and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for + playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for + playback and DMA channel 3 for capture. The developer can choose which + DMA controller to use, but the channels themselves are hard-wired. The + purpose of these two properties is to represent this hardware design. + + The device tree nodes for the DMA channels that are referenced by + "fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with + "fsl,ssi-dma-channel". The SOC-specific compatible string (e.g. + "fsl,mpc8610-dma-channel") can remain. If these nodes are left as + "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA + drivers (fsldma) will attempt to use them, and it will conflict with the + sound drivers. + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx50-ssi + - fsl,imx53-ssi + - const: fsl,imx51-ssi + - const: fsl,imx21-ssi + - items: + - enum: + - fsl,imx25-ssi + - fsl,imx27-ssi + - fsl,imx35-ssi + - fsl,imx51-ssi + - const: fsl,imx21-ssi + - items: + - enum: + - fsl,imx6q-ssi + - fsl,imx6sl-ssi + - fsl,imx6sx-ssi + - const: fsl,imx51-ssi + - items: + - const: fsl,imx21-ssi + - items: + - const: fsl,mpc8610-ssi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: The ipg clock for register access + - description: clock for SSI master mode + minItems: 1 + + clock-names: + items: + - const: ipg + - const: baud + minItems: 1 + + dmas: + oneOf: + - items: + - description: DMA controller phandle and request line for RX + - description: DMA controller phandle and request line for TX + - items: + - description: DMA controller phandle and request line for RX0 + - description: DMA controller phandle and request line for TX0 + - description: DMA controller phandle and request line for RX1 + - description: DMA controller phandle and request line for TX1 + + dma-names: + oneOf: + - items: + - const: rx + - const: tx + - items: + - const: rx0 + - const: tx0 + - const: rx1 + - const: tx1 + + "#sound-dai-cells": + const: 0 + description: optional, some dts node didn't add it. + + cell-index: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + description: The SSI index + + ac97-gpios: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: Please refer to soc-ac97link.txt + + codec-handle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to a 'codec' node that defines an audio + codec connected to this SSI. This node is typically + a child of an I2C or other control node. + + fsl,fifo-depth: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The number of elements in the transmit and receive FIFOs. + This number is the maximum allowed value for SFCSR[TFWM0]. + enum: [8, 15] + + fsl,fiq-stream-filter: + type: boolean + description: + Disabled DMA and use FIQ instead to filter the codec stream. + This is necessary for some boards where an incompatible codec + is connected to this SSI, e.g. on pca100 and pcm043. + + fsl,mode: + $ref: /schemas/types.yaml#/definitions/string + enum: [ ac97-slave, ac97-master, i2s-slave, i2s-master, + lj-slave, lj-master, rj-slave, rj-master ] + description: | + "ac97-slave" - AC97 mode, SSI is clock slave + "ac97-master" - AC97 mode, SSI is clock master + "i2s-slave" - I2S mode, SSI is clock slave + "i2s-master" - I2S mode, SSI is clock master + "lj-slave" - Left justified mode, SSI is clock slave + "lj-master" - Left justified mode, SSI is clock master + "rj-slave" - Right justified mode, SSI is clock slave + "rj-master" - Right justified mode, SSI is clock master + + fsl,ssi-asynchronous: + type: boolean + description: If specified, the SSI is to be programmed in asynchronous + mode. In this mode, pins SRCK, STCK, SRFS, and STFS must + all be connected to valid signals. In synchronous mode, + SRCK and SRFS are ignored. Asynchronous mode allows + playback and capture to use different sample sizes and + sample rates. Some drivers may require that SRCK and STCK + be connected together, and SRFS and STFS be connected + together. This would still allow different sample sizes, + but not different sample rates. + + fsl,playback-dma: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to a node for the DMA channel to use for + playback of audio. This is typically dictated by SOC + design. Only used on Power Architecture. + + fsl,capture-dma: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to a node for the DMA channel to use for + capture (recording) of audio. This is typically dictated + by SOC design. Only used on Power Architecture. + +required: + - compatible + - reg + - interrupts + - fsl,fifo-depth + +allOf: + - $ref: dai-common.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx6qdl-clock.h> + ssi@2028000 { + compatible = "fsl,imx6q-ssi", "fsl,imx51-ssi"; + reg = <0x02028000 0x4000>; + interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks IMX6QDL_CLK_SSI1_IPG>, + <&clks IMX6QDL_CLK_SSI1>; + clock-names = "ipg", "baud"; + dmas = <&sdma 37 1 0>, <&sdma 38 1 0>; + dma-names = "rx", "tx"; + #sound-dai-cells = <0>; + fsl,fifo-depth = <15>; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt deleted file mode 100644 index 4e8dbc5abfd1..000000000000 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt +++ /dev/null @@ -1,117 +0,0 @@ -Freescale Generic ASoC Sound Card with ASRC support - -The Freescale Generic ASoC Sound Card can be used, ideally, for all Freescale -SoCs connecting with external CODECs. - -The idea of this generic sound card is a bit like ASoC Simple Card. However, -for Freescale SoCs (especially those released in recent years), most of them -have ASRC (Documentation/devicetree/bindings/sound/fsl,asrc.txt) inside. And -this is a specific feature that might be painstakingly controlled and merged -into the Simple Card. - -So having this generic sound card allows all Freescale SoC users to benefit -from the simplification of a new card support and the capability of the wide -sample rates support through ASRC. - -Note: The card is initially designed for those sound cards who use AC'97, I2S - and PCM DAI formats. However, it'll be also possible to support those non - AC'97/I2S/PCM type sound cards, such as S/PDIF audio and HDMI audio, as - long as the driver has been properly upgraded. - - -The compatible list for this generic sound card currently: - "fsl,imx-audio-ac97" - - "fsl,imx-audio-cs42888" - - "fsl,imx-audio-cs427x" - (compatible with CS4271 and CS4272) - - "fsl,imx-audio-wm8962" - - "fsl,imx-audio-sgtl5000" - (compatible with Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt) - - "fsl,imx-audio-wm8960" - - "fsl,imx-audio-mqs" - - "fsl,imx-audio-wm8524" - - "fsl,imx-audio-tlv320aic32x4" - - "fsl,imx-audio-tlv320aic31xx" - - "fsl,imx-audio-si476x" - - "fsl,imx-audio-wm8958" - - "fsl,imx-audio-nau8822" - -Required properties: - - - compatible : Contains one of entries in the compatible list. - - - model : The user-visible name of this sound complex - - - audio-cpu : The phandle of an CPU DAI controller - - - audio-codec : The phandle of an audio codec - -Optional properties: - - - audio-asrc : The phandle of ASRC. It can be absent if there's no - need to add ASRC support via DPCM. - - - audio-routing : A list of the connections between audio components. - Each entry is a pair of strings, the first being the - connection's sink, the second being the connection's - source. There're a few pre-designed board connectors: - * Line Out Jack - * Line In Jack - * Headphone Jack - * Mic Jack - * Ext Spk - * AMIC (stands for Analog Microphone Jack) - * DMIC (stands for Digital Microphone Jack) - - Note: The "Mic Jack" and "AMIC" are redundant while - coexisting in order to support the old bindings - of wm8962 and sgtl5000. - - - hp-det-gpio : The GPIO that detect headphones are plugged in - - mic-det-gpio : The GPIO that detect microphones are plugged in - - bitclock-master : Indicates dai-link bit clock master; for details see simple-card.yaml. - - frame-master : Indicates dai-link frame master; for details see simple-card.yaml. - - dai-format : audio format, for details see simple-card.yaml. - - frame-inversion : dai-link uses frame clock inversion, for details see simple-card.yaml. - - bitclock-inversion : dai-link uses bit clock inversion, for details see simple-card.yaml. - - mclk-id : main clock id, specific for each card configuration. - -Optional unless SSI is selected as a CPU DAI: - - - mux-int-port : The internal port of the i.MX audio muxer (AUDMUX) - - - mux-ext-port : The external port of the i.MX audio muxer - -Example: -sound-cs42888 { - compatible = "fsl,imx-audio-cs42888"; - model = "cs42888-audio"; - audio-cpu = <&esai>; - audio-asrc = <&asrc>; - audio-codec = <&cs42888>; - audio-routing = - "Line Out Jack", "AOUT1L", - "Line Out Jack", "AOUT1R", - "Line Out Jack", "AOUT2L", - "Line Out Jack", "AOUT2R", - "Line Out Jack", "AOUT3L", - "Line Out Jack", "AOUT3R", - "Line Out Jack", "AOUT4L", - "Line Out Jack", "AOUT4R", - "AIN1L", "Line In Jack", - "AIN1R", "Line In Jack", - "AIN2L", "Line In Jack", - "AIN2R", "Line In Jack"; -}; diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml b/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml new file mode 100644 index 000000000000..9922664d5ccc --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml @@ -0,0 +1,197 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl-asoc-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Generic ASoC Sound Card with ASRC support + +description: + The Freescale Generic ASoC Sound Card can be used, ideally, + for all Freescale SoCs connecting with external CODECs. + + The idea of this generic sound card is a bit like ASoC Simple Card. + However, for Freescale SoCs (especially those released in recent years), + most of them have ASRC inside. And this is a specific feature that might + be painstakingly controlled and merged into the Simple Card. + + So having this generic sound card allows all Freescale SoC users to + benefit from the simplification of a new card support and the capability + of the wide sample rates support through ASRC. + + Note, The card is initially designed for those sound cards who use AC'97, I2S + and PCM DAI formats. However, it'll be also possible to support those non + AC'97/I2S/PCM type sound cards, such as S/PDIF audio and HDMI audio, as + long as the driver has been properly upgraded. + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx-sgtl5000 + - fsl,imx25-pdk-sgtl5000 + - fsl,imx53-cpuvo-sgtl5000 + - fsl,imx51-babbage-sgtl5000 + - fsl,imx53-m53evk-sgtl5000 + - fsl,imx53-qsb-sgtl5000 + - fsl,imx53-voipac-sgtl5000 + - fsl,imx6-armadeus-sgtl5000 + - fsl,imx6-rex-sgtl5000 + - fsl,imx6-sabreauto-cs42888 + - fsl,imx6-wandboard-sgtl5000 + - fsl,imx6dl-nit6xlite-sgtl5000 + - fsl,imx6q-ba16-sgtl5000 + - fsl,imx6q-nitrogen6_max-sgtl5000 + - fsl,imx6q-nitrogen6_som2-sgtl5000 + - fsl,imx6q-nitrogen6x-sgtl5000 + - fsl,imx6q-sabrelite-sgtl5000 + - fsl,imx6q-sabresd-wm8962 + - fsl,imx6q-udoo-ac97 + - fsl,imx6q-ventana-sgtl5000 + - fsl,imx6sl-evk-wm8962 + - fsl,imx6sx-sdb-mqs + - fsl,imx6sx-sdb-wm8962 + - fsl,imx7d-evk-wm8960 + - karo,tx53-audio-sgtl5000 + - tq,imx53-mba53-sgtl5000 + - enum: + - fsl,imx-audio-ac97 + - fsl,imx-audio-cs42888 + - fsl,imx-audio-mqs + - fsl,imx-audio-sgtl5000 + - fsl,imx-audio-wm8960 + - fsl,imx-audio-wm8962 + - items: + - enum: + - fsl,imx-audio-ac97 + - fsl,imx-audio-cs42888 + - fsl,imx-audio-cs427x + - fsl,imx-audio-mqs + - fsl,imx-audio-nau8822 + - fsl,imx-audio-sgtl5000 + - fsl,imx-audio-si476x + - fsl,imx-audio-tlv320aic31xx + - fsl,imx-audio-tlv320aic32x4 + - fsl,imx-audio-wm8524 + - fsl,imx-audio-wm8904 + - fsl,imx-audio-wm8960 + - fsl,imx-audio-wm8962 + - fsl,imx-audio-wm8958 + + model: + $ref: /schemas/types.yaml#/definitions/string + description: The user-visible name of this sound complex + + audio-asrc: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of ASRC. It can be absent if there's no + need to add ASRC support via DPCM. + + audio-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of an audio codec + + audio-cpu: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of an CPU DAI controller + + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. There're a few pre-designed board + connectors. "AMIC" stands for Analog Microphone Jack. + "DMIC" stands for Digital Microphone Jack. The "Mic Jack" and "AMIC" + are redundant while coexisting in order to support the old bindings + of wm8962 and sgtl5000. + + hp-det-gpio: + deprecated: true + maxItems: 1 + description: The GPIO that detect headphones are plugged in + + hp-det-gpios: + maxItems: 1 + description: The GPIO that detect headphones are plugged in + + mic-det-gpio: + deprecated: true + maxItems: 1 + description: The GPIO that detect microphones are plugged in + + mic-det-gpios: + maxItems: 1 + description: The GPIO that detect microphones are plugged in + + bitclock-master: + $ref: simple-card.yaml#/definitions/bitclock-master + description: Indicates dai-link bit clock master. + + frame-master: + $ref: simple-card.yaml#/definitions/frame-master + description: Indicates dai-link frame master. + + format: + $ref: simple-card.yaml#/definitions/format + description: audio format. + + frame-inversion: + $ref: simple-card.yaml#/definitions/frame-inversion + description: dai-link uses frame clock inversion. + + bitclock-inversion: + $ref: simple-card.yaml#/definitions/bitclock-inversion + description: dai-link uses bit clock inversion. + + mclk-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: main clock id, specific for each card configuration. + + mux-int-port: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 7] + description: The internal port of the i.MX audio muxer (AUDMUX) + + mux-ext-port: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [3, 4, 5, 6] + description: The external port of the i.MX audio muxer + + ssi-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of an CPU DAI controller + +required: + - compatible + - model + +unevaluatedProperties: false + +examples: + - | + sound-cs42888 { + compatible = "fsl,imx-audio-cs42888"; + model = "cs42888-audio"; + audio-cpu = <&esai>; + audio-asrc = <&asrc>; + audio-codec = <&cs42888>; + audio-routing = + "Line Out Jack", "AOUT1L", + "Line Out Jack", "AOUT1R", + "Line Out Jack", "AOUT2L", + "Line Out Jack", "AOUT2R", + "Line Out Jack", "AOUT3L", + "Line Out Jack", "AOUT3R", + "Line Out Jack", "AOUT4L", + "Line Out Jack", "AOUT4R", + "AIN1L", "Line In Jack", + "AIN1R", "Line In Jack", + "AIN2L", "Line In Jack", + "AIN2R", "Line In Jack"; + }; diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt deleted file mode 100644 index da84a442ccea..000000000000 --- a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt +++ /dev/null @@ -1,36 +0,0 @@ -Freescale i.MX audio complex with S/PDIF transceiver - -Required properties: - - - compatible : "fsl,imx-audio-spdif" - - - model : The user-visible name of this sound complex - - - spdif-controller : The phandle of the i.MX S/PDIF controller - - -Optional properties: - - - spdif-out : This is a boolean property. If present, the - transmitting function of S/PDIF will be enabled, - indicating there's a physical S/PDIF out connector - or jack on the board or it's connecting to some - other IP block, such as an HDMI encoder or - display-controller. - - - spdif-in : This is a boolean property. If present, the receiving - function of S/PDIF will be enabled, indicating there - is a physical S/PDIF in connector/jack on the board. - -* Note: At least one of these two properties should be set in the DT binding. - - -Example: - -sound-spdif { - compatible = "fsl,imx-audio-spdif"; - model = "imx-spdif"; - spdif-controller = <&spdif>; - spdif-out; - spdif-in; -}; diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml new file mode 100644 index 000000000000..cf985461a995 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mediatek,mt2701-wm8960.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek MT2701 with WM8960 CODEC + +maintainers: + - Kartik Agarwala <agarwala.kartik@gmail.com> + +properties: + compatible: + const: mediatek,mt2701-wm8960-machine + + mediatek,platform: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of MT2701 ASoC platform. + + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. + + mediatek,audio-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the WM8960 audio codec. + +unevaluatedProperties: false + +required: + - compatible + - mediatek,platform + - audio-routing + - mediatek,audio-codec + - pinctrl-names + - pinctrl-0 + +examples: + - | + sound { + compatible = "mediatek,mt2701-wm8960-machine"; + mediatek,platform = <&afe>; + audio-routing = + "Headphone", "HP_L", + "Headphone", "HP_R", + "LINPUT1", "AMIC", + "RINPUT1", "AMIC"; + mediatek,audio-codec = <&wm8960>; + pinctrl-names = "default"; + pinctrl-0 = <&aud_pins_default>; + }; diff --git a/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt b/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt deleted file mode 100644 index 809b609ea9d0..000000000000 --- a/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt +++ /dev/null @@ -1,24 +0,0 @@ -MT2701 with WM8960 CODEC - -Required properties: -- compatible: "mediatek,mt2701-wm8960-machine" -- mediatek,platform: the phandle of MT2701 ASoC platform -- audio-routing: a list of the connections between audio -- mediatek,audio-codec: the phandles of wm8960 codec -- pinctrl-names: Should contain only one value - "default" -- pinctrl-0: Should specify pin control groups used for this controller. - -Example: - - sound:sound { - compatible = "mediatek,mt2701-wm8960-machine"; - mediatek,platform = <&afe>; - audio-routing = - "Headphone", "HP_L", - "Headphone", "HP_R", - "LINPUT1", "AMIC", - "RINPUT1", "AMIC"; - mediatek,audio-codec = <&wm8960>; - pinctrl-names = "default"; - pinctrl-0 = <&aud_pins_default>; - }; diff --git a/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml b/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml index 9853c11a1330..cbc641ecbe94 100644 --- a/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml +++ b/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml @@ -12,17 +12,46 @@ maintainers: description: This binding describes the MT8186 sound card. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: - mediatek,mt8186-mt6366-da7219-max98357-sound + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. + Valid names could be the input or output widgets of audio components, + power supplies, MicBias of codec and the software switch. + minItems: 2 + items: + enum: + # Sinks + - HDMI1 + - Headphones + - Line Out + - MIC + - Speakers + + # Sources + - Headset Mic + - HPL + - HPR + - Speaker + - TX + mediatek,platform: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8186 ASoC platform. headset-codec: type: object + deprecated: true additionalProperties: false properties: sound-dai: @@ -32,6 +61,7 @@ properties: playback-codecs: type: object + deprecated: true additionalProperties: false properties: sound-dai: @@ -53,32 +83,115 @@ properties: A list of the desired dai-links in the sound card. Each entry is a name defined in the machine driver. -additionalProperties: false +patternProperties: + ".*-dai-link$": + type: object + additionalProperties: false + description: + Container for dai-link level properties and CODEC sub-nodes. + + properties: + link-name: + description: Indicates dai-link name and PCM stream name + items: + enum: + - I2S0 + - I2S1 + - I2S2 + - I2S3 + + codec: + description: Holds subnode which indicates codec dai. + type: object + additionalProperties: false + properties: + sound-dai: + minItems: 1 + maxItems: 2 + required: + - sound-dai + + dai-format: + description: audio format + items: + enum: + - i2s + - right_j + - left_j + - dsp_a + - dsp_b + + mediatek,clk-provider: + $ref: /schemas/types.yaml#/definitions/string + description: Indicates dai-link clock master. + items: + enum: + - cpu + - codec + + required: + - link-name + +unevaluatedProperties: false required: - compatible - mediatek,platform - - headset-codec - - playback-codecs + +# Disallow legacy properties if xxx-dai-link nodes are specified +if: + not: + patternProperties: + ".*-dai-link$": false +then: + properties: + headset-codec: false + speaker-codecs: false examples: - | sound: mt8186-sound { compatible = "mediatek,mt8186-mt6366-da7219-max98357-sound"; - mediatek,platform = <&afe>; + model = "mt8186_da7219_m98357"; pinctrl-names = "aud_clk_mosi_off", "aud_clk_mosi_on"; pinctrl-0 = <&aud_clk_mosi_off>; pinctrl-1 = <&aud_clk_mosi_on>; + mediatek,platform = <&afe>; + + audio-routing = + "Headphones", "HPL", + "Headphones", "HPR", + "MIC", "Headset Mic", + "Speakers", "Speaker", + "HDMI1", "TX"; + + hs-playback-dai-link { + link-name = "I2S0"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&da7219>; + }; + }; - headset-codec { - sound-dai = <&da7219>; + hs-capture-dai-link { + link-name = "I2S1"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&da7219>; + }; }; - playback-codecs { - sound-dai = <&anx_bridge_dp>, - <&max98357a>; + spk-dp-playback-dai-link { + link-name = "I2S3"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&anx_bridge_dp>, <&max98357a>; + }; }; }; diff --git a/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml b/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml index bdf7b0960533..ed93f18ef985 100644 --- a/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml +++ b/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml @@ -12,6 +12,9 @@ maintainers: description: This binding describes the MT8186 sound card. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: @@ -19,6 +22,34 @@ properties: - mediatek,mt8186-mt6366-rt5682s-max98360-sound - mediatek,mt8186-mt6366-rt5650-sound + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. + Valid names could be the input or output widgets of audio components, + power supplies, MicBias of codec and the software switch. + minItems: 2 + items: + enum: + # Sinks + - HDMI1 + - Headphone + - IN1P + - IN1N + - Line Out + - Speakers + + # Sources + - Headset Mic + - HPOL + - HPOR + - Speaker + - SPOL + - SPOR + - TX + mediatek,platform: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8186 ASoC platform. @@ -32,6 +63,7 @@ properties: headset-codec: type: object + deprecated: true additionalProperties: false properties: sound-dai: @@ -41,6 +73,7 @@ properties: playback-codecs: type: object + deprecated: true additionalProperties: false properties: sound-dai: @@ -62,13 +95,56 @@ properties: A list of the desired dai-links in the sound card. Each entry is a name defined in the machine driver. -additionalProperties: false +patternProperties: + ".*-dai-link$": + type: object + additionalProperties: false + description: + Container for dai-link level properties and CODEC sub-nodes. + + properties: + link-name: + description: Indicates dai-link name and PCM stream name + enum: [ I2S0, I2S1, I2S2, I2S3 ] + + codec: + description: Holds subnode which indicates codec dai. + type: object + additionalProperties: false + properties: + sound-dai: + minItems: 1 + maxItems: 2 + required: + - sound-dai + + dai-format: + description: audio format + enum: [ i2s, right_j, left_j, dsp_a, dsp_b ] + + mediatek,clk-provider: + $ref: /schemas/types.yaml#/definitions/string + description: Indicates dai-link clock master. + enum: [ cpu, codec ] + + required: + - link-name + +unevaluatedProperties: false required: - compatible - mediatek,platform - - headset-codec - - playback-codecs + +# Disallow legacy properties if xxx-dai-link nodes are specified +if: + not: + patternProperties: + ".*-dai-link$": false +then: + properties: + headset-codec: false + speaker-codecs: false examples: - | @@ -76,23 +152,49 @@ examples: sound: mt8186-sound { compatible = "mediatek,mt8186-mt6366-rt1019-rt5682s-sound"; - mediatek,platform = <&afe>; + model = "mt8186_rt1019_rt5682s"; pinctrl-names = "aud_clk_mosi_off", "aud_clk_mosi_on", "aud_gpio_dmic_sec"; pinctrl-0 = <&aud_clk_mosi_off>; pinctrl-1 = <&aud_clk_mosi_on>; pinctrl-2 = <&aud_gpio_dmic_sec>; + mediatek,platform = <&afe>; dmic-gpios = <&pio 23 GPIO_ACTIVE_HIGH>; - headset-codec { - sound-dai = <&rt5682s>; + audio-routing = + "Headphone", "HPOL", + "Headphone", "HPOR", + "IN1P", "Headset Mic", + "Speakers", "Speaker", + "HDMI1", "TX"; + + hs-playback-dai-link { + link-name = "I2S0"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&rt5682s 0>; + }; + }; + + hs-capture-dai-link { + link-name = "I2S1"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&rt5682s 0>; + }; }; - playback-codecs { - sound-dai = <&it6505dptx>, - <&rt1019p>; + spk-hdmi-playback-dai-link { + link-name = "I2S3"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&it6505dptx>, <&rt1019p>; + }; }; }; diff --git a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml index 7e50f5d65c8f..c4e68f31aaab 100644 --- a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml +++ b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml @@ -13,6 +13,9 @@ maintainers: description: This binding describes the MT8192 sound card. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: @@ -20,6 +23,31 @@ properties: - mediatek,mt8192_mt6359_rt1015p_rt5682 - mediatek,mt8192_mt6359_rt1015p_rt5682s + audio-routing: + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. + Valid names could be the input or output widgets of audio components, + power supplies, MicBias of codec and the software switch. + minItems: 2 + items: + enum: + # Sinks + - Speakers + - Headphone Jack + - IN1P + - Left Spk + - Right Spk + + # Sources + - Headset Mic + - HPOL + - HPOR + - Left SPO + - Right SPO + - Speaker + mediatek,platform: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8192 ASoC platform. @@ -27,10 +55,12 @@ properties: mediatek,hdmi-codec: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of HDMI codec. + deprecated: true headset-codec: type: object additionalProperties: false + deprecated: true properties: sound-dai: @@ -41,6 +71,7 @@ properties: speaker-codecs: type: object additionalProperties: false + deprecated: true properties: sound-dai: @@ -51,33 +82,121 @@ properties: required: - sound-dai -additionalProperties: false +patternProperties: + ".*-dai-link$": + type: object + additionalProperties: false + + description: + Container for dai-link level properties and CODEC sub-nodes. + + properties: + link-name: + description: Indicates dai-link name and PCM stream name + enum: + - I2S0 + - I2S1 + - I2S2 + - I2S3 + - I2S4 + - I2S5 + - I2S6 + - I2S7 + - I2S8 + - I2S9 + - TDM + + codec: + description: Holds subnode which indicates codec dai. + type: object + additionalProperties: false + properties: + sound-dai: + minItems: 1 + maxItems: 2 + required: + - sound-dai + + dai-format: + description: audio format + enum: [ i2s, right_j, left_j, dsp_a, dsp_b ] + + mediatek,clk-provider: + $ref: /schemas/types.yaml#/definitions/string + description: Indicates dai-link clock master. + enum: [ cpu, codec ] + + required: + - link-name + +unevaluatedProperties: false required: - compatible - mediatek,platform - - headset-codec - - speaker-codecs + +# Disallow legacy properties if xxx-dai-link nodes are specified +if: + not: + patternProperties: + ".*-dai-link$": false +then: + properties: + headset-codec: false + speaker-codecs: false + mediatek,hdmi-codec: false examples: - | sound: mt8192-sound { compatible = "mediatek,mt8192_mt6359_rt1015_rt5682"; - mediatek,platform = <&afe>; - mediatek,hdmi-codec = <&anx_bridge_dp>; + model = "mt8192_mt6359_rt1015_rt5682"; pinctrl-names = "aud_clk_mosi_off", "aud_clk_mosi_on"; pinctrl-0 = <&aud_clk_mosi_off>; pinctrl-1 = <&aud_clk_mosi_on>; + mediatek,platform = <&afe>; + + audio-routing = + "Headphone Jack", "HPOL", + "Headphone Jack", "HPOR", + "IN1P", "Headset Mic", + "Speakers", "Speaker"; + + spk-playback-dai-link { + link-name = "I2S3"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&rt1015p>; + }; + }; + + hs-playback-dai-link { + link-name = "I2S8"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&rt5682 0>; + }; + }; - headset-codec { - sound-dai = <&rt5682>; + hs-capture-dai-link { + link-name = "I2S9"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&rt5682 0>; + }; }; - speaker-codecs { - sound-dai = <&rt1015_l>, - <&rt1015_r>; + displayport-dai-link { + link-name = "TDM"; + dai-format = "dsp_a"; + codec { + sound-dai = <&anx_bridge_dp>; + }; }; }; diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml index c1ddbf672ca3..2af1d8ffbd8b 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml @@ -12,6 +12,9 @@ maintainers: description: This binding describes the MT8195 sound card. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: @@ -23,6 +26,33 @@ properties: $ref: /schemas/types.yaml#/definitions/string description: User specified audio sound card name + audio-routing: + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. + Valid names could be the input or output widgets of audio components, + power supplies, MicBias of codec and the software switch. + minItems: 2 + items: + enum: + # Sinks + - Ext Spk + - Headphone + - IN1P + - Left Spk + - Right Spk + + # Sources + - Headset Mic + - HPOL + - HPOR + - Left BE_OUT + - Left SPO + - Right BE_OUT + - Right SPO + - Speaker + mediatek,platform: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8195 ASoC platform. @@ -30,10 +60,12 @@ properties: mediatek,dptx-codec: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8195 Display Port Tx codec node. + deprecated: true mediatek,hdmi-codec: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8195 HDMI codec node. + deprecated: true mediatek,adsp: $ref: /schemas/types.yaml#/definitions/phandle @@ -45,20 +77,122 @@ properties: A list of the desired dai-links in the sound card. Each entry is a name defined in the machine driver. +patternProperties: + ".*-dai-link$": + type: object + additionalProperties: false + description: + Container for dai-link level properties and CODEC sub-nodes. + + properties: + link-name: + description: Indicates dai-link name and PCM stream name + enum: + - DPTX_BE + - ETDM1_IN_BE + - ETDM2_IN_BE + - ETDM1_OUT_BE + - ETDM2_OUT_BE + - ETDM3_OUT_BE + - PCM1_BE + + codec: + description: Holds subnode which indicates codec dai. + type: object + additionalProperties: false + properties: + sound-dai: + minItems: 1 + maxItems: 2 + required: + - sound-dai + + dai-format: + description: audio format + enum: [ i2s, right_j, left_j, dsp_a, dsp_b ] + + mediatek,clk-provider: + $ref: /schemas/types.yaml#/definitions/string + description: Indicates dai-link clock master. + enum: [ cpu, codec ] + + required: + - link-name + additionalProperties: false required: - compatible - mediatek,platform +# Disallow legacy properties if xxx-dai-link nodes are specified +if: + not: + patternProperties: + ".*-dai-link$": false +then: + properties: + mediatek,dptx-codec: false + mediatek,hdmi-codec: false + examples: - | sound: mt8195-sound { compatible = "mediatek,mt8195_mt6359_rt1019_rt5682"; + model = "mt8195_r1019_5682"; mediatek,platform = <&afe>; pinctrl-names = "default"; pinctrl-0 = <&aud_pins_default>; + + audio-routing = + "Headphone", "HPOL", + "Headphone", "HPOR", + "IN1P", "Headset Mic", + "Ext Spk", "Speaker"; + + mm-dai-link { + link-name = "ETDM1_IN_BE"; + mediatek,clk-provider = "cpu"; + }; + + hs-playback-dai-link { + link-name = "ETDM1_OUT_BE"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&headset_codec>; + }; + }; + + hs-capture-dai-link { + link-name = "ETDM2_IN_BE"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&headset_codec>; + }; + }; + + spk-playback-dai-link { + link-name = "ETDM2_OUT_BE"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&spk_amplifier>; + }; + }; + + hdmi-dai-link { + link-name = "ETDM3_OUT_BE"; + codec { + sound-dai = <&hdmi_tx>; + }; + }; + + displayport-dai-link { + link-name = "DPTX_BE"; + codec { + sound-dai = <&dp_tx>; + }; + }; }; ... diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8325.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8325.yaml new file mode 100644 index 000000000000..979be0d336da --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8325.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nuvoton,nau8325.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAU8325 audio Amplifier + +maintainers: + - Seven Lee <WTLI@nuvoton.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: nuvoton,nau8325 + + reg: + maxItems: 1 + + nuvoton,vref-impedance-ohms: + description: + The vref impedance to be used in ohms. Middle of voltage enables + Tie-Off selection options. Due to the high impedance of the VREF + pin, it is important to use a low-leakage capacitor. + + enum: [0, 25000, 125000, 2500] + + nuvoton,dac-vref-microvolt: + description: + The DAC vref to be used in voltage. DAC reference voltage setting. Can + be used for minor tuning of the output level. Since the VDDA is range + between 1.62 to 1.98 voltage, the typical value for design is 1.8V. After + the minor tuning, the final microvolt are as the below. + + enum: [1800000, 2700000, 2880000, 3060000] + + nuvoton,alc-enable: + description: + Enable digital automatic level control (ALC) function. + type: boolean + + nuvoton,clock-detection-disable: + description: + When clock detection is enabled, it will detect whether MCLK + and FS are within the range. MCLK range is from 2.048MHz to 24.576MHz. + FS range is from 8kHz to 96kHz. And also needs to detect the ratio + MCLK_SRC/LRCK of 256, 400 or 500, and needs to detect the BCLK + to make sure data is present. There needs to be at least 8 BCLK + cycles per Frame Sync. + type: boolean + + nuvoton,clock-det-data: + description: + Request clock detection to require 2048 non-zero samples before enabling + the audio paths. If set then non-zero samples is required, otherwise it + doesn't matter. + type: boolean + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@21 { + compatible = "nuvoton,nau8325"; + reg = <0x21>; + nuvoton,vref-impedance-ohms = <125000>; + nuvoton,dac-vref-microvolt = <2880000>; + nuvoton,alc-enable; + nuvoton,clock-det-data; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml index 054b53954ac3..9f44168efb3e 100644 --- a/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml @@ -103,6 +103,12 @@ properties: just limited to the left adc for design demand. type: boolean + nuvoton,adc-delay-ms: + description: Delay (in ms) to make input path stable and avoid pop noise. + minimum: 125 + maximum: 500 + default: 125 + '#sound-dai-cells': const: 0 @@ -136,6 +142,7 @@ examples: nuvoton,jack-eject-debounce = <0>; nuvoton,dmic-clk-threshold = <3072000>; nuvoton,dmic-slew-rate = <0>; + nuvoton,adc-delay-ms = <125>; #sound-dai-cells = <0>; }; }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt deleted file mode 100644 index eaf00102d92c..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt +++ /dev/null @@ -1,36 +0,0 @@ -NVIDIA Tegra 20 AC97 controller - -Required properties: -- compatible : "nvidia,tegra20-ac97" -- reg : Should contain AC97 controller registers location and length -- interrupts : Should contain AC97 interrupt -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - ac97 -- dmas : Must contain an entry for each entry in clock-names. - See ../dma/dma.txt for details. -- dma-names : Must include the following entries: - - rx - - tx -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- nvidia,codec-reset-gpio : The Tegra GPIO controller's phandle and the number - of the GPIO used to reset the external AC97 codec -- nvidia,codec-sync-gpio : The Tegra GPIO controller's phandle and the number - of the GPIO corresponding with the AC97 DAP _FS line - -Example: - -ac97@70002000 { - compatible = "nvidia,tegra20-ac97"; - reg = <0x70002000 0x200>; - interrupts = <0 81 0x04>; - nvidia,codec-reset-gpio = <&gpio 170 0>; - nvidia,codec-sync-gpio = <&gpio 120 0>; - clocks = <&tegra_car 3>; - resets = <&tegra_car 3>; - reset-names = "ac97"; - dmas = <&apbdma 12>, <&apbdma 12>; - dma-names = "rx", "tx"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml new file mode 100644 index 000000000000..4ea0a303d995 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra20-ac97.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20 AC97 controller + +maintainers: + - Thierry Reding <treding@nvidia.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra20-ac97 + + reg: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: ac97 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + dmas: + maxItems: 2 + + dma-names: + items: + - const: rx + - const: tx + + nvidia,codec-reset-gpios: + description: Reset pin of external AC97 codec + maxItems: 1 + + nvidia,codec-sync-gpios: + description: AC97 DAP _FS line + maxItems: 1 + +required: + - compatible + - reg + - resets + - reset-names + - interrupts + - clocks + - dmas + - dma-names + - nvidia,codec-reset-gpios + - nvidia,codec-sync-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + + ac97@70002000 { + compatible = "nvidia,tegra20-ac97"; + reg = <0x70002000 0x200>; + resets = <&tegra_car 3>; + reset-names = "ac97"; + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car 3>; + dmas = <&apbdma 12>, <&apbdma 12>; + dma-names = "rx", "tx"; + nvidia,codec-reset-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>; + nvidia,codec-sync-gpios = <&gpio TEGRA_GPIO(P, 0) GPIO_ACTIVE_HIGH>; + }; +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt deleted file mode 100644 index 6de3a7ee4efb..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt +++ /dev/null @@ -1,12 +0,0 @@ -NVIDIA Tegra 20 DAS (Digital Audio Switch) controller - -Required properties: -- compatible : "nvidia,tegra20-das" -- reg : Should contain DAS registers location and length - -Example: - -das@70000c00 { - compatible = "nvidia,tegra20-das"; - reg = <0x70000c00 0x80>; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml new file mode 100644 index 000000000000..44c5ce8ee6be --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra20-das.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra 20 DAS (Digital Audio Switch) controller + +maintainers: + - Thierry Reding <treding@nvidia.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra20-das + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <1>; + #size-cells = <1>; + das@70000c00 { + compatible = "nvidia,tegra20-das"; + reg = <0x70000c00 0x80>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt deleted file mode 100644 index 38caa936f6f8..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt +++ /dev/null @@ -1,27 +0,0 @@ -NVIDIA Tegra30 I2S controller - -Required properties: -- compatible : For Tegra30, must contain "nvidia,tegra30-i2s". For Tegra124, - must contain "nvidia,tegra124-i2s". Otherwise, must contain - "nvidia,<chip>-i2s" plus at least one of the above, where <chip> is - tegra114 or tegra132. -- reg : Should contain I2S registers location and length -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - i2s -- nvidia,ahub-cif-ids : The list of AHUB CIF IDs for this port, rx (playback) - first, tx (capture) second. See nvidia,tegra30-ahub.txt for values. - -Example: - -i2s@70080300 { - compatible = "nvidia,tegra30-i2s"; - reg = <0x70080300 0x100>; - nvidia,ahub-cif-ids = <4 4>; - clocks = <&tegra_car 11>; - resets = <&tegra_car 11>; - reset-names = "i2s"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml new file mode 100644 index 000000000000..89c3c6414ab1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra30-i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra30 I2S controller + +maintainers: + - Thierry Reding <treding@nvidia.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra124-i2s + - nvidia,tegra30-i2s + - items: + - const: nvidia,tegra114-i2s + - const: nvidia,tegra30-i2s + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: i2s + + resets: + maxItems: 1 + + reset-names: + const: i2s + + nvidia,ahub-cif-ids: + description: list of AHUB CIF IDs + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: rx (playback) + - description: tx (capture) + +required: + - compatible + - reg + - clocks + - resets + - reset-names + - nvidia,ahub-cif-ids + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra30-car.h> + + i2s@70080300 { + compatible = "nvidia,tegra30-i2s"; + reg = <0x70080300 0x100>; + nvidia,ahub-cif-ids = <4 4>; + clocks = <&tegra_car TEGRA30_CLK_I2S0>; + resets = <&tegra_car 30>; + reset-names = "i2s"; + }; +... diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index 2ab6871e89e5..b2e15ebbd1bc 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -29,6 +29,8 @@ properties: - enum: - qcom,apq8016-sbc-sndcard - qcom,msm8916-qdsp6-sndcard + - qcom,qcm6490-idp-sndcard + - qcom,qcs6490-rb3gen2-sndcard - qcom,qrb5165-rb5-sndcard - qcom,sc7180-qdsp6-sndcard - qcom,sc8280xp-sndcard diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 0d7a6b576d88..07ec6247d9de 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -48,13 +48,16 @@ properties: - const: renesas,rcar_sound-gen3 # for Gen4 SoC - items: - - const: renesas,rcar_sound-r8a779g0 # R-Car V4H + - enum: + - renesas,rcar_sound-r8a779g0 # R-Car V4H + - renesas,rcar_sound-r8a779h0 # R-Car V4M - const: renesas,rcar_sound-gen4 # for Generic - enum: - renesas,rcar_sound-gen1 - renesas,rcar_sound-gen2 - renesas,rcar_sound-gen3 + - renesas,rcar_sound-gen4 reg: minItems: 1 diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml new file mode 100644 index 000000000000..ecf3d7d968c8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/rockchip,rk3308-codec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3308 Internal Codec + +description: | + This is the audio codec embedded in the Rockchip RK3308 + SoC. It has 8 24-bit ADCs and 2 24-bit DACs. The maximum supported + sampling rate is 192 kHz. + + It is connected internally to one out of a selection of the internal I2S + controllers. + + The RK3308 audio codec has 8 independent capture channels, but some + features work on stereo pairs called groups: + * grp 0 -- MIC1 / MIC2 + * grp 1 -- MIC3 / MIC4 + * grp 2 -- MIC5 / MIC6 + * grp 3 -- MIC7 / MIC8 + +maintainers: + - Luca Ceresoli <luca.ceresoli@bootlin.com> + +properties: + compatible: + const: rockchip,rk3308-codec + + reg: + maxItems: 1 + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the General Register Files (GRF) + + clocks: + items: + - description: clock for TX + - description: clock for RX + - description: AHB clock driving the interface + + clock-names: + items: + - const: mclk_tx + - const: mclk_rx + - const: hclk + + resets: + maxItems: 1 + + reset-names: + items: + - const: codec + + "#sound-dai-cells": + const: 0 + + rockchip,micbias-avdd-percent: + description: | + Voltage setting for the MICBIAS pins expressed as a percentage of + AVDD. + + E.g. if rockchip,micbias-avdd-percent = 85 and AVDD = 3v3, then the + MIC BIAS voltage will be 3.3 V * 85% = 2.805 V. + + enum: [ 50, 55, 60, 65, 70, 75, 80, 85 ] + +required: + - compatible + - reg + - rockchip,grf + - clocks + - resets + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3308-cru.h> + + audio_codec: audio-codec@ff560000 { + compatible = "rockchip,rk3308-codec"; + reg = <0xff560000 0x10000>; + rockchip,grf = <&grf>; + clock-names = "mclk_tx", "mclk_rx", "hclk"; + clocks = <&cru SCLK_I2S2_8CH_TX_OUT>, + <&cru SCLK_I2S2_8CH_RX_OUT>, + <&cru PCLK_ACODEC>; + reset-names = "codec"; + resets = <&cru SRST_ACODEC_P>; + #sound-dai-cells = <0>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/rt5645.txt b/Documentation/devicetree/bindings/sound/rt5645.txt index 41a62fd2ae1f..c1fa379f5f3e 100644 --- a/Documentation/devicetree/bindings/sound/rt5645.txt +++ b/Documentation/devicetree/bindings/sound/rt5645.txt @@ -20,6 +20,11 @@ Optional properties: a GPIO spec for the external headphone detect pin. If jd-mode = 0, we will get the JD status by getting the value of hp-detect-gpios. +- cbj-sleeve-gpios: + a GPIO spec to control the external combo jack circuit to tie the sleeve/ring2 + contacts to the ground or floating. It could avoid some electric noise from the + active speaker jacks. + - realtek,in2-differential Boolean. Indicate MIC2 input are differential, rather than single-ended. @@ -68,6 +73,7 @@ codec: rt5650@1a { compatible = "realtek,rt5650"; reg = <0x1a>; hp-detect-gpios = <&gpio 19 0>; + cbj-sleeve-gpios = <&gpio 20 0>; interrupt-parent = <&gpio>; interrupts = <7 IRQ_TYPE_EDGE_FALLING>; realtek,dmic-en = "true"; diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml index b9111d375b93..8978f6bd63e5 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml @@ -65,6 +65,10 @@ properties: $ref: audio-graph-port.yaml# unevaluatedProperties: false + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - "#sound-dai-cells" diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index 59df8a832310..b46a4778807d 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -48,6 +48,10 @@ properties: clock-names: maxItems: 3 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml index bc48151b9adb..3dedc81ec12f 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml @@ -50,6 +50,10 @@ properties: resets: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - "#sound-dai-cells" diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1681.txt b/Documentation/devicetree/bindings/sound/ti,pcm1681.txt deleted file mode 100644 index 4df17185ab80..000000000000 --- a/Documentation/devicetree/bindings/sound/ti,pcm1681.txt +++ /dev/null @@ -1,15 +0,0 @@ -Texas Instruments PCM1681 8-channel PWM Processor - -Required properties: - - - compatible: Should contain "ti,pcm1681". - - reg: The i2c address. Should contain <0x4c>. - -Examples: - - i2c_bus { - pcm1681@4c { - compatible = "ti,pcm1681"; - reg = <0x4c>; - }; - }; diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml b/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml new file mode 100644 index 000000000000..5aa00617291c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ti,pcm1681.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments PCM1681 8-channel PWM Processor + +maintainers: + - Shenghao Ding <shenghao-ding@ti.com> + - Kevin Lu <kevin-lu@ti.com> + - Baojun Xu <baojun.xu@ti.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: ti,pcm1681 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pcm1681: audio-codec@4c { + compatible = "ti,pcm1681"; + reg = <0x4c>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml b/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml new file mode 100644 index 000000000000..dd5b08e3d7a1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml @@ -0,0 +1,177 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 - 2024 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ti,pcm6240.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments PCM6240 Family Audio ADC/DAC + +maintainers: + - Shenghao Ding <shenghao-ding@ti.com> + +description: | + The PCM6240 Family is a big family of Audio ADC/DAC for + different Specifications, range from Personal Electric + to Automotive Electric, even some professional fields. + + Specifications about the audio chip can be found at: + https://www.ti.com/lit/gpn/tlv320adc3120 + https://www.ti.com/lit/gpn/tlv320adc5120 + https://www.ti.com/lit/gpn/tlv320adc6120 + https://www.ti.com/lit/gpn/dix4192 + https://www.ti.com/lit/gpn/pcm1690 + https://www.ti.com/lit/gpn/pcm3120-q1 + https://www.ti.com/lit/gpn/pcm3140-q1 + https://www.ti.com/lit/gpn/pcm5120-q1 + https://www.ti.com/lit/gpn/pcm6120-q1 + https://www.ti.com/lit/gpn/pcm6260-q1 + https://www.ti.com/lit/gpn/pcm9211 + https://www.ti.com/lit/gpn/pcmd3140 + https://www.ti.com/lit/gpn/pcmd3180 + https://www.ti.com/lit/gpn/taa5212 + https://www.ti.com/lit/gpn/tad5212 + +properties: + compatible: + description: | + ti,adc3120: Stereo-channel, 768-kHz, Burr-Brown™ audio analog-to- + digital converter (ADC) with 106-dB SNR. + + ti,adc5120: 2-Channel, 768-kHz, Burr-Brown™ Audio ADC with 120-dB SNR. + + ti,adc6120: Stereo-channel, 768-kHz, Burr-Brown™ audio analog-to- + digital converter (ADC) with 123-dB SNR. + + ti,dix4192: 216-kHz digital audio converter with Quad-Channel In + and One-Channel Out. + + ti,pcm1690: Automotive Catalog 113dB SNR 8-Channel Audio DAC with + Differential Outputs. + + ti,pcm3120: Automotive, stereo, 106-dB SNR, 768-kHz, low-power + software-controlled audio ADC. + + ti,pcm3140: Automotive, Quad-Channel, 768-kHz, Burr-Brown™ Audio ADC + with 106-dB SNR. + + ti,pcm5120: Automotive, stereo, 120-dB SNR, 768-kHz, low-power + software-controlled audio ADC. + + ti,pcm5140: Automotive, Quad-Channel, 768-kHz, Burr-Brown™ Audio ADC + with 120-dB SNR. + + ti,pcm6120: Automotive, stereo, 123-dB SNR, 768-kHz, low-power + software-controlled audio ADC. + + ti,pcm6140: Automotive, Quad-Channel, 768-kHz, Burr-Brown™ Audio ADC + with 123-dB SNR. + + ti,pcm6240: Automotive 4-ch audio ADC with integrated programmable mic + bias, boost and input diagnostics. + + ti,pcm6260: Automotive 6-ch audio ADC with integrated programmable mic + bias, boost and input diagnostics. + + ti,pcm9211: 216-kHz digital audio converter With Stereo ADC and + Routing. + + ti,pcmd3140: Four-channel PDM-input to TDM or I2S output converter. + + ti,pcmd3180: Eight-channel pulse-density-modulation input to TDM or + I2S output converter. + + ti,taa5212: Low-power high-performance stereo audio ADC with 118-dB + dynamic range. + + ti,tad5212: Low-power stereo audio DAC with 120-dB dynamic range. + oneOf: + - items: + - enum: + - ti,adc3120 + - ti,adc5120 + - ti,pcm3120 + - ti,pcm5120 + - ti,pcm6120 + - const: ti,adc6120 + - items: + - enum: + - ti,pcmd512x + - ti,pcm9211 + - ti,taa5212 + - ti,tad5212 + - const: ti,adc6120 + - items: + - enum: + - ti,pcm3140 + - ti,pcm5140 + - ti,dix4192 + - ti,pcm6140 + - ti,pcm6260 + - const: ti,pcm6240 + - items: + - enum: + - ti,pcmd3140 + - ti,pcmd3180 + - ti,pcm1690 + - ti,taa5412 + - ti,tad5412 + - const: ti,pcm6240 + - enum: + - ti,adc6120 + - ti,pcm6240 + + reg: + description: + I2C address, in multiple pcmdevices case, all the i2c address + aggregate as one Audio Device to support multiple audio slots. + minItems: 1 + maxItems: 4 + + reset-gpios: + maxItems: 1 + + interrupts: + maxItems: 1 + description: + Invalid only for ti,pcm1690 because of no INT pin. + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + +allOf: + - $ref: dai-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - ti,pcm1690 + then: + properties: + interrupts: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + /* example for two devices with interrupt support */ + #address-cells = <1>; + #size-cells = <0>; + pcm6240: audio-codec@48 { + compatible = "ti,pcm6240"; + reg = <0x48>, /* primary-device */ + <0x4b>; /* secondary-device */ + #sound-dai-cells = <0>; + reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&gpio1>; + interrupts = <15>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8776.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8776.yaml new file mode 100644 index 000000000000..7bbc96ee81be --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8776.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8776.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8776 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8776 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "wlf,wm8776"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt deleted file mode 100644 index 01d3a7c83419..000000000000 --- a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt +++ /dev/null @@ -1,15 +0,0 @@ -WM8974 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - compatible: "wlf,wm8974" - - reg: the I2C address or SPI chip select number of the device - -Examples: - -codec: wm8974@1a { - compatible = "wlf,wm8974"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8974.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8974.yaml new file mode 100644 index 000000000000..d27300207c67 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8974.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8974.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8974 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8974 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "wlf,wm8974"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wm8776.txt b/Documentation/devicetree/bindings/sound/wm8776.txt deleted file mode 100644 index 01173369c3ed..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8776.txt +++ /dev/null @@ -1,18 +0,0 @@ -WM8776 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8776" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Example: - -wm8776: codec@1a { - compatible = "wlf,wm8776"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/spi/airoha,en7581-snand.yaml b/Documentation/devicetree/bindings/spi/airoha,en7581-snand.yaml new file mode 100644 index 000000000000..b820c5613dcc --- /dev/null +++ b/Documentation/devicetree/bindings/spi/airoha,en7581-snand.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/airoha,en7581-snand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI-NAND flash controller for Airoha ARM SoCs + +maintainers: + - Lorenzo Bianconi <lorenzo@kernel.org> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + const: airoha,en7581-snand + + reg: + items: + - description: spi base address + - description: nfi2spi base address + + clocks: + maxItems: 1 + + clock-names: + items: + - const: spi + +required: + - compatible + - reg + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/en7523-clk.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + spi@1fa10000 { + compatible = "airoha,en7581-snand"; + reg = <0x0 0x1fa10000 0x0 0x140>, + <0x0 0x1fa11000 0x0 0x160>; + + clocks = <&scuclk EN7523_CLK_SPI>; + clock-names = "spi"; + + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "spi-nand"; + reg = <0>; + spi-tx-bus-width = <1>; + spi-rx-bus-width = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml index cca81f89e252..d48ecd6cd5ad 100644 --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml @@ -68,12 +68,13 @@ properties: - items: - enum: - amd,pensando-elba-qspi - - ti,k2g-qspi - - ti,am654-ospi - intel,lgm-qspi - - xlnx,versal-ospi-1.0 - intel,socfpga-qspi + - mobileye,eyeq5-ospi - starfive,jh7110-qspi + - ti,am654-ospi + - ti,k2g-qspi + - xlnx,versal-ospi-1.0 - const: cdns,qspi-nor - const: cdns,qspi-nor @@ -145,7 +146,6 @@ required: - reg - interrupts - clocks - - cdns,fifo-depth - cdns,fifo-width - cdns,trigger-address - '#address-cells' diff --git a/Documentation/devicetree/bindings/spi/marvell,armada-3700-spi.yaml b/Documentation/devicetree/bindings/spi/marvell,armada-3700-spi.yaml new file mode 100644 index 000000000000..61caa1d86188 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/marvell,armada-3700-spi.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/marvell,armada-3700-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Armada 3700 SPI Controller + +description: + The SPI controller on Marvell Armada 3700 SoC. + +maintainers: + - Kousik Sanagavarapu <five231003@gmail.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + const: marvell,armada-3700-spi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + num-cs: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + spi0: spi@10600 { + compatible = "marvell,armada-3700-spi"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x10600 0x5d>; + clocks = <&nb_perih_clk 7>; + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; + num-cs = <4>; + }; +... diff --git a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml index 00acbbb0f65d..49649fc3f95a 100644 --- a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml @@ -54,6 +54,7 @@ properties: - renesas,msiof-r8a779a0 # R-Car V3U - renesas,msiof-r8a779f0 # R-Car S4-8 - renesas,msiof-r8a779g0 # R-Car V4H + - renesas,msiof-r8a779h0 # R-Car V4M - const: renesas,rcar-gen4-msiof # generic R-Car Gen4 # compatible device - items: diff --git a/Documentation/devicetree/bindings/spi/spi-armada-3700.txt b/Documentation/devicetree/bindings/spi/spi-armada-3700.txt deleted file mode 100644 index 1564aa8c02cd..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-armada-3700.txt +++ /dev/null @@ -1,25 +0,0 @@ -* Marvell Armada 3700 SPI Controller - -Required Properties: - -- compatible: should be "marvell,armada-3700-spi" -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: The interrupt number. The interrupt specifier format depends on - the interrupt controller and of its driver. -- clocks: Must contain the clock source, usually from the North Bridge clocks. -- num-cs: The number of chip selects that is supported by this SPI Controller -- #address-cells: should be 1. -- #size-cells: should be 0. - -Example: - - spi0: spi@10600 { - compatible = "marvell,armada-3700-spi"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x10600 0x5d>; - clocks = <&nb_perih_clk 7>; - interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; - num-cs = <4>; - }; diff --git a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml index 8bba965a9ae6..3f1a27efff80 100644 --- a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml @@ -46,6 +46,10 @@ properties: - const: tx - const: rx + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml index 4bd9aeb81208..a55c8633c32c 100644 --- a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml +++ b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml @@ -52,6 +52,10 @@ properties: - const: rx - const: tx + access-controllers: + minItems: 1 + maxItems: 2 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/spi/ti,qspi.yaml b/Documentation/devicetree/bindings/spi/ti,qspi.yaml new file mode 100644 index 000000000000..626a915b3d77 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/ti,qspi.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/ti,qspi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI QSPI controller + +maintainers: + - Kousik Sanagavarapu <five231003@gmail.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + enum: + - ti,am4372-qspi + - ti,dra7xxx-qspi + + reg: + items: + - description: base registers + - description: mapped memory + + reg-names: + items: + - const: qspi_base + - const: qspi_mmap + + clocks: + maxItems: 1 + + clock-names: + items: + - const: fck + + interrupts: + maxItems: 1 + + num-cs: + minimum: 1 + maximum: 4 + default: 1 + + ti,hwmods: + description: + Name of the hwmod associated to the QSPI. This is for legacy + platforms only. + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + + syscon-chipselects: + description: + Handle to system control region containing QSPI chipselect register + and offset of that register. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to system control register + - description: register offset + + spi-max-frequency: + description: Maximum SPI clocking speed of the controller in Hz. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/dra7.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + spi@4b300000 { + compatible = "ti,dra7xxx-qspi"; + reg = <0x4b300000 0x100>, + <0x5c000000 0x4000000>; + reg-names = "qspi_base", "qspi_mmap"; + syscon-chipselects = <&scm_conf 0x558>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&l4per2_clkctrl DRA7_L4PER2_QSPI_CLKCTRL 25>; + clock-names = "fck"; + num-cs = <4>; + spi-max-frequency = <48000000>; + interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>; + }; +... diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt b/Documentation/devicetree/bindings/spi/ti_qspi.txt deleted file mode 100644 index 47b184bce414..000000000000 --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt +++ /dev/null @@ -1,53 +0,0 @@ -TI QSPI controller. - -Required properties: -- compatible : should be "ti,dra7xxx-qspi" or "ti,am4372-qspi". -- reg: Should contain QSPI registers location and length. -- reg-names: Should contain the resource reg names. - - qspi_base: Qspi configuration register Address space - - qspi_mmap: Memory mapped Address space - - (optional) qspi_ctrlmod: Control module Address space -- interrupts: should contain the qspi interrupt number. -- #address-cells, #size-cells : Must be present if the device has sub-nodes -- ti,hwmods: Name of the hwmod associated to the QSPI - -Recommended properties: -- spi-max-frequency: Definition as per - Documentation/devicetree/bindings/spi/spi-bus.txt - -Optional properties: -- syscon-chipselects: Handle to system control region contains QSPI - chipselect register and offset of that register. - -NOTE: TI QSPI controller requires different pinmux and IODelay -parameters for Mode-0 and Mode-3 operations, which needs to be set up by -the bootloader (U-Boot). Default configuration only supports Mode-0 -operation. Hence, "spi-cpol" and "spi-cpha" DT properties cannot be -specified in the slave nodes of TI QSPI controller without appropriate -modification to bootloader. - -Example: - -For am4372: -qspi: qspi@47900000 { - compatible = "ti,am4372-qspi"; - reg = <0x47900000 0x100>, <0x30000000 0x4000000>; - reg-names = "qspi_base", "qspi_mmap"; - #address-cells = <1>; - #size-cells = <0>; - spi-max-frequency = <25000000>; - ti,hwmods = "qspi"; -}; - -For dra7xx: -qspi: qspi@4b300000 { - compatible = "ti,dra7xxx-qspi"; - reg = <0x4b300000 0x100>, - <0x5c000000 0x4000000>, - reg-names = "qspi_base", "qspi_mmap"; - syscon-chipselects = <&scm_conf 0x558>; - #address-cells = <1>; - #size-cells = <0>; - spi-max-frequency = <48000000>; - ti,hwmods = "qspi"; -}; diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml index 20f8f9b3b971..01fccdfc4178 100644 --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml @@ -13,11 +13,13 @@ description: Binding for Amlogic Thermal properties: compatible: - items: - - enum: - - amlogic,g12a-cpu-thermal - - amlogic,g12a-ddr-thermal - - const: amlogic,g12a-thermal + oneOf: + - items: + - enum: + - amlogic,g12a-cpu-thermal + - amlogic,g12a-ddr-thermal + - const: amlogic,g12a-thermal + - const: amlogic,a1-cpu-thermal reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml index b634f57cd011..ca81c8afba79 100644 --- a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml @@ -18,13 +18,15 @@ properties: oneOf: - enum: - loongson,ls2k1000-thermal + - loongson,ls2k2000-thermal - items: - enum: - - loongson,ls2k2000-thermal + - loongson,ls2k0500-thermal - const: loongson,ls2k1000-thermal reg: - maxItems: 1 + minItems: 1 + maxItems: 2 interrupts: maxItems: 1 @@ -38,6 +40,24 @@ required: - interrupts - '#thermal-sensor-cells' +if: + properties: + compatible: + contains: + enum: + - loongson,ls2k2000-thermal + +then: + properties: + reg: + minItems: 2 + maxItems: 2 + +else: + properties: + reg: + maxItems: 1 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml b/Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml index e6665af52ee6..331cf4e662e3 100644 --- a/Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml @@ -19,6 +19,9 @@ properties: compatible: enum: - mediatek,mt7988-lvts-ap + - mediatek,mt8186-lvts + - mediatek,mt8188-lvts-ap + - mediatek,mt8188-lvts-mcu - mediatek,mt8192-lvts-ap - mediatek,mt8192-lvts-mcu - mediatek,mt8195-lvts-ap @@ -60,6 +63,8 @@ allOf: compatible: contains: enum: + - mediatek,mt8188-lvts-ap + - mediatek,mt8188-lvts-mcu - mediatek,mt8192-lvts-ap - mediatek,mt8192-lvts-mcu then: @@ -75,6 +80,7 @@ allOf: compatible: contains: enum: + - mediatek,mt8186-lvts - mediatek,mt8195-lvts-ap - mediatek,mt8195-lvts-mcu then: diff --git a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml index 5ff72ce5c887..1175bb358382 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml @@ -17,10 +17,14 @@ description: properties: compatible: - enum: - - qcom,sc8180x-lmh - - qcom,sdm845-lmh - - qcom,sm8150-lmh + oneOf: + - enum: + - qcom,sc8180x-lmh + - qcom,sdm845-lmh + - qcom,sm8150-lmh + - items: + - const: qcom,qcm2290-lmh + - const: qcom,sm8150-lmh reg: items: diff --git a/Documentation/devicetree/bindings/thermal/st,stih407-thermal.yaml b/Documentation/devicetree/bindings/thermal/st,stih407-thermal.yaml new file mode 100644 index 000000000000..9f6fc5c95c55 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/st,stih407-thermal.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/st,stih407-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STi digital thermal sensor (DTS) + +maintainers: + - Patrice Chotard <patrice.chotard@foss.st.com> + - Lee Jones <lee@kernel.org> + +allOf: + - $ref: thermal-sensor.yaml + +properties: + compatible: + const: st,stih407-thermal + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: thermal + + interrupts: + description: + For thermal sensors for which no interrupt has been defined, a polling + delay of 1000ms will be used to read the temperature from device. + maxItems: 1 + + '#thermal-sensor-cells': + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + temperature-sensor@91a0000 { + compatible = "st,stih407-thermal"; + reg = <0x91a0000 0x28>; + clock-names = "thermal"; + clocks = <&CLK_SYSIN>; + interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>; + #thermal-sensor-cells = <0>; + }; +... diff --git a/Documentation/devicetree/bindings/thermal/st-thermal.txt b/Documentation/devicetree/bindings/thermal/st-thermal.txt deleted file mode 100644 index a2f939137e35..000000000000 --- a/Documentation/devicetree/bindings/thermal/st-thermal.txt +++ /dev/null @@ -1,32 +0,0 @@ -Binding for Thermal Sensor driver for STMicroelectronics STi series of SoCs. - -Required parameters: -------------------- - -compatible : Should be "st,stih407-thermal" - -clock-names : Should be "thermal". - See: Documentation/devicetree/bindings/resource-names.txt -clocks : Phandle of the clock used by the thermal sensor. - See: Documentation/devicetree/bindings/clock/clock-bindings.txt - -Optional parameters: -------------------- - -reg : For non-sysconf based sensors, this should be the physical base - address and length of the sensor's registers. -interrupts : Standard way to define interrupt number. - NB: For thermal sensor's for which no interrupt has been - defined, a polling delay of 1000ms will be used to read the - temperature from device. - -Example: - - temp0@91a0000 { - compatible = "st,stih407-thermal"; - reg = <0x91a0000 0x28>; - clock-names = "thermal"; - clocks = <&CLK_SYSIN>; - interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>; - st,passive_cooling_temp = <110>; - }; diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml index 8b06a681764e..e8c642166462 100644 --- a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml @@ -26,6 +26,7 @@ properties: - renesas,r9a07g043-ostm # RZ/G2UL and RZ/Five - renesas,r9a07g044-ostm # RZ/G2{L,LC} - renesas,r9a07g054-ostm # RZ/V2L + - renesas,r9a09g057-ostm # RZ/V2H(P) - const: renesas,ostm # Generic reg: @@ -58,6 +59,7 @@ if: - renesas,r9a07g043-ostm - renesas,r9a07g044-ostm - renesas,r9a07g054-ostm + - renesas,r9a09g057-ostm then: required: - resets diff --git a/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml index 3ab4434b7352..af7720dc4a12 100644 --- a/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml +++ b/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml @@ -32,6 +32,7 @@ properties: - enum: - infineon,slb9673 - nuvoton,npct75x + - st,st33ktpm2xi2c - const: tcg,tpm-tis-i2c - description: TPM 1.2 and 2.0 chips with vendor-specific I²C interface diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index e07be7bf8395..025d50454f88 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -126,6 +126,8 @@ properties: - ibm,cffps1 # IBM Common Form Factor Power Supply Versions 2 - ibm,cffps2 + # IBM On-Chip Controller hwmon device + - ibm,p8-occ-hwmon # Infineon barometric pressure and temperature sensor - infineon,dps310 # Infineon IR36021 digital POL buck controller @@ -134,6 +136,8 @@ properties: - infineon,irps5401 # Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor - infineon,tlv493d-a1b6 + # Infineon Hot-swap controller xdp710 + - infineon,xdp710 # Infineon Multi-phase Digital VR Controller xdpe11280 - infineon,xdpe11280 # Infineon Multi-phase Digital VR Controller xdpe12254 diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml index b2b509b3944d..720879820f66 100644 --- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml @@ -12,12 +12,10 @@ maintainers: description: | Each Samsung UFS host controller instance should have its own node. -allOf: - - $ref: ufs-common.yaml - properties: compatible: enum: + - google,gs101-ufs - samsung,exynos7-ufs - samsung,exynosautov9-ufs - samsung,exynosautov9-ufs-vh @@ -38,14 +36,24 @@ properties: - const: ufsp clocks: + minItems: 2 items: - description: ufs link core clock - description: unipro main clock + - description: fmp clock + - description: ufs aclk clock + - description: ufs pclk clock + - description: sysreg clock clock-names: + minItems: 2 items: - const: core_clk - const: sclk_unipro_main + - const: fmp + - const: aclk + - const: pclk + - const: sysreg phys: maxItems: 1 @@ -72,6 +80,30 @@ required: - clocks - clock-names +allOf: + - $ref: ufs-common.yaml + - if: + properties: + compatible: + contains: + const: google,gs101-ufs + + then: + properties: + clocks: + minItems: 6 + + clock-names: + minItems: 6 + + else: + properties: + clocks: + maxItems: 2 + + clock-names: + maxItems: 2 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 0a5c98ea711d..88c077673c8b 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -172,6 +172,10 @@ properties: tpl-support: true + access-controllers: + minItems: 1 + maxItems: 2 + dependencies: port: [ usb-role-switch ] role-switch-default-mode: [ usb-role-switch ] diff --git a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml index 2d3589d284b2..0a6e7ac1b37e 100644 --- a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml +++ b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml @@ -33,6 +33,7 @@ properties: - fsl,imx7ulp-usbmisc - fsl,imx8mm-usbmisc - fsl,imx8mn-usbmisc + - fsl,imx8ulp-usbmisc - const: fsl,imx7d-usbmisc - const: fsl,imx6q-usbmisc - items: diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b97d298b3eb6..fbf47f0bacf1 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -151,6 +151,8 @@ patternProperties: description: ARM Ltd. "^armadeus,.*": description: ARMadeus Systems SARL + "^armsom,.*": + description: ArmSoM Technology Co., Ltd. "^arrow,.*": description: Arrow Electronics "^artesyn,.*": @@ -256,6 +258,8 @@ patternProperties: description: Catalyst Semiconductor, Inc. "^cavium,.*": description: Cavium, Inc. + "^cct,.*": + description: Crystal Clear Technology Sdn. Bhd. "^cdns,.*": description: Cadence Design Systems Inc. "^cdtech,.*": @@ -438,6 +442,8 @@ patternProperties: description: Dongguan EmbedFire Electronic Technology Co., Ltd. "^embest,.*": description: Shenzhen Embest Technology Co., Ltd. + "^emcraft,.*": + description: Emcraft Systems "^emlid,.*": description: Emlid, Ltd. "^emmicro,.*": @@ -529,6 +535,8 @@ patternProperties: description: FX Technology Ltd. "^galaxycore,.*": description: GalaxyCore Inc. + "^gameforce,.*": + description: GameForce "^gardena,.*": description: GARDENA GmbH "^gateway,.*": @@ -1627,6 +1635,8 @@ patternProperties: description: Wondermedia Technologies, Inc. "^wobo,.*": description: Wobo + "^wolfvision,.*": + description: WolfVision GmbH "^x-powers,.*": description: X-Powers "^xen,.*": diff --git a/Documentation/doc-guide/parse-headers.rst b/Documentation/doc-guide/parse-headers.rst index 5da0046f7059..204b025f1349 100644 --- a/Documentation/doc-guide/parse-headers.rst +++ b/Documentation/doc-guide/parse-headers.rst @@ -61,7 +61,7 @@ DESCRIPTION *********** -Convert a C header or source file (C_FILE), into a ReStructured Text +Convert a C header or source file (C_FILE), into a reStructuredText included via ..parsed-literal block with cross-references for the documentation files that describe the API. It accepts an optional EXCEPTIONS_FILE with describes what elements will be either ignored or diff --git a/Documentation/driver-api/crypto/iaa/iaa-crypto.rst b/Documentation/driver-api/crypto/iaa/iaa-crypto.rst index de587cf9cbed..f4fba897d931 100644 --- a/Documentation/driver-api/crypto/iaa/iaa-crypto.rst +++ b/Documentation/driver-api/crypto/iaa/iaa-crypto.rst @@ -179,7 +179,9 @@ has the old 'iax' device naming in place) :: # configure wq1.0 - accel-config config-wq --group-id=0 --mode=dedicated --type=kernel --name="iaa_crypto" --device_name="crypto" iax1/wq1.0 + accel-config config-wq --group-id=0 --mode=dedicated --type=kernel --priority=10 --name="iaa_crypto" --driver-name="crypto" iax1/wq1.0 + + accel-config config-engine iax1/engine1.0 --group-id=0 # enable IAA device iax1 @@ -321,33 +323,30 @@ driver will generate statistics which can be accessed in debugfs at:: # ls -al /sys/kernel/debug/iaa-crypto/ total 0 - drwxr-xr-x 2 root root 0 Mar 3 09:35 . - drwx------ 47 root root 0 Mar 3 09:35 .. - -rw-r--r-- 1 root root 0 Mar 3 09:35 max_acomp_delay_ns - -rw-r--r-- 1 root root 0 Mar 3 09:35 max_adecomp_delay_ns - -rw-r--r-- 1 root root 0 Mar 3 09:35 max_comp_delay_ns - -rw-r--r-- 1 root root 0 Mar 3 09:35 max_decomp_delay_ns - -rw-r--r-- 1 root root 0 Mar 3 09:35 stats_reset - -rw-r--r-- 1 root root 0 Mar 3 09:35 total_comp_bytes_out - -rw-r--r-- 1 root root 0 Mar 3 09:35 total_comp_calls - -rw-r--r-- 1 root root 0 Mar 3 09:35 total_decomp_bytes_in - -rw-r--r-- 1 root root 0 Mar 3 09:35 total_decomp_calls - -rw-r--r-- 1 root root 0 Mar 3 09:35 wq_stats - -Most of the above statisticss are self-explanatory. The wq_stats file -shows per-wq stats, a set for each iaa device and wq in addition to -some global stats:: + drwxr-xr-x 2 root root 0 Mar 3 07:55 . + drwx------ 53 root root 0 Mar 3 07:55 .. + -rw-r--r-- 1 root root 0 Mar 3 07:55 global_stats + -rw-r--r-- 1 root root 0 Mar 3 07:55 stats_reset + -rw-r--r-- 1 root root 0 Mar 3 07:55 wq_stats - # cat wq_stats +The global_stats file shows a set of global statistics collected since +the driver has been loaded or reset:: + + # cat global_stats global stats: - total_comp_calls: 100 - total_decomp_calls: 100 - total_comp_bytes_out: 22800 - total_decomp_bytes_in: 22800 + total_comp_calls: 4300 + total_decomp_calls: 4164 + total_sw_decomp_calls: 0 + total_comp_bytes_out: 5993989 + total_decomp_bytes_in: 5993989 total_completion_einval_errors: 0 total_completion_timeout_errors: 0 - total_completion_comp_buf_overflow_errors: 0 + total_completion_comp_buf_overflow_errors: 136 + +The wq_stats file shows per-wq stats, a set for each iaa device and wq +in addition to some global stats:: + # cat wq_stats iaa device: id: 1 n_wqs: 1 @@ -379,21 +378,36 @@ some global stats:: iaa device: id: 5 n_wqs: 1 - comp_calls: 100 - comp_bytes: 22800 - decomp_calls: 100 - decomp_bytes: 22800 + comp_calls: 1360 + comp_bytes: 1999776 + decomp_calls: 0 + decomp_bytes: 0 wqs: name: iaa_crypto - comp_calls: 100 - comp_bytes: 22800 - decomp_calls: 100 - decomp_bytes: 22800 + comp_calls: 1360 + comp_bytes: 1999776 + decomp_calls: 0 + decomp_bytes: 0 -Writing 0 to 'stats_reset' resets all the stats, including the + iaa device: + id: 7 + n_wqs: 1 + comp_calls: 2940 + comp_bytes: 3994213 + decomp_calls: 4164 + decomp_bytes: 5993989 + wqs: + name: iaa_crypto + comp_calls: 2940 + comp_bytes: 3994213 + decomp_calls: 4164 + decomp_bytes: 5993989 + ... + +Writing to 'stats_reset' resets all the stats, including the per-device and per-wq stats:: - # echo 0 > stats_reset + # echo 1 > stats_reset # cat wq_stats global stats: total_comp_calls: 0 @@ -536,12 +550,20 @@ The below script automatically does that:: echo "End Disable IAA" + echo "Reload iaa_crypto module" + + rmmod iaa_crypto + modprobe iaa_crypto + + echo "End Reload iaa_crypto module" + # # configure iaa wqs and devices # echo "Configure IAA" for ((i = 1; i < ${num_iaa} * 2; i += 2)); do - accel-config config-wq --group-id=0 --mode=dedicated --size=128 --priority=10 --type=kernel --name="iaa_crypto" --driver_name="crypto" iax${i}/wq${i} + accel-config config-wq --group-id=0 --mode=dedicated --wq-size=128 --priority=10 --type=kernel --name="iaa_crypto" --driver-name="crypto" iax${i}/wq${i}.0 + accel-config config-engine iax${i}/engine${i}.0 --group-id=0 done echo "End Configure IAA" @@ -552,10 +574,10 @@ The below script automatically does that:: echo "Enable IAA" for ((i = 1; i < ${num_iaa} * 2; i += 2)); do - echo enable iaa iaa${i} - accel-config enable-device iaa${i} - echo enable wq iaa${i}/wq${i}.0 - accel-config enable-wq iaa${i}/wq${i}.0 + echo enable iaa iax${i} + accel-config enable-device iax${i} + echo enable wq iax${i}/wq${i}.0 + accel-config enable-wq iax${i}/wq${i}.0 done echo "End Enable IAA" diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 0c153d79ccc4..29abf1eebf9f 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -77,7 +77,7 @@ consider though: the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other llseek operation will report -EINVAL. - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all + If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE for all cases. Userspace can use this to detect support for discovering the dma-buf size using llseek. diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 7be8b8dd5f00..18caebad7376 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -433,6 +433,7 @@ REGULATOR devm_regulator_bulk_put() devm_regulator_get() devm_regulator_get_enable() + devm_regulator_get_enable_read_voltage() devm_regulator_get_enable_optional() devm_regulator_get_exclusive() devm_regulator_get_optional() diff --git a/Documentation/driver-api/eisa.rst b/Documentation/driver-api/eisa.rst index 3eac11b7eb01..b33ebe1ec9ed 100644 --- a/Documentation/driver-api/eisa.rst +++ b/Documentation/driver-api/eisa.rst @@ -196,8 +196,8 @@ eisa_bus.disable_dev virtual_root.force_probe Force the probing code to probe EISA slots even when it cannot find an EISA compliant mainboard (nothing appears on slot 0). Defaults to 0 - (don't force), and set to 1 (force probing) when either - CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set. + (don't force), and set to 1 (force probing) when + CONFIG_EISA_VLB_PRIMING is set. Random notes ============ diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index bf6319cc531b..e541bd2e898b 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -7,7 +7,7 @@ This document serves as a guide for writers of GPIO chip drivers. Each GPIO controller driver needs to include the following header, which defines the structures used to define a GPIO driver:: - #include <linux/gpio/driver.h> + #include <linux/gpio/driver.h> Internal Representation of GPIOs @@ -144,7 +144,7 @@ is not open, it will present a high-impedance (tristate) to the external rail:: in ----|| |/ ||--+ in ----| | |\ - GND GND + GND GND This configuration is normally used as a way to achieve one of two things: @@ -550,10 +550,10 @@ the interrupt separately and go with it: struct my_gpio *g; struct gpio_irq_chip *girq; - ret = devm_request_threaded_irq(dev, irq, NULL, - irq_thread_fn, IRQF_ONESHOT, "my-chip", g); + ret = devm_request_threaded_irq(dev, irq, NULL, irq_thread_fn, + IRQF_ONESHOT, "my-chip", g); if (ret < 0) - return ret; + return ret; /* Get a pointer to the gpio_irq_chip */ girq = &g->gc.irq; @@ -681,12 +681,12 @@ certain operations and keep track of usage inside of the gpiolib subsystem. Input GPIOs can be used as IRQ signals. When this happens, a driver is requested to mark the GPIO as being used as an IRQ:: - int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset) + int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset) This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock is released:: - void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset) + void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset) When implementing an irqchip inside a GPIO driver, these two functions should typically be called in the .startup() and .shutdown() callbacks from the @@ -708,12 +708,12 @@ When a GPIO is used as an IRQ signal, then gpiolib also needs to know if the IRQ is enabled or disabled. In order to inform gpiolib about this, the irqchip driver should call:: - void gpiochip_disable_irq(struct gpio_chip *chip, unsigned int offset) + void gpiochip_disable_irq(struct gpio_chip *chip, unsigned int offset) This allows drivers to drive the GPIO as an output while the IRQ is disabled. When the IRQ is enabled again, a driver should call:: - void gpiochip_enable_irq(struct gpio_chip *chip, unsigned int offset) + void gpiochip_enable_irq(struct gpio_chip *chip, unsigned int offset) When implementing an irqchip inside a GPIO driver, these two functions should typically be called in the .irq_disable() and .irq_enable() callbacks from the @@ -763,12 +763,12 @@ Sometimes it is useful to allow a GPIO chip driver to request its own GPIO descriptors through the gpiolib API. A GPIO driver can use the following functions to request and free descriptors:: - struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc, - u16 hwnum, - const char *label, - enum gpiod_flags flags) + struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc, + u16 hwnum, + const char *label, + enum gpiod_flags flags) - void gpiochip_free_own_desc(struct gpio_desc *desc) + void gpiochip_free_own_desc(struct gpio_desc *desc) Descriptors requested with gpiochip_request_own_desc() must be released with gpiochip_free_own_desc(). diff --git a/Documentation/driver-api/gpio/legacy.rst b/Documentation/driver-api/gpio/legacy.rst index b6505914791c..534dfe95d128 100644 --- a/Documentation/driver-api/gpio/legacy.rst +++ b/Documentation/driver-api/gpio/legacy.rst @@ -225,8 +225,6 @@ setup or driver probe/teardown code, so this is an easy constraint.):: gpio_request() ## gpio_request_one() - ## gpio_request_array() - ## gpio_free_array() gpio_free() @@ -295,14 +293,6 @@ are claimed, three additional calls are defined:: */ int gpio_request_one(unsigned gpio, unsigned long flags, const char *label); - /* request multiple GPIOs in a single call - */ - int gpio_request_array(struct gpio *array, size_t num); - - /* release multiple GPIOs in a single call - */ - void gpio_free_array(struct gpio *array, size_t num); - where 'flags' is currently defined to specify the following properties: * GPIOF_DIR_IN - to configure direction as input @@ -341,12 +331,6 @@ A typical example of usage:: if (err) ... - err = gpio_request_array(leds_gpios, ARRAY_SIZE(leds_gpios)); - if (err) - ... - - gpio_free_array(leds_gpios, ARRAY_SIZE(leds_gpios)); - GPIOs mapped to IRQs -------------------- diff --git a/Documentation/driver-api/mtd/nand_ecc.rst b/Documentation/driver-api/mtd/nand_ecc.rst index 74347c14a70b..a0d681f26a2e 100644 --- a/Documentation/driver-api/mtd/nand_ecc.rst +++ b/Documentation/driver-api/mtd/nand_ecc.rst @@ -462,7 +462,7 @@ statements is reduced. This is also reflected in the assembly code. Analysis 3 ========== -Very weird. Guess it has to do with caching or instruction parallellism +Very weird. Guess it has to do with caching or instruction parallelism or so. I also tried on an eeePC (Celeron, clocked at 900 Mhz). Interesting observation was that this one is only 30% slower (according to time) executing the code as my 3Ghz D920 processor. diff --git a/Documentation/driver-api/scsi.rst b/Documentation/driver-api/scsi.rst index 64b231d125e0..273281474c09 100644 --- a/Documentation/driver-api/scsi.rst +++ b/Documentation/driver-api/scsi.rst @@ -20,7 +20,7 @@ Although the old parallel (fast/wide/ultra) SCSI bus has largely fallen out of use, the SCSI command set is more widely used than ever to communicate with devices over a number of different busses. -The `SCSI protocol <http://www.t10.org/scsi-3.htm>`__ is a big-endian +The `SCSI protocol <https://www.t10.org/scsi-3.htm>`__ is a big-endian peer-to-peer packet based protocol. SCSI commands are 6, 10, 12, or 16 bytes long, often followed by an associated data payload. @@ -28,8 +28,7 @@ SCSI commands can be transported over just about any kind of bus, and are the default protocol for storage devices attached to USB, SATA, SAS, Fibre Channel, FireWire, and ATAPI devices. SCSI packets are also commonly exchanged over Infiniband, -`I2O <http://i2o.shadowconnect.com/faq.php>`__, TCP/IP -(`iSCSI <https://en.wikipedia.org/wiki/ISCSI>`__), even `Parallel +TCP/IP (`iSCSI <https://en.wikipedia.org/wiki/ISCSI>`__), even `Parallel ports <http://cyberelk.net/tim/parport/parscsi.html>`__. Design of the Linux SCSI subsystem @@ -170,9 +169,9 @@ drivers/scsi/scsi_netlink.c Infrastructure to provide async events from transports to userspace via netlink, using a single NETLINK_SCSITRANSPORT protocol for all -transports. See `the original patch -submission <http://marc.info/?l=linux-scsi&m=115507374832500&w=2>`__ for -more details. +transports. See `the original patch submission +<https://lore.kernel.org/linux-scsi/1155070439.6275.5.camel@localhost.localdomain/>`__ +for more details. .. kernel-doc:: drivers/scsi/scsi_netlink.c :internal: @@ -259,7 +258,7 @@ attributes for Serial Attached SCSI, a variant of SATA aimed at large high-end systems. The SAS transport class contains common code to deal with SAS HBAs, an -aproximated representation of SAS topologies in the driver model, and +approximated representation of SAS topologies in the driver model, and various sysfs attributes to expose these topologies and management interfaces to userspace. @@ -328,11 +327,11 @@ the ordinary is seen. To be more realistic, the simulated devices have the transport attributes of SAS disks. -For documentation see http://sg.danny.cz/sg/sdebug26.html +For documentation see http://sg.danny.cz/sg/scsi_debug.html todo ~~~~ Parallel (fast/wide/ultra) SCSI, USB, SATA, SAS, Fibre Channel, -FireWire, ATAPI devices, Infiniband, I2O, Parallel ports, +FireWire, ATAPI devices, Infiniband, Parallel ports, netlink... diff --git a/Documentation/driver-api/usb/usb.rst b/Documentation/driver-api/usb/usb.rst index fb41768696ec..89f9c37bb979 100644 --- a/Documentation/driver-api/usb/usb.rst +++ b/Documentation/driver-api/usb/usb.rst @@ -422,7 +422,7 @@ USBDEVFS_CONNECTINFO USBDEVFS_GET_SPEED Returns the speed of the device. The speed is returned as a - nummerical value in accordance with enum usb_device_speed + numerical value in accordance with enum usb_device_speed File modification time is not updated by this request. diff --git a/Documentation/driver-api/wbrf.rst b/Documentation/driver-api/wbrf.rst index f48bfa029813..6b18833e2e69 100644 --- a/Documentation/driver-api/wbrf.rst +++ b/Documentation/driver-api/wbrf.rst @@ -68,7 +68,7 @@ The expected flow for the consumers: can be enabled for the device. 2. Call `amd_wbrf_register_notifier` to register for notification of frequency band change(add or remove) from other producers. -3. Call the `amd_wbrf_retrieve_freq_band` initally to retrieve +3. Call the `amd_wbrf_retrieve_freq_band` initially to retrieve current active frequency bands considering some producers may broadcast such information before the consumer is up. 4. On receiving a notification for frequency band change, run diff --git a/Documentation/filesystems/directory-locking.rst b/Documentation/filesystems/directory-locking.rst index 05ea387bc9fb..6fdf0b02df43 100644 --- a/Documentation/filesystems/directory-locking.rst +++ b/Documentation/filesystems/directory-locking.rst @@ -44,7 +44,7 @@ For our purposes all operations fall in 6 classes: * decide which of the source and target need to be locked. The source needs to be locked if it's a non-directory, target - if it's a non-directory or about to be removed. - * take the locks that need to be taken (exlusive), in inode pointer order + * take the locks that need to be taken (exclusive), in inode pointer order if need to take both (that can happen only when both source and target are non-directories - the source because it wouldn't need to be locked otherwise and the target because mixing directory and non-directory is @@ -234,7 +234,7 @@ among the children, in some order. But that is also impossible, since neither of the children is a descendent of another. That concludes the proof, since the set of operations with the -properties requiered for a minimal deadlock can not exist. +properties required for a minimal deadlock can not exist. Note that the check for having a common ancestor in cross-directory rename is crucial - without it a deadlock would be possible. Indeed, diff --git a/Documentation/filesystems/efivarfs.rst b/Documentation/filesystems/efivarfs.rst index 0551985821b8..f646c3f0980f 100644 --- a/Documentation/filesystems/efivarfs.rst +++ b/Documentation/filesystems/efivarfs.rst @@ -40,4 +40,4 @@ accidentally. *See also:* - Documentation/admin-guide/acpi/ssdt-overlays.rst -- Documentation/ABI/stable/sysfs-firmware-efi-vars +- Documentation/ABI/removed/sysfs-firmware-efi-vars diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 1be76ef117b3..f2b44c2400c6 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -858,7 +858,7 @@ be misspelled d_alloc_anon(). **mandatory** -[should've been added in 2016] stale comment in finish_open() nonwithstanding, +[should've been added in 2016] stale comment in finish_open() notwithstanding, failure exits in ->atomic_open() instances should *NOT* fput() the file, no matter what. Everything is handled by the caller. @@ -989,7 +989,7 @@ This mechanism would only work for a single device so the block layer couldn't find the owning superblock of any additional devices. In the old mechanism reusing or creating a superblock for a racing mount(2) and -umount(2) relied on the file_system_type as the holder. This was severly +umount(2) relied on the file_system_type as the holder. This was severely underdocumented however: (1) Any concurrent mounter that managed to grab an active reference on an diff --git a/Documentation/firmware-guide/acpi/namespace.rst b/Documentation/firmware-guide/acpi/namespace.rst index 4ef963679a3d..5021843b526b 100644 --- a/Documentation/firmware-guide/acpi/namespace.rst +++ b/Documentation/firmware-guide/acpi/namespace.rst @@ -15,7 +15,7 @@ ACPI Device Tree - Representation of ACPI Namespace Abstract ======== The Linux ACPI subsystem converts ACPI namespace objects into a Linux -device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon +device tree under the /sys/devices/LNXSYSTM:00 and updates it upon receiving ACPI hotplug notification events. For each device object in this hierarchy there is a corresponding symbolic link in the /sys/bus/acpi/devices. @@ -326,7 +326,7 @@ example ACPI namespace illustrated in Figure 2 with the addition of fixed PWR_BUTTON/SLP_BUTTON devices is shown below:: +--------------+---+-----------------+ - | LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: | + | LNXSYSTM:00 | \ | acpi:LNXSYSTM: | +--------------+---+-----------------+ | | +-------------+-----+----------------+ diff --git a/Documentation/gpu/amdgpu/debugging.rst b/Documentation/gpu/amdgpu/debugging.rst new file mode 100644 index 000000000000..e75f97d0e4ea --- /dev/null +++ b/Documentation/gpu/amdgpu/debugging.rst @@ -0,0 +1,80 @@ +=============== + GPU Debugging +=============== + +GPUVM Debugging +=============== + +To aid in debugging GPU virtual memory related problems, the driver supports a +number of options module parameters: + +`vm_fault_stop` - If non-0, halt the GPU memory controller on a GPU page fault. + +`vm_update_mode` - If non-0, use the CPU to update GPU page tables rather than +the GPU. + + +Decoding a GPUVM Page Fault +=========================== + +If you see a GPU page fault in the kernel log, you can decode it to figure +out what is going wrong in your application. A page fault in your kernel +log may look something like this: + +:: + + [gfxhub0] no-retry page fault (src_id:0 ring:24 vmid:3 pasid:32777, for process glxinfo pid 2424 thread glxinfo:cs0 pid 2425) + in page starting at address 0x0000800102800000 from IH client 0x1b (UTCL2) + VM_L2_PROTECTION_FAULT_STATUS:0x00301030 + Faulty UTCL2 client ID: TCP (0x8) + MORE_FAULTS: 0x0 + WALKER_ERROR: 0x0 + PERMISSION_FAULTS: 0x3 + MAPPING_ERROR: 0x0 + RW: 0x0 + +First you have the memory hub, gfxhub and mmhub. gfxhub is the memory +hub used for graphics, compute, and sdma on some chips. mmhub is the +memory hub used for multi-media and sdma on some chips. + +Next you have the vmid and pasid. If the vmid is 0, this fault was likely +caused by the kernel driver or firmware. If the vmid is non-0, it is generally +a fault in a user application. The pasid is used to link a vmid to a system +process id. If the process is active when the fault happens, the process +information will be printed. + +The GPU virtual address that caused the fault comes next. + +The client ID indicates the GPU block that caused the fault. +Some common client IDs: + +- CB/DB: The color/depth backend of the graphics pipe +- CPF: Command Processor Frontend +- CPC: Command Processor Compute +- CPG: Command Processor Graphics +- TCP/SQC/SQG: Shaders +- SDMA: SDMA engines +- VCN: Video encode/decode engines +- JPEG: JPEG engines + +PERMISSION_FAULTS describe what faults were encountered: + +- bit 0: the PTE was not valid +- bit 1: the PTE read bit was not set +- bit 2: the PTE write bit was not set +- bit 3: the PTE execute bit was not set + +Finally, RW, indicates whether the access was a read (0) or a write (1). + +In the example above, a shader (cliend id = TCP) generated a read (RW = 0x0) to +an invalid page (PERMISSION_FAULTS = 0x3) at GPU virtual address +0x0000800102800000. The user can then inspect their shader code and resource +descriptor state to determine what caused the GPU page fault. + +UMR +=== + +`umr <https://gitlab.freedesktop.org/tomstdenis/umr>`_ is a general purpose +GPU debugging and diagnostics tool. Please see the umr +`documentation <https://umr.readthedocs.io/en/main/>`_ for more information +about its capabilities. diff --git a/Documentation/gpu/amdgpu/display/display-contributing.rst b/Documentation/gpu/amdgpu/display/display-contributing.rst index fdb2bea01d53..36f3077eee00 100644 --- a/Documentation/gpu/amdgpu/display/display-contributing.rst +++ b/Documentation/gpu/amdgpu/display/display-contributing.rst @@ -135,7 +135,7 @@ Enable underlay --------------- AMD display has this feature called underlay (which you can read more about at -'Documentation/GPU/amdgpu/display/mpo-overview.rst') which is intended to +'Documentation/gpu/amdgpu/display/mpo-overview.rst') which is intended to save power when playing a video. The basic idea is to put a video in the underlay plane at the bottom and the desktop in the plane above it with a hole in the video area. This feature is enabled in ChromeOS, and from our data diff --git a/Documentation/gpu/amdgpu/index.rst b/Documentation/gpu/amdgpu/index.rst index 912e699fd373..847e04924030 100644 --- a/Documentation/gpu/amdgpu/index.rst +++ b/Documentation/gpu/amdgpu/index.rst @@ -15,4 +15,5 @@ Next (GCN), Radeon DNA (RDNA), and Compute DNA (CDNA) architectures. ras thermal driver-misc + debugging amdgpu-glossary diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst index e5070a0e95ab..971cdb4816fc 100644 --- a/Documentation/gpu/driver-uapi.rst +++ b/Documentation/gpu/driver-uapi.rst @@ -18,6 +18,11 @@ VM_BIND / EXEC uAPI .. kernel-doc:: include/uapi/drm/nouveau_drm.h +drm/panthor uAPI +================ + +.. kernel-doc:: include/uapi/drm/panthor_drm.h + drm/xe uAPI =========== diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 13d3627d8bc0..abfe220764e1 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -398,6 +398,21 @@ Plane Damage Tracking Functions Reference .. kernel-doc:: include/drm/drm_damage_helper.h :internal: +Plane Panic Feature +------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_panic.c + :doc: overview + +Plane Panic Functions Reference +------------------------------- + +.. kernel-doc:: include/drm/drm_panic.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_panic.c + :export: + Display Modes Function Reference ================================ @@ -496,6 +511,13 @@ addition to the one mentioned above: * An IGT test must be submitted where reasonable. +For historical reasons, non-standard, driver-specific properties exist. If a KMS +driver wants to add support for one of those properties, the requirements for +new properties apply where possible. Additionally, the documented behavior must +match the de facto semantics of the existing property to ensure compatibility. +Developers of the driver that first added the property should help with those +tasks and must ACK the documented behavior if possible. + Property Types and Blob Property Support ---------------------------------------- diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 0ca1550fd9dc..17261ba18313 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -204,6 +204,15 @@ DMC Firmware Support .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c :internal: +DMC wakelock support +-------------------- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c + :doc: DMC wakelock support + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c + :internal: + Video BIOS Table (VBT) ---------------------- diff --git a/Documentation/gpu/panfrost.rst b/Documentation/gpu/panfrost.rst index b80e41f4b2c5..51ba375fd80d 100644 --- a/Documentation/gpu/panfrost.rst +++ b/Documentation/gpu/panfrost.rst @@ -38,3 +38,12 @@ the currently possible format options: Possible `drm-engine-` key names are: `fragment`, and `vertex-tiler`. `drm-curfreq-` values convey the current operating frequency for that engine. + +Users must bear in mind that engine and cycle sampling are disabled by default, +because of power saving concerns. `fdinfo` users and benchmark applications which +query the fdinfo file must make sure to toggle the job profiling status of the +driver by writing into the appropriate sysfs node:: + + echo <N> > /sys/bus/platform/drivers/panfrost/[a-f0-9]*.gpu/profiling + +Where `N` is either `0` or `1`, depending on the desired enablement status. diff --git a/Documentation/gpu/rfc/i915_vm_bind.h b/Documentation/gpu/rfc/i915_vm_bind.h index 8a8fcd4fceac..bc26dc126104 100644 --- a/Documentation/gpu/rfc/i915_vm_bind.h +++ b/Documentation/gpu/rfc/i915_vm_bind.h @@ -93,12 +93,11 @@ struct drm_i915_gem_timeline_fence { * Multiple VA mappings can be created to the same section of the object * (aliasing). * - * The @start, @offset and @length must be 4K page aligned. However the DG2 - * and XEHPSDV has 64K page size for device local memory and has compact page - * table. On those platforms, for binding device local-memory objects, the - * @start, @offset and @length must be 64K aligned. Also, UMDs should not mix - * the local memory 64K page and the system memory 4K page bindings in the same - * 2M range. + * The @start, @offset and @length must be 4K page aligned. However the DG2 has + * 64K page size for device local memory and has compact page table. On that + * platform, for binding device local-memory objects, the @start, @offset and + * @length must be 64K aligned. Also, UMDs should not mix the local memory 64K + * page and the system memory 4K page bindings in the same 2M range. * * Error code -EINVAL will be returned if @start, @offset and @length are not * properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), error code diff --git a/Documentation/hid/hid-bpf.rst b/Documentation/hid/hid-bpf.rst index 4fad83a6ebc3..0765b3298ecf 100644 --- a/Documentation/hid/hid-bpf.rst +++ b/Documentation/hid/hid-bpf.rst @@ -179,7 +179,7 @@ Available API that can be used in syscall HID-BPF programs: ----------------------------------------------------------- .. kernel-doc:: drivers/hid/bpf/hid_bpf_dispatch.c - :functions: hid_bpf_attach_prog hid_bpf_hw_request hid_bpf_allocate_context hid_bpf_release_context + :functions: hid_bpf_attach_prog hid_bpf_hw_request hid_bpf_hw_output_report hid_bpf_input_report hid_bpf_allocate_context hid_bpf_release_context General overview of a HID-BPF program ===================================== diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst index 42dc77b7b10f..55cbaa719a79 100644 --- a/Documentation/hid/intel-ish-hid.rst +++ b/Documentation/hid/intel-ish-hid.rst @@ -18,8 +18,8 @@ These ISH also comply to HID sensor specification, but the difference is the transport protocol used for communication. The current external sensor hubs mainly use HID over I2C or USB. But ISH doesn't use either I2C or USB. -1. Overview -=========== +Overview +======== Using a analogy with a usbhid implementation, the ISH follows a similar model for a very high speed communication:: @@ -58,8 +58,8 @@ implemented as a bus. Each client application executing in the ISH processor is registered as a device on this bus. The driver, which binds each device (ISH HID driver) identifies the device type and registers with the HID core. -2. ISH Implementation: Block Diagram -==================================== +ISH Implementation: Block Diagram +================================= :: @@ -96,27 +96,27 @@ is registered as a device on this bus. The driver, which binds each device | ISH Hardware/Firmware(FW) | ---------------------------- -3. High level processing in above blocks -======================================== +High level processing in above blocks +===================================== -3.1 Hardware Interface ----------------------- +Hardware Interface +------------------ The ISH is exposed as "Non-VGA unclassified PCI device" to the host. The PCI product and vendor IDs are changed from different generations of processors. So the source code which enumerates drivers needs to update from generation to generation. -3.2 Inter Processor Communication (IPC) driver ----------------------------------------------- +Inter Processor Communication (IPC) driver +------------------------------------------ Location: drivers/hid/intel-ish-hid/ipc The IPC message uses memory mapped I/O. The registers are defined in hw-ish-regs.h. -3.2.1 IPC/FW message types -^^^^^^^^^^^^^^^^^^^^^^^^^^ +IPC/FW message types +^^^^^^^^^^^^^^^^^^^^ There are two types of messages, one for management of link and another for messages to and from transport layers. @@ -142,20 +142,20 @@ register has the following format:: Bit 31: doorbell trigger (signal H/W interrupt to the other side) Other bits are reserved, should be 0. -3.2.2 Transport layer interface -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Transport layer interface +^^^^^^^^^^^^^^^^^^^^^^^^^ To abstract HW level IPC communication, a set of callbacks is registered. The transport layer uses them to send and receive messages. Refer to struct ishtp_hw_ops for callbacks. -3.3 ISH Transport layer ------------------------ +ISH Transport layer +------------------- Location: drivers/hid/intel-ish-hid/ishtp/ -3.3.1 A Generic Transport Layer -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +A Generic Transport Layer +^^^^^^^^^^^^^^^^^^^^^^^^^ The transport layer is a bi-directional protocol, which defines: - Set of commands to start, stop, connect, disconnect and flow control @@ -166,8 +166,8 @@ This protocol resembles bus messages described in the following document: http://www.intel.com/content/dam/www/public/us/en/documents/technical-\ specifications/dcmi-hi-1-0-spec.pdf "Chapter 7: Bus Message Layer" -3.3.2 Connection and Flow Control Mechanism -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Connection and Flow Control Mechanism +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Each FW client and a protocol is identified by a UUID. In order to communicate to a FW client, a connection must be established using connect request and @@ -181,8 +181,8 @@ before receiving the next flow control credit. Either side can send disconnect request bus message to end communication. Also the link will be dropped if major FW reset occurs. -3.3.3 Peer to Peer data transfer -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Peer to Peer data transfer +^^^^^^^^^^^^^^^^^^^^^^^^^^ Peer to Peer data transfer can happen with or without using DMA. Depending on the sensor bandwidth requirement DMA can be enabled by using module parameter @@ -217,8 +217,8 @@ In principle, multiple DMA_XFER and DMA_XFER_ACK messages may be sent at once Currently, ISH FW decides to send over DMA if ISHTP message is more than 3 IPC fragments and via IPC otherwise. -3.3.4 Ring Buffers -^^^^^^^^^^^^^^^^^^ +Ring Buffers +^^^^^^^^^^^^ When a client initiates a connection, a ring of RX and TX buffers is allocated. The size of ring can be specified by the client. HID client sets 16 and 32 for @@ -228,8 +228,8 @@ bus message protocol. These buffers are required because the FW may have not have processed the last message and may not have enough flow control credits to send. Same thing holds true on receive side and flow control is required. -3.3.5 Host Enumeration -^^^^^^^^^^^^^^^^^^^^^^ +Host Enumeration +^^^^^^^^^^^^^^^^ The host enumeration bus command allows discovery of clients present in the FW. There can be multiple sensor clients and clients for calibration function. @@ -252,8 +252,8 @@ Enumeration sequence of messages: - Once host received properties for that last discovered client, it considers ISHTP device fully functional (and allocates DMA buffers) -3.4 HID over ISH Client ------------------------ +HID over ISH Client +------------------- Location: drivers/hid/intel-ish-hid @@ -265,16 +265,16 @@ The ISHTP client driver is responsible for: - Process Get/Set feature request - Get input reports -3.5 HID Sensor Hub MFD and IIO sensor drivers ---------------------------------------------- +HID Sensor Hub MFD and IIO sensor drivers +----------------------------------------- The functionality in these drivers is the same as an external sensor hub. Refer to Documentation/hid/hid-sensor.rst for HID sensor Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space. -3.6 End to End HID transport Sequence Diagram ---------------------------------------------- +End to End HID transport Sequence Diagram +----------------------------------------- :: @@ -339,16 +339,81 @@ Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space. | | | | -3.7 ISH Debugging ------------------ +ISH Firmware Loading from Host Flow +----------------------------------- + +Starting from the Lunar Lake generation, the ISH firmware has been divided into two components for better space optimization and increased flexibility. These components include a bootloader that is integrated into the BIOS, and a main firmware that is stored within the operating system's file system. + +The process works as follows: + +- Initially, the ISHTP driver sends a command, HOST_START_REQ_CMD, to the ISH bootloader. In response, the bootloader sends back a HOST_START_RES_CMD. This response includes the ISHTP_SUPPORT_CAP_LOADER bit. Subsequently, the ISHTP driver checks if this bit is set. If it is, the firmware loading process from the host begins. + +- During this process, the ISHTP driver first invokes the request_firmware() function, followed by sending a LOADER_CMD_XFER_QUERY command. Upon receiving a response from the bootloader, the ISHTP driver sends a LOADER_CMD_XFER_FRAGMENT command. After receiving another response, the ISHTP driver sends a LOADER_CMD_START command. The bootloader responds and then proceeds to the Main Firmware. + +- After the process concludes, the ISHTP driver calls the release_firmware() function. + +For more detailed information, please refer to the flow descriptions provided below: + +:: + + +---------------+ +-----------------+ + | ISHTP Driver | | ISH Bootloader | + +---------------+ +-----------------+ + | | + |~~~Send HOST_START_REQ_CMD~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| + | | + |<--Send HOST_START_RES_CMD(Includes ISHTP_SUPPORT_CAP_LOADER bit)----| + | | + **************************************************************************************** + * if ISHTP_SUPPORT_CAP_LOADER bit is set * + **************************************************************************************** + | | + |~~~start loading firmware from host process~~~+ | + | | | + |<---------------------------------------------+ | + | | + --------------------------- | + | Call request_firmware() | | + --------------------------- | + | | + |~~~Send LOADER_CMD_XFER_QUERY~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| + | | + |<--Send response-----------------------------------------------------| + | | + |~~~Send LOADER_CMD_XFER_FRAGMENT~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| + | | + |<--Send response-----------------------------------------------------| + | | + |~~~Send LOADER_CMD_START~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| + | | + |<--Send response-----------------------------------------------------| + | | + | |~~~Jump to Main Firmware~~~+ + | | | + | |<--------------------------+ + | | + --------------------------- | + | Call release_firmware() | | + --------------------------- | + | | + **************************************************************************************** + * end if * + **************************************************************************************** + | | + +---------------+ +-----------------+ + | ISHTP Driver | | ISH Bootloader | + +---------------+ +-----------------+ + +ISH Debugging +------------- To debug ISH, event tracing mechanism is used. To enable debug logs:: echo 1 > /sys/kernel/tracing/events/intel_ish/enable cat /sys/kernel/tracing/trace -3.8 ISH IIO sysfs Example on Lenovo thinkpad Yoga 260 ------------------------------------------------------ +ISH IIO sysfs Example on Lenovo thinkpad Yoga 260 +------------------------------------------------- :: diff --git a/Documentation/hwmon/adm1275.rst b/Documentation/hwmon/adm1275.rst index 804590eeabdc..467daf8ce3c5 100644 --- a/Documentation/hwmon/adm1275.rst +++ b/Documentation/hwmon/adm1275.rst @@ -43,6 +43,14 @@ Supported chips: Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1278.pdf + * Analog Devices ADM1281 + + Prefix: 'adm1281' + + Addresses scanned: - + + Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/adm1281.pdf + * Analog Devices ADM1293/ADM1294 Prefix: 'adm1293', 'adm1294' @@ -58,10 +66,10 @@ Description ----------- This driver supports hardware monitoring for Analog Devices ADM1075, ADM1272, -ADM1275, ADM1276, ADM1278, ADM1293, and ADM1294 Hot-Swap Controller and +ADM1275, ADM1276, ADM1278, ADM1281, ADM1293, and ADM1294 Hot-Swap Controller and Digital Power Monitors. -ADM1075, ADM1272, ADM1275, ADM1276, ADM1278, ADM1293, and ADM1294 are hot-swap +ADM1075, ADM1272, ADM1275, ADM1276, ADM1278, ADM1281, ADM1293, and ADM1294 are hot-swap controllers that allow a circuit board to be removed from or inserted into a live backplane. They also feature current and voltage readback via an integrated 12 bit analog-to-digital converter (ADC), accessed using a @@ -144,5 +152,5 @@ temp1_highest Highest observed temperature. temp1_reset_history Write any value to reset history. Temperature attributes are supported on ADM1272 and - ADM1278. + ADM1278, and ADM1281. ======================= ======================================================= diff --git a/Documentation/hwmon/adp1050.rst b/Documentation/hwmon/adp1050.rst new file mode 100644 index 000000000000..8fa937064886 --- /dev/null +++ b/Documentation/hwmon/adp1050.rst @@ -0,0 +1,64 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver adp1050 +===================== + +Supported chips: + + * Analog Devices ADP1050 + + Prefix: 'adp1050' + + Addresses scanned: I2C 0x70 - 0x77 + + Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADP1050.pdf + +Authors: + + - Radu Sabau <radu.sabau@analog.com> + + +Description +----------- + +This driver supprts hardware monitoring for Analog Devices ADP1050 Digital +Controller for Isolated Power Supply with PMBus interface. + +The ADP1050 is an advanced digital controller with a PMBus™ +interface targeting high density, high efficiency dc-to-dc power +conversion used to monitor system temperatures, voltages and currents. +Through the PMBus interface, the device can monitor input/output voltages, +input current and temperature. + +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. + +Platform data support +--------------------- + +The driver supports standard PMBus driver platform data. + +Sysfs Attributes +---------------- + +================= ======================================== +in1_label "vin" +in1_input Measured input voltage +in1_alarm Input voltage alarm +in2_label "vout1" +in2_input Measured output voltage +in2_crit Critical maximum output voltage +in2_crit_alarm Output voltage high alarm +in2_lcrit Critical minimum output voltage +in2_lcrit_alarm Output voltage critical low alarm +curr1_label "iin" +curr1_input Measured input current. +curr1_alarm Input current alarm +temp1_input Measured temperature +temp1_crit Critical high temperature +temp1_crit_alarm Chip temperature critical high alarm +================= ======================================== diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst index cb073c79479c..49163f387b90 100644 --- a/Documentation/hwmon/aquacomputer_d5next.rst +++ b/Documentation/hwmon/aquacomputer_d5next.rst @@ -45,9 +45,9 @@ seems to require sending it a complete configuration. That includes addressable RGB LEDs, for which there is no standard sysfs interface. Thus, that task is better suited for userspace tools. -The Octo exposes four physical and sixteen virtual temperature sensors, as well as -eight PWM controllable fans, along with their speed (in RPM), power, voltage and -current. +The Octo exposes four physical and sixteen virtual temperature sensors, a flow sensor +as well as eight PWM controllable fans, along with their speed (in RPM), power, voltage +and current. Flow sensor pulses are also available. The Quadro exposes four physical and sixteen virtual temperature sensors, a flow sensor and four PWM controllable fans, along with their speed (in RPM), power, @@ -95,11 +95,12 @@ Sysfs entries ================ ============================================================== temp[1-20]_input Physical/virtual temperature sensors (in millidegrees Celsius) temp[1-8]_offset Temperature sensor correction offset (in millidegrees Celsius) -fan[1-8]_input Pump/fan speed (in RPM) / Flow speed (in dL/h) +fan[1-9]_input Pump/fan speed (in RPM) / Flow speed (in dL/h) fan1_min Minimal fan speed (in RPM) fan1_max Maximal fan speed (in RPM) fan1_target Target fan speed (in RPM) fan5_pulses Quadro flow sensor pulses +fan9_pulses Octo flow sensor pulses power[1-8]_input Pump/fan power (in micro Watts) in[0-7]_input Pump/fan voltage (in milli Volts) curr[1-8]_input Pump/fan current (in milli Amperes) diff --git a/Documentation/hwmon/emc1403.rst b/Documentation/hwmon/emc1403.rst index 0de9616b24ed..57f833b1a800 100644 --- a/Documentation/hwmon/emc1403.rst +++ b/Documentation/hwmon/emc1403.rst @@ -45,6 +45,17 @@ Supported chips: - https://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf + * SMSC / Microchip EMC1428, EMC1438 + + Addresses scanned: I2C 0x18, 0x4c, 0x4d + + Prefix: 'emc1428', 'emc1438' + + Datasheets: + + - https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/20005275A.pdf + - https://ww1.microchip.com/downloads/en/DeviceDoc/EMC1438%20DS%20Rev.%201.0%20(04-29-10).pdf + Author: Kalhan Trisal <kalhan.trisal@intel.com @@ -53,10 +64,10 @@ Description ----------- The Standard Microsystems Corporation (SMSC) / Microchip EMC14xx chips -contain up to four temperature sensors. EMC14x2 support two sensors +contain up to eight temperature sensors. EMC14x2 support two sensors (one internal, one external). EMC14x3 support three sensors (one internal, -two external), and EMC14x4 support four sensors (one internal, three -external). +two external), EMC14x4 support four sensors (one internal, three external), +and EMC14x8 support eight sensors (one internal, seven external). The chips implement three limits for each sensor: low (tempX_min), high (tempX_max) and critical (tempX_crit.) The chips also implement an diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 1ca7a4fe1f8f..03d313af469a 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -33,6 +33,7 @@ Hardware Monitoring Kernel Drivers adm1266 adm1275 adm9240 + adp1050 ads7828 adt7410 adt7411 @@ -250,6 +251,7 @@ Hardware Monitoring Kernel Drivers wm831x wm8350 xgene-hwmon + xdp710 xdpe12284 xdpe152c4 zl6100 diff --git a/Documentation/hwmon/lm70.rst b/Documentation/hwmon/lm70.rst index 11303a7e16a8..02ed60dddffb 100644 --- a/Documentation/hwmon/lm70.rst +++ b/Documentation/hwmon/lm70.rst @@ -5,7 +5,7 @@ Supported chips: * National Semiconductor LM70 - Datasheet: http://www.national.com/pf/LM/LM70.html + Datasheet: https://www.ti.com/product/LM70 * Texas Instruments TMP121/TMP123 diff --git a/Documentation/hwmon/nzxt-kraken3.rst b/Documentation/hwmon/nzxt-kraken3.rst index 90fd9dec15ff..57fe99d23301 100644 --- a/Documentation/hwmon/nzxt-kraken3.rst +++ b/Documentation/hwmon/nzxt-kraken3.rst @@ -11,17 +11,20 @@ Supported devices: * NZXT Kraken Z53 * NZXT Kraken Z63 * NZXT Kraken Z73 +* NZXT Kraken 2023 +* NZXT Kraken 2023 Elite Author: Jonas Malaco, Aleksa Savic Description ----------- -This driver enables hardware monitoring support for NZXT Kraken X53/X63/X73 and -Z53/Z63/Z73 all-in-one CPU liquid coolers. All models expose liquid temperature -and pump speed (in RPM), as well as PWM control (either as a fixed value -or through a temp-PWM curve). The Z-series models additionally expose the speed -and duty of an optionally connected fan, with the same PWM control capabilities. +This driver enables hardware monitoring support for NZXT Kraken X53/X63/X73, +Z53/Z63/Z73 and Kraken 2023 (standard and Elite) all-in-one CPU liquid coolers. +All models expose liquid temperature and pump speed (in RPM), as well as PWM +control (either as a fixed value or through a temp-PWM curve). The Z-series and +Kraken 2023 models additionally expose the speed and duty of an optionally connected +fan, with the same PWM control capabilities. Pump and fan duty control mode can be set through pwm[1-2]_enable, where 1 is for the manual control mode and 2 is for the liquid temp to PWM curve mode. @@ -39,9 +42,9 @@ The devices can report if they are faulty. The driver supports that situation and will issue a warning. This can also happen when the USB cable is connected, but SATA power is not. -The addressable RGB LEDs and LCD screen (only on Z-series models) are not -supported in this driver, but can be controlled through existing userspace tools, -such as `liquidctl`_. +The addressable RGB LEDs and LCD screen (only on Z-series and Kraken 2023 models) +are not supported in this driver, but can be controlled through existing userspace +tools, such as `liquidctl`_. .. _liquidctl: https://github.com/liquidctl/liquidctl diff --git a/Documentation/hwmon/pmbus.rst b/Documentation/hwmon/pmbus.rst index eb1569bfa676..d477124cf67f 100644 --- a/Documentation/hwmon/pmbus.rst +++ b/Documentation/hwmon/pmbus.rst @@ -152,7 +152,7 @@ Emerson DS1200 power modules might look as follows:: } static const struct i2c_device_id ds1200_id[] = { - {"ds1200", 0}, + {"ds1200"}, {} }; diff --git a/Documentation/hwmon/xdp710.rst b/Documentation/hwmon/xdp710.rst new file mode 100644 index 000000000000..083891f27818 --- /dev/null +++ b/Documentation/hwmon/xdp710.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver xdp710 +==================== + +Supported chips: + + * Infineon XDP710 + + Prefix: 'xdp710' + + * Datasheet + + Publicly available at the Infineon website : https://www.infineon.com/dgdl/Infineon-XDP710-001-DataSheet-v01_00-EN.pdf?fileId=8ac78c8c8412f8d301848a5316290b97 + +Author: + + Peter Yin <peteryin.openbmc@gmail.com> + +Description +----------- + +This driver implements support for Infineon XDP710 Hot-Swap Controller. + +Device compliant with: + +- PMBus rev 1.3 interface. + +Device supports direct and linear format for reading input voltage, +output voltage, output current, input power and temperature. + +The driver exports the following attributes via the 'sysfs' files +for input voltage: + +**in1_input** + +**in1_label** + +**in1_max** + +**in1_max_alarm** + +**in1_min** + +**in1_min_alarm** + +The driver provides the following attributes for output voltage: + +**in2_input** + +**in2_label** + +**in2_alarm** + +The driver provides the following attributes for output current: + +**curr1_input** + +**curr1_label** + +**curr1_alarm** + +**curr1_max** + +The driver provides the following attributes for input power: + +**power1_input** + +**power1_label** + +**power1_alarm** + +The driver provides the following attributes for temperature: + +**temp1_input** + +**temp1_max** + +**temp1_max_alarm** + +**temp1_crit** + +**temp1_crit_alarm** diff --git a/Documentation/index.rst b/Documentation/index.rst index 5298611e00ee..f9f525f4c0dd 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -107,7 +107,7 @@ Other documentation There are several unsorted documents that don't seem to fit on other parts of the documentation body, or may require some adjustments and/or conversion -to ReStructured Text format, or are simply too old. +to reStructuredText format, or are simply too old. .. toctree:: :maxdepth: 1 diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README index 658d37860d39..6c666f3422ea 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -21,6 +21,51 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus Test that atomic_set() cannot break the atomicity of atomic RMWs. NOTE: Require herd7 7.56 or later which supports "(void)expr". +cmpxchg-fail-ordered-1.litmus + Demonstrate that a failing cmpxchg() operation acts as a full barrier + when followed by smp_mb__after_atomic(). + +cmpxchg-fail-ordered-2.litmus + Demonstrate that a failing cmpxchg() operation acts as an acquire + operation when followed by smp_mb__after_atomic(). + +cmpxchg-fail-unordered-1.litmus + Demonstrate that a failing cmpxchg() operation does not act as a + full barrier. + +cmpxchg-fail-unordered-2.litmus + Demonstrate that a failing cmpxchg() operation does not act as an + acquire operation. + + +locking (/locking directory) +---------------------------- + +DCL-broken.litmus + Demonstrates that double-checked locking needs more than just + the obvious lock acquisitions and releases. + +DCL-fixed.litmus + Demonstrates corrected double-checked locking that uses + smp_store_release() and smp_load_acquire() in addition to the + obvious lock acquisitions and releases. + +RM-broken.litmus + Demonstrates problems with "roach motel" locking, where code is + freely moved into lock-based critical sections. This example also + shows how to use the "filter" clause to discard executions that + would be excluded by other code not modeled in the litmus test. + Note also that this "roach motel" optimization is emulated by + physically moving P1()'s two reads from x under the lock. + + What is a roach motel? This is from an old advertisement for + a cockroach trap, much later featured in one of the "Men in + Black" movies. "The roaches check in. They don't check out." + +RM-fixed.litmus + The counterpart to RM-broken.litmus, showing P0()'s two loads from + x safely outside of the critical section. + RCU (/rcu directory) -------------------- diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus new file mode 100644 index 000000000000..c0f93dc07105 --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus @@ -0,0 +1,35 @@ +C cmpxchg-fail-ordered-1 + +(* + * Result: Never + * + * Demonstrate that a failing cmpxchg() operation will act as a full + * barrier when followed by smp_mb__after_atomic(). + *) + +{} + +P0(int *x, int *y, int *z) +{ + int r0; + int r1; + + WRITE_ONCE(*x, 1); + r1 = cmpxchg(z, 1, 0); + smp_mb__after_atomic(); + r0 = READ_ONCE(*y); +} + +P1(int *x, int *y, int *z) +{ + int r0; + int r1; + + WRITE_ONCE(*y, 1); + r1 = cmpxchg(z, 1, 0); + smp_mb__after_atomic(); + r0 = READ_ONCE(*x); +} + +locations[0:r1;1:r1] +exists (0:r0=0 /\ 1:r0=0) diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus new file mode 100644 index 000000000000..5c06054f4694 --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus @@ -0,0 +1,30 @@ +C cmpxchg-fail-ordered-2 + +(* + * Result: Never + * + * Demonstrate use of smp_mb__after_atomic() to make a failing cmpxchg + * operation have acquire ordering. + *) + +{} + +P0(int *x, int *y) +{ + int r1; + + WRITE_ONCE(*x, 1); + r1 = cmpxchg(y, 0, 1); +} + +P1(int *x, int *y) +{ + int r1; + int r2; + + r1 = cmpxchg(y, 0, 1); + smp_mb__after_atomic(); + r2 = READ_ONCE(*x); +} + +exists (0:r1=0 /\ 1:r1=1 /\ 1:r2=0) diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus new file mode 100644 index 000000000000..39ea1f56a28d --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus @@ -0,0 +1,34 @@ +C cmpxchg-fail-unordered-1 + +(* + * Result: Sometimes + * + * Demonstrate that a failing cmpxchg() operation does not act as a + * full barrier. (In contrast, a successful cmpxchg() does act as a + * full barrier.) + *) + +{} + +P0(int *x, int *y, int *z) +{ + int r0; + int r1; + + WRITE_ONCE(*x, 1); + r1 = cmpxchg(z, 1, 0); + r0 = READ_ONCE(*y); +} + +P1(int *x, int *y, int *z) +{ + int r0; + int r1; + + WRITE_ONCE(*y, 1); + r1 = cmpxchg(z, 1, 0); + r0 = READ_ONCE(*x); +} + +locations[0:r1;1:r1] +exists (0:r0=0 /\ 1:r0=0) diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus new file mode 100644 index 000000000000..61aab24a4a64 --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus @@ -0,0 +1,30 @@ +C cmpxchg-fail-unordered-2 + +(* + * Result: Sometimes + * + * Demonstrate that a failing cmpxchg() operation does not act as either + * an acquire release operation. (In contrast, a successful cmpxchg() + * does act as both an acquire and a release operation.) + *) + +{} + +P0(int *x, int *y) +{ + int r1; + + WRITE_ONCE(*x, 1); + r1 = cmpxchg(y, 0, 1); +} + +P1(int *x, int *y) +{ + int r1; + int r2; + + r1 = cmpxchg(y, 0, 1); + r2 = READ_ONCE(*x); +} + +exists (0:r1=0 /\ 1:r1=1 /\ 1:r2=0) diff --git a/Documentation/mm/page_frags.rst b/Documentation/mm/page_frags.rst index a81617e688a8..503ca6cdb804 100644 --- a/Documentation/mm/page_frags.rst +++ b/Documentation/mm/page_frags.rst @@ -25,7 +25,7 @@ to be disabled when executing the fragment allocation. The network stack uses two separate caches per CPU to handle fragment allocation. The netdev_alloc_cache is used by callers making use of the netdev_alloc_frag and __netdev_alloc_skb calls. The napi_alloc_cache is -used by callers of the __napi_alloc_frag and __napi_alloc_skb calls. The +used by callers of the __napi_alloc_frag and napi_alloc_skb calls. The main difference between these two calls is the context in which they may be called. The "netdev" prefixed functions are usable in any context as these functions will disable interrupts, while the "napi" prefixed functions are diff --git a/Documentation/mm/slub.rst b/Documentation/mm/slub.rst index b517ee28a955..60d350d08362 100644 --- a/Documentation/mm/slub.rst +++ b/Documentation/mm/slub.rst @@ -80,7 +80,7 @@ to the dentry cache with:: Debugging options may require the minimum possible slab order to increase as a result of storing the metadata (for example, caches with PAGE_SIZE object -sizes). This has a higher liklihood of resulting in slab allocation errors +sizes). This has a higher likelihood of resulting in slab allocation errors in low memory situations or if there's high fragmentation of memory. To switch off debugging for such caches by default, use:: diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml index 4dfd899a1661..4f803eaac6d8 100644 --- a/Documentation/netlink/genetlink-c.yaml +++ b/Documentation/netlink/genetlink-c.yaml @@ -158,7 +158,7 @@ properties: type: &attr-type enum: [ unused, pad, flag, binary, uint, sint, u8, u16, u32, u64, s32, s64, - string, nest, array-nest, nest-type-value ] + string, nest, indexed-array, nest-type-value ] doc: description: Documentation of the attribute. type: string diff --git a/Documentation/netlink/genetlink-legacy.yaml b/Documentation/netlink/genetlink-legacy.yaml index b48ad3b1cc32..8db0e22fa72c 100644 --- a/Documentation/netlink/genetlink-legacy.yaml +++ b/Documentation/netlink/genetlink-legacy.yaml @@ -201,7 +201,7 @@ properties: description: The netlink attribute type enum: [ unused, pad, flag, binary, bitfield32, uint, sint, u8, u16, u32, u64, s32, s64, - string, nest, array-nest, nest-type-value ] + string, nest, indexed-array, nest-type-value ] doc: description: Documentation of the attribute. type: string diff --git a/Documentation/netlink/genetlink.yaml b/Documentation/netlink/genetlink.yaml index ebd6ee743fcc..b036227b46f1 100644 --- a/Documentation/netlink/genetlink.yaml +++ b/Documentation/netlink/genetlink.yaml @@ -124,7 +124,7 @@ properties: type: &attr-type enum: [ unused, pad, flag, binary, uint, sint, u8, u16, u32, u64, s32, s64, - string, nest, array-nest, nest-type-value ] + string, nest, indexed-array, nest-type-value ] doc: description: Documentation of the attribute. type: string diff --git a/Documentation/netlink/netlink-raw.yaml b/Documentation/netlink/netlink-raw.yaml index a76e54cbadbc..914aa1c0a273 100644 --- a/Documentation/netlink/netlink-raw.yaml +++ b/Documentation/netlink/netlink-raw.yaml @@ -222,7 +222,7 @@ properties: description: The netlink attribute type enum: [ unused, pad, flag, binary, bitfield32, u8, u16, u32, u64, s8, s16, s32, s64, - string, nest, array-nest, nest-type-value, + string, nest, indexed-array, nest-type-value, sub-message ] doc: description: Documentation of the attribute. diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml index 197208f419dc..00dc61358be8 100644 --- a/Documentation/netlink/specs/ethtool.yaml +++ b/Documentation/netlink/specs/ethtool.yaml @@ -16,6 +16,10 @@ definitions: name: stringset type: enum entries: [] + - + name: header-flags + type: flags + entries: [ compact-bitsets, omit-reply, stats ] attribute-sets: - @@ -30,6 +34,7 @@ attribute-sets: - name: flags type: u32 + enum: header-flags - name: bitset-bit @@ -560,6 +565,18 @@ attribute-sets: name: tx-lpi-timer type: u32 - + name: ts-stat + attributes: + - + name: tx-pkts + type: uint + - + name: tx-lost + type: uint + - + name: tx-err + type: uint + - name: tsinfo attributes: - @@ -581,6 +598,10 @@ attribute-sets: - name: phc-index type: u32 + - + name: stats + type: nest + nested-attributes: ts-stat - name: cable-result attributes: @@ -878,17 +899,29 @@ attribute-sets: type: nest nested-attributes: header - - name: admin-state + name: podl-pse-admin-state + type: u32 + name-prefix: ethtool-a- + - + name: podl-pse-admin-control + type: u32 + name-prefix: ethtool-a- + - + name: podl-pse-pw-d-status + type: u32 + name-prefix: ethtool-a- + - + name: c33-pse-admin-state type: u32 - name-prefix: ethtool-a-podl-pse- + name-prefix: ethtool-a- - - name: admin-control + name: c33-pse-admin-control type: u32 - name-prefix: ethtool-a-podl-pse- + name-prefix: ethtool-a- - - name: pw-d-status + name: c33-pse-pw-d-status type: u32 - name-prefix: ethtool-a-podl-pse- + name-prefix: ethtool-a- - name: rss attributes: @@ -1388,6 +1421,7 @@ operations: - tx-types - rx-filters - phc-index + - stats dump: *tsinfo-get-op - name: cable-test-act @@ -1571,9 +1605,12 @@ operations: reply: attributes: &pse - header - - admin-state - - admin-control - - pw-d-status + - podl-pse-admin-state + - podl-pse-admin-control + - podl-pse-pw-d-status + - c33-pse-admin-state + - c33-pse-admin-control + - c33-pse-pw-d-status dump: *pse-get-op - name: pse-set diff --git a/Documentation/netlink/specs/netdev.yaml b/Documentation/netlink/specs/netdev.yaml index 76352dbd2be4..11a32373365a 100644 --- a/Documentation/netlink/specs/netdev.yaml +++ b/Documentation/netlink/specs/netdev.yaml @@ -335,6 +335,124 @@ attribute-sets: Allocation failure may, or may not result in a packet drop, depending on driver implementation and whether system recovers quickly. type: uint + - + name: rx-hw-drops + doc: | + Number of all packets which entered the device, but never left it, + including but not limited to: packets dropped due to lack of buffer + space, processing errors, explicit or implicit policies and packet + filters. + type: uint + - + name: rx-hw-drop-overruns + doc: | + Number of packets dropped due to transient lack of resources, such as + buffer space, host descriptors etc. + type: uint + - + name: rx-csum-unnecessary + doc: Number of packets that were marked as CHECKSUM_UNNECESSARY. + type: uint + - + name: rx-csum-none + doc: Number of packets that were not checksummed by device. + type: uint + - + name: rx-csum-bad + doc: | + Number of packets with bad checksum. The packets are not discarded, + but still delivered to the stack. + type: uint + - + name: rx-hw-gro-packets + doc: | + Number of packets that were coalesced from smaller packets by the device. + Counts only packets coalesced with the HW-GRO netdevice feature, + LRO-coalesced packets are not counted. + type: uint + - + name: rx-hw-gro-bytes + doc: See `rx-hw-gro-packets`. + type: uint + - + name: rx-hw-gro-wire-packets + doc: | + Number of packets that were coalesced to bigger packetss with the HW-GRO + netdevice feature. LRO-coalesced packets are not counted. + type: uint + - + name: rx-hw-gro-wire-bytes + doc: See `rx-hw-gro-wire-packets`. + type: uint + - + name: rx-hw-drop-ratelimits + doc: | + Number of the packets dropped by the device due to the received + packets bitrate exceeding the device rate limit. + type: uint + - + name: tx-hw-drops + doc: | + Number of packets that arrived at the device but never left it, + encompassing packets dropped for reasons such as processing errors, as + well as those affected by explicitly defined policies and packet + filtering criteria. + type: uint + - + name: tx-hw-drop-errors + doc: Number of packets dropped because they were invalid or malformed. + type: uint + - + name: tx-csum-none + doc: | + Number of packets that did not require the device to calculate the + checksum. + type: uint + - + name: tx-needs-csum + doc: | + Number of packets that required the device to calculate the checksum. + type: uint + - + name: tx-hw-gso-packets + doc: | + Number of packets that necessitated segmentation into smaller packets + by the device. + type: uint + - + name: tx-hw-gso-bytes + doc: See `tx-hw-gso-packets`. + type: uint + - + name: tx-hw-gso-wire-packets + doc: | + Number of wire-sized packets generated by processing + `tx-hw-gso-packets` + type: uint + - + name: tx-hw-gso-wire-bytes + doc: See `tx-hw-gso-wire-packets`. + type: uint + - + name: tx-hw-drop-ratelimits + doc: | + Number of the packets dropped by the device due to the transmit + packets bitrate exceeding the device rate limit. + type: uint + - + name: tx-stop + doc: | + Number of times driver paused accepting new tx packets + from the stack to this queue, because the queue was full. + Note that if BQL is supported and enabled on the device + the networking stack will avoid queuing a lot of data at once. + type: uint + - + name: tx-wake + doc: | + Number of times driver re-started accepting send + requests to this queue from the stack. + type: uint operations: list: @@ -486,6 +604,7 @@ operations: dump: request: attributes: + - ifindex - scope reply: attributes: diff --git a/Documentation/netlink/specs/nftables.yaml b/Documentation/netlink/specs/nftables.yaml new file mode 100644 index 000000000000..dff2a18f3d90 --- /dev/null +++ b/Documentation/netlink/specs/nftables.yaml @@ -0,0 +1,1264 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: nftables +protocol: netlink-raw +protonum: 12 + +doc: + Netfilter nftables configuration over netlink. + +definitions: + - + name: nfgenmsg + type: struct + members: + - + name: nfgen-family + type: u8 + - + name: version + type: u8 + - + name: res-id + byte-order: big-endian + type: u16 + - + name: meta-keys + type: enum + entries: + - len + - protocol + - priority + - mark + - iif + - oif + - iifname + - oifname + - iftype + - oiftype + - skuid + - skgid + - nftrace + - rtclassid + - secmark + - nfproto + - l4-proto + - bri-iifname + - bri-oifname + - pkttype + - cpu + - iifgroup + - oifgroup + - cgroup + - prandom + - secpath + - iifkind + - oifkind + - bri-iifpvid + - bri-iifvproto + - time-ns + - time-day + - time-hour + - sdif + - sdifname + - bri-broute + - + name: cmp-ops + type: enum + entries: + - eq + - neq + - lt + - lte + - gt + - gte + - + name: object-type + type: enum + entries: + - unspec + - counter + - quota + - ct-helper + - limit + - connlimit + - tunnel + - ct-timeout + - secmark + - ct-expect + - synproxy + - + name: nat-range-flags + type: flags + entries: + - map-ips + - proto-specified + - proto-random + - persistent + - proto-random-fully + - proto-offset + - netmap + - + name: table-flags + type: flags + entries: + - dormant + - owner + - persist + - + name: chain-flags + type: flags + entries: + - base + - hw-offload + - binding + - + name: set-flags + type: flags + entries: + - anonymous + - constant + - interval + - map + - timeout + - eval + - object + - concat + - expr + +attribute-sets: + - + name: empty-attrs + attributes: + - + name: name + type: string + - + name: batch-attrs + attributes: + - + name: genid + type: u32 + byte-order: big-endian + - + name: table-attrs + attributes: + - + name: name + type: string + doc: name of the table + - + name: flags + type: u32 + byte-order: big-endian + doc: bitmask of flags + enum: table-flags + enum-as-flags: true + - + name: use + type: u32 + byte-order: big-endian + doc: number of chains in this table + - + name: handle + type: u64 + byte-order: big-endian + doc: numeric handle of the table + - + name: userdata + type: binary + doc: user data + - + name: chain-attrs + attributes: + - + name: table + type: string + doc: name of the table containing the chain + - + name: handle + type: u64 + byte-order: big-endian + doc: numeric handle of the chain + - + name: name + type: string + doc: name of the chain + - + name: hook + type: nest + nested-attributes: nft-hook-attrs + doc: hook specification for basechains + - + name: policy + type: u32 + byte-order: big-endian + doc: numeric policy of the chain + - + name: use + type: u32 + byte-order: big-endian + doc: number of references to this chain + - + name: type + type: string + doc: type name of the chain + - + name: counters + type: nest + nested-attributes: nft-counter-attrs + doc: counter specification of the chain + - + name: flags + type: u32 + byte-order: big-endian + doc: chain flags + enum: chain-flags + enum-as-flags: true + - + name: id + type: u32 + byte-order: big-endian + doc: uniquely identifies a chain in a transaction + - + name: userdata + type: binary + doc: user data + - + name: counter-attrs + attributes: + - + name: bytes + type: u64 + byte-order: big-endian + - + name: packets + type: u64 + byte-order: big-endian + - + name: pad + type: pad + - + name: nft-hook-attrs + attributes: + - + name: num + type: u32 + byte-order: big-endian + - + name: priority + type: s32 + byte-order: big-endian + - + name: dev + type: string + doc: net device name + - + name: devs + type: nest + nested-attributes: hook-dev-attrs + doc: list of net devices + - + name: hook-dev-attrs + attributes: + - + name: name + type: string + multi-attr: true + - + name: nft-counter-attrs + attributes: + - + name: bytes + type: u64 + - + name: packets + type: u64 + - + name: rule-attrs + attributes: + - + name: table + type: string + doc: name of the table containing the rule + - + name: chain + type: string + doc: name of the chain containing the rule + - + name: handle + type: u64 + byte-order: big-endian + doc: numeric handle of the rule + - + name: expressions + type: nest + nested-attributes: expr-list-attrs + doc: list of expressions + - + name: compat + type: nest + nested-attributes: rule-compat-attrs + doc: compatibility specifications of the rule + - + name: position + type: u64 + byte-order: big-endian + doc: numeric handle of the previous rule + - + name: userdata + type: binary + doc: user data + - + name: id + type: u32 + doc: uniquely identifies a rule in a transaction + - + name: position-id + type: u32 + doc: transaction unique identifier of the previous rule + - + name: chain-id + type: u32 + doc: add the rule to chain by ID, alternative to chain name + - + name: expr-list-attrs + attributes: + - + name: elem + type: nest + nested-attributes: expr-attrs + multi-attr: true + - + name: expr-attrs + attributes: + - + name: name + type: string + doc: name of the expression type + - + name: data + type: sub-message + sub-message: expr-ops + selector: name + doc: type specific data + - + name: rule-compat-attrs + attributes: + - + name: proto + type: binary + doc: numeric value of the handled protocol + - + name: flags + type: binary + doc: bitmask of flags + - + name: set-attrs + attributes: + - + name: table + type: string + doc: table name + - + name: name + type: string + doc: set name + - + name: flags + type: u32 + enum: set-flags + byte-order: big-endian + doc: bitmask of enum nft_set_flags + - + name: key-type + type: u32 + byte-order: big-endian + doc: key data type, informational purpose only + - + name: key-len + type: u32 + byte-order: big-endian + doc: key data length + - + name: data-type + type: u32 + byte-order: big-endian + doc: mapping data type + - + name: data-len + type: u32 + byte-order: big-endian + doc: mapping data length + - + name: policy + type: u32 + byte-order: big-endian + doc: selection policy + - + name: desc + type: nest + nested-attributes: set-desc-attrs + doc: set description + - + name: id + type: u32 + doc: uniquely identifies a set in a transaction + - + name: timeout + type: u64 + doc: default timeout value + - + name: gc-interval + type: u32 + doc: garbage collection interval + - + name: userdata + type: binary + doc: user data + - + name: pad + type: pad + - + name: obj-type + type: u32 + byte-order: big-endian + doc: stateful object type + - + name: handle + type: u64 + byte-order: big-endian + doc: set handle + - + name: expr + type: nest + nested-attributes: expr-attrs + doc: set expression + multi-attr: true + - + name: expressions + type: nest + nested-attributes: set-list-attrs + doc: list of expressions + - + name: set-desc-attrs + attributes: + - + name: size + type: u32 + byte-order: big-endian + doc: number of elements in set + - + name: concat + type: nest + nested-attributes: set-desc-concat-attrs + doc: description of field concatenation + multi-attr: true + - + name: set-desc-concat-attrs + attributes: + - + name: elem + type: nest + nested-attributes: set-field-attrs + - + name: set-field-attrs + attributes: + - + name: len + type: u32 + byte-order: big-endian + - + name: set-list-attrs + attributes: + - + name: elem + type: nest + nested-attributes: expr-attrs + multi-attr: true + - + name: setelem-attrs + attributes: + - + name: key + type: nest + nested-attributes: data-attrs + doc: key value + - + name: data + type: nest + nested-attributes: data-attrs + doc: data value of mapping + - + name: flags + type: binary + doc: bitmask of nft_set_elem_flags + - + name: timeout + type: u64 + doc: timeout value + - + name: expiration + type: u64 + doc: expiration time + - + name: userdata + type: binary + doc: user data + - + name: expr + type: nest + nested-attributes: expr-attrs + doc: expression + - + name: objref + type: string + doc: stateful object reference + - + name: key-end + type: nest + nested-attributes: data-attrs + doc: closing key value + - + name: expressions + type: nest + nested-attributes: expr-list-attrs + doc: list of expressions + - + name: setelem-list-elem-attrs + attributes: + - + name: elem + type: nest + nested-attributes: setelem-attrs + multi-attr: true + - + name: setelem-list-attrs + attributes: + - + name: table + type: string + - + name: set + type: string + - + name: elements + type: nest + nested-attributes: setelem-list-elem-attrs + - + name: set-id + type: u32 + - + name: gen-attrs + attributes: + - + name: id + type: u32 + byte-order: big-endian + doc: ruleset generation id + - + name: proc-pid + type: u32 + byte-order: big-endian + - + name: proc-name + type: string + - + name: obj-attrs + attributes: + - + name: table + type: string + doc: name of the table containing the expression + - + name: name + type: string + doc: name of this expression type + - + name: type + type: u32 + enum: object-type + byte-order: big-endian + doc: stateful object type + - + name: data + type: sub-message + sub-message: obj-data + selector: type + doc: stateful object data + - + name: use + type: u32 + byte-order: big-endian + doc: number of references to this expression + - + name: handle + type: u64 + byte-order: big-endian + doc: object handle + - + name: pad + type: pad + - + name: userdata + type: binary + doc: user data + - + name: quota-attrs + attributes: + - + name: bytes + type: u64 + byte-order: big-endian + - + name: flags # TODO + type: u32 + byte-order: big-endian + - + name: pad + type: pad + - + name: consumed + type: u64 + byte-order: big-endian + - + name: flowtable-attrs + attributes: + - + name: table + type: string + - + name: name + type: string + - + name: hook + type: nest + nested-attributes: flowtable-hook-attrs + - + name: use + type: u32 + byte-order: big-endian + - + name: handle + type: u64 + byte-order: big-endian + - + name: pad + type: pad + - + name: flags + type: u32 + byte-order: big-endian + - + name: flowtable-hook-attrs + attributes: + - + name: num + type: u32 + byte-order: big-endian + - + name: priority + type: u32 + byte-order: big-endian + - + name: devs + type: nest + nested-attributes: hook-dev-attrs + - + name: expr-cmp-attrs + attributes: + - + name: sreg + type: u32 + byte-order: big-endian + - + name: op + type: u32 + byte-order: big-endian + enum: cmp-ops + - + name: data + type: nest + nested-attributes: data-attrs + - + name: data-attrs + attributes: + - + name: value + type: binary + # sub-type: u8 + - + name: verdict + type: nest + nested-attributes: verdict-attrs + - + name: verdict-attrs + attributes: + - + name: code + type: u32 + byte-order: big-endian + - + name: chain + type: string + - + name: chain-id + type: u32 + - + name: expr-counter-attrs + attributes: + - + name: bytes + type: u64 + doc: Number of bytes + - + name: packets + type: u64 + doc: Number of packets + - + name: pad + type: pad + - + name: expr-flow-offload-attrs + attributes: + - + name: name + type: string + doc: Flow offload table name + - + name: expr-immediate-attrs + attributes: + - + name: dreg + type: u32 + byte-order: big-endian + - + name: data + type: nest + nested-attributes: data-attrs + - + name: expr-meta-attrs + attributes: + - + name: dreg + type: u32 + byte-order: big-endian + - + name: key + type: u32 + byte-order: big-endian + enum: meta-keys + - + name: sreg + type: u32 + byte-order: big-endian + - + name: expr-nat-attrs + attributes: + - + name: type + type: u32 + byte-order: big-endian + - + name: family + type: u32 + byte-order: big-endian + - + name: reg-addr-min + type: u32 + byte-order: big-endian + - + name: reg-addr-max + type: u32 + byte-order: big-endian + - + name: reg-proto-min + type: u32 + byte-order: big-endian + - + name: reg-proto-max + type: u32 + byte-order: big-endian + - + name: flags + type: u32 + byte-order: big-endian + enum: nat-range-flags + enum-as-flags: true + - + name: expr-payload-attrs + attributes: + - + name: dreg + type: u32 + byte-order: big-endian + - + name: base + type: u32 + byte-order: big-endian + - + name: offset + type: u32 + byte-order: big-endian + - + name: len + type: u32 + byte-order: big-endian + - + name: sreg + type: u32 + byte-order: big-endian + - + name: csum-type + type: u32 + byte-order: big-endian + - + name: csum-offset + type: u32 + byte-order: big-endian + - + name: csum-flags + type: u32 + byte-order: big-endian + - + name: expr-tproxy-attrs + attributes: + - + name: family + type: u32 + byte-order: big-endian + - + name: reg-addr + type: u32 + byte-order: big-endian + - + name: reg-port + type: u32 + byte-order: big-endian + +sub-messages: + - + name: expr-ops + formats: + - + value: bitwise # TODO + - + value: cmp + attribute-set: expr-cmp-attrs + - + value: counter + attribute-set: expr-counter-attrs + - + value: ct # TODO + - + value: flow_offload + attribute-set: expr-flow-offload-attrs + - + value: immediate + attribute-set: expr-immediate-attrs + - + value: lookup # TODO + - + value: meta + attribute-set: expr-meta-attrs + - + value: nat + attribute-set: expr-nat-attrs + - + value: payload + attribute-set: expr-payload-attrs + - + value: tproxy + attribute-set: expr-tproxy-attrs + - + name: obj-data + formats: + - + value: counter + attribute-set: counter-attrs + - + value: quota + attribute-set: quota-attrs + +operations: + enum-model: directional + list: + - + name: batch-begin + doc: Start a batch of operations + attribute-set: batch-attrs + fixed-header: nfgenmsg + do: + request: + value: 0x10 + attributes: + - genid + reply: + value: 0x10 + attributes: + - genid + - + name: batch-end + doc: Finish a batch of operations + attribute-set: batch-attrs + fixed-header: nfgenmsg + do: + request: + value: 0x11 + attributes: + - genid + - + name: newtable + doc: Create a new table. + attribute-set: table-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa00 + attributes: + - name + - + name: gettable + doc: Get / dump tables. + attribute-set: table-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa01 + attributes: + - name + reply: + value: 0xa00 + attributes: + - name + - + name: deltable + doc: Delete an existing table. + attribute-set: table-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa02 + attributes: + - name + - + name: destroytable + doc: Delete an existing table with destroy semantics (ignoring ENOENT errors). + attribute-set: table-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa1a + attributes: + - name + - + name: newchain + doc: Create a new chain. + attribute-set: chain-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa03 + attributes: + - name + - + name: getchain + doc: Get / dump chains. + attribute-set: chain-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa04 + attributes: + - name + reply: + value: 0xa03 + attributes: + - name + - + name: delchain + doc: Delete an existing chain. + attribute-set: chain-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa05 + attributes: + - name + - + name: destroychain + doc: Delete an existing chain with destroy semantics (ignoring ENOENT errors). + attribute-set: chain-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa1b + attributes: + - name + - + name: newrule + doc: Create a new rule. + attribute-set: rule-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa06 + attributes: + - name + - + name: getrule + doc: Get / dump rules. + attribute-set: rule-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa07 + attributes: + - name + reply: + value: 0xa06 + attributes: + - name + - + name: getrule-reset + doc: Get / dump rules and reset stateful expressions. + attribute-set: rule-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa19 + attributes: + - name + reply: + value: 0xa06 + attributes: + - name + - + name: delrule + doc: Delete an existing rule. + attribute-set: rule-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa08 + attributes: + - name + - + name: destroyrule + doc: Delete an existing rule with destroy semantics (ignoring ENOENT errors). + attribute-set: rule-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa1c + attributes: + - name + - + name: newset + doc: Create a new set. + attribute-set: set-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa09 + attributes: + - name + - + name: getset + doc: Get / dump sets. + attribute-set: set-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa0a + attributes: + - name + reply: + value: 0xa09 + attributes: + - name + - + name: delset + doc: Delete an existing set. + attribute-set: set-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa0b + attributes: + - name + - + name: destroyset + doc: Delete an existing set with destroy semantics (ignoring ENOENT errors). + attribute-set: set-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa1d + attributes: + - name + - + name: newsetelem + doc: Create a new set element. + attribute-set: setelem-list-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa0c + attributes: + - name + - + name: getsetelem + doc: Get / dump set elements. + attribute-set: setelem-list-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa0d + attributes: + - name + reply: + value: 0xa0c + attributes: + - name + - + name: getsetelem-reset + doc: Get / dump set elements and reset stateful expressions. + attribute-set: setelem-list-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa21 + attributes: + - name + reply: + value: 0xa0c + attributes: + - name + - + name: delsetelem + doc: Delete an existing set element. + attribute-set: setelem-list-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa0e + attributes: + - name + - + name: destroysetelem + doc: Delete an existing set element with destroy semantics. + attribute-set: setelem-list-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa1e + attributes: + - name + - + name: getgen + doc: Get / dump rule-set generation. + attribute-set: gen-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa10 + attributes: + - name + reply: + value: 0xa0f + attributes: + - name + - + name: newobj + doc: Create a new stateful object. + attribute-set: obj-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa12 + attributes: + - name + - + name: getobj + doc: Get / dump stateful objects. + attribute-set: obj-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa13 + attributes: + - name + reply: + value: 0xa12 + attributes: + - name + - + name: delobj + doc: Delete an existing stateful object. + attribute-set: obj-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa14 + attributes: + - name + - + name: destroyobj + doc: Delete an existing stateful object with destroy semantics. + attribute-set: obj-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa1f + attributes: + - name + - + name: newflowtable + doc: Create a new flow table. + attribute-set: flowtable-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa16 + attributes: + - name + - + name: getflowtable + doc: Get / dump flow tables. + attribute-set: flowtable-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa17 + attributes: + - name + reply: + value: 0xa16 + attributes: + - name + - + name: delflowtable + doc: Delete an existing flow table. + attribute-set: flowtable-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa18 + attributes: + - name + - + name: destroyflowtable + doc: Delete an existing flow table with destroy semantics. + attribute-set: flowtable-attrs + fixed-header: nfgenmsg + do: + request: + value: 0xa20 + attributes: + - name + +mcast-groups: + list: + - + name: mgmt diff --git a/Documentation/netlink/specs/nlctrl.yaml b/Documentation/netlink/specs/nlctrl.yaml index b1632b95f725..a36535350bdb 100644 --- a/Documentation/netlink/specs/nlctrl.yaml +++ b/Documentation/netlink/specs/nlctrl.yaml @@ -65,11 +65,13 @@ attribute-sets: type: u32 - name: ops - type: array-nest + type: indexed-array + sub-type: nest nested-attributes: op-attrs - name: mcast-groups - type: array-nest + type: indexed-array + sub-type: nest nested-attributes: mcast-group-attrs - name: policy diff --git a/Documentation/netlink/specs/rt_link.yaml b/Documentation/netlink/specs/rt_link.yaml index 8e4d19adee8c..de08c12fd56f 100644 --- a/Documentation/netlink/specs/rt_link.yaml +++ b/Documentation/netlink/specs/rt_link.yaml @@ -50,7 +50,16 @@ definitions: name: dormant - name: echo - + - + name: vlan-protocols + type: enum + entries: + - + name: 8021q + value: 33024 + - + name: 8021ad + value: 34984 - name: rtgenmsg type: struct @@ -729,7 +738,171 @@ definitions: - name: filter-mask type: u32 - + - + name: ifla-vlan-flags + type: struct + members: + - + name: flags + type: u32 + enum: vlan-flags + enum-as-flags: true + - + name: mask + type: u32 + display-hint: hex + - + name: vlan-flags + type: flags + entries: + - reorder-hdr + - gvrp + - loose-binding + - mvrp + - bridge-binding + - + name: ifla-vlan-qos-mapping + type: struct + members: + - + name: from + type: u32 + - + name: to + type: u32 + - + name: ifla-vf-mac + type: struct + members: + - + name: vf + type: u32 + - + name: mac + type: binary + len: 32 + - + name: ifla-vf-vlan + type: struct + members: + - + name: vf + type: u32 + - + name: vlan + type: u32 + - + name: qos + type: u32 + - + name: ifla-vf-tx-rate + type: struct + members: + - + name: vf + type: u32 + - + name: rate + type: u32 + - + name: ifla-vf-spoofchk + type: struct + members: + - + name: vf + type: u32 + - + name: setting + type: u32 + - + name: ifla-vf-link-state + type: struct + members: + - + name: vf + type: u32 + - + name: link-state + type: u32 + enum: ifla-vf-link-state-enum + - + name: ifla-vf-link-state-enum + type: enum + entries: + - auto + - enable + - disable + - + name: ifla-vf-rate + type: struct + members: + - + name: vf + type: u32 + - + name: min-tx-rate + type: u32 + - + name: max-tx-rate + type: u32 + - + name: ifla-vf-rss-query-en + type: struct + members: + - + name: vf + type: u32 + - + name: setting + type: u32 + - + name: ifla-vf-trust + type: struct + members: + - + name: vf + type: u32 + - + name: setting + type: u32 + - + name: ifla-vf-guid + type: struct + members: + - + name: vf + type: u32 + - + name: guid + type: u64 + - + name: ifla-vf-vlan-info + type: struct + members: + - + name: vf + type: u32 + - + name: vlan + type: u32 + - + name: qos + type: u32 + - + name: vlan-proto + type: u32 + - + name: rtext-filter + type: flags + entries: + - vf + - brvlan + - brvlan-compressed + - skip-stats + - mrp + - cfm-config + - cfm-status + - mst attribute-sets: - @@ -807,7 +980,7 @@ attribute-sets: - name: vfinfo-list type: nest - nested-attributes: vfinfo-attrs + nested-attributes: vfinfo-list-attrs - name: stats64 type: binary @@ -833,6 +1006,8 @@ attribute-sets: - name: ext-mask type: u32 + enum: rtext-filter + enum-as-flags: true - name: promiscuity type: u32 @@ -965,8 +1140,106 @@ attribute-sets: value: 45 nested-attributes: mctp-attrs - + name: vfinfo-list-attrs + attributes: + - + name: info + type: nest + nested-attributes: vfinfo-attrs + multi-attr: true + - name: vfinfo-attrs - attributes: [] + attributes: + - + name: mac + type: binary + struct: ifla-vf-mac + - + name: vlan + type: binary + struct: ifla-vf-vlan + - + name: tx-rate + type: binary + struct: ifla-vf-tx-rate + - + name: spoofchk + type: binary + struct: ifla-vf-spoofchk + - + name: link-state + type: binary + struct: ifla-vf-link-state + - + name: rate + type: binary + struct: ifla-vf-rate + - + name: rss-query-en + type: binary + struct: ifla-vf-rss-query-en + - + name: stats + type: nest + nested-attributes: vf-stats-attrs + - + name: trust + type: binary + struct: ifla-vf-trust + - + name: ib-node-guid + type: binary + struct: ifla-vf-guid + - + name: ib-port-guid + type: binary + struct: ifla-vf-guid + - + name: vlan-list + type: nest + nested-attributes: vf-vlan-attrs + - + name: broadcast + type: binary + - + name: vf-stats-attrs + attributes: + - + name: rx-packets + type: u64 + value: 0 + - + name: tx-packets + type: u64 + - + name: rx-bytes + type: u64 + - + name: tx-bytes + type: u64 + - + name: broadcast + type: u64 + - + name: multicast + type: u64 + - + name: pad + type: pad + - + name: rx-dropped + type: u64 + - + name: tx-dropped + type: u64 + - + name: vf-vlan-attrs + attributes: + - + name: info + type: binary + struct: ifla-vf-vlan-info + multi-attr: true - name: vf-ports-attrs attributes: [] @@ -996,6 +1269,165 @@ attribute-sets: sub-message: linkinfo-member-data-msg selector: slave-kind - + name: linkinfo-bond-attrs + name-prefix: ifla-bond- + attributes: + - + name: mode + type: u8 + - + name: active-slave + type: u32 + - + name: miimon + type: u32 + - + name: updelay + type: u32 + - + name: downdelay + type: u32 + - + name: use-carrier + type: u8 + - + name: arp-interval + type: u32 + - + name: arp-ip-target + type: indexed-array + sub-type: u32 + byte-order: big-endian + display-hint: ipv4 + - + name: arp-validate + type: u32 + - + name: arp-all-targets + type: u32 + - + name: primary + type: u32 + - + name: primary-reselect + type: u8 + - + name: fail-over-mac + type: u8 + - + name: xmit-hash-policy + type: u8 + - + name: resend-igmp + type: u32 + - + name: num-peer-notif + type: u8 + - + name: all-slaves-active + type: u8 + - + name: min-links + type: u32 + - + name: lp-interval + type: u32 + - + name: packets-per-slave + type: u32 + - + name: ad-lacp-rate + type: u8 + - + name: ad-select + type: u8 + - + name: ad-info + type: nest + nested-attributes: bond-ad-info-attrs + - + name: ad-actor-sys-prio + type: u16 + - + name: ad-user-port-key + type: u16 + - + name: ad-actor-system + type: binary + display-hint: mac + - + name: tlb-dynamic-lb + type: u8 + - + name: peer-notif-delay + type: u32 + - + name: ad-lacp-active + type: u8 + - + name: missed-max + type: u8 + - + name: ns-ip6-target + type: indexed-array + sub-type: binary + display-hint: ipv6 + - + name: coupled-control + type: u8 + - + name: bond-ad-info-attrs + name-prefix: ifla-bond-ad-info- + attributes: + - + name: aggregator + type: u16 + - + name: num-ports + type: u16 + - + name: actor-key + type: u16 + - + name: partner-key + type: u16 + - + name: partner-mac + type: binary + display-hint: mac + - + name: bond-slave-attrs + name-prefix: ifla-bond-slave- + attributes: + - + name: state + type: u8 + - + name: mii-status + type: u8 + - + name: link-failure-count + type: u32 + - + name: perm-hwaddr + type: binary + display-hint: mac + - + name: queue-id + type: u16 + - + name: ad-aggregator-id + type: u16 + - + name: ad-actor-oper-port-state + type: u8 + - + name: ad-partner-oper-port-state + type: u16 + - + name: prio + type: u32 + - name: linkinfo-bridge-attrs name-prefix: ifla-br- attributes: @@ -1144,6 +1576,12 @@ attribute-sets: - name: mcast-querier-state type: binary + - + name: fdb-n-learned + type: u32 + - + name: fdb-max-learned + type: u32 - name: linkinfo-brport-attrs name-prefix: ifla-brport- @@ -1508,6 +1946,39 @@ attribute-sets: name: num-disabled-queues type: u32 - + name: linkinfo-vlan-attrs + name-prefix: ifla-vlan- + attributes: + - + name: id + type: u16 + - + name: flag + type: binary + struct: ifla-vlan-flags + - + name: egress-qos + type: nest + nested-attributes: ifla-vlan-qos + - + name: ingress-qos + type: nest + nested-attributes: ifla-vlan-qos + - + name: protocol + type: u16 + enum: vlan-protocols + byte-order: big-endian + - + name: ifla-vlan-qos + name-prefix: ifla-vlan-qos + attributes: + - + name: mapping + type: binary + multi-attr: true + struct: ifla-vlan-qos-mapping + - name: linkinfo-vrf-attrs name-prefix: ifla-vrf- attributes: @@ -1617,7 +2088,8 @@ attribute-sets: type: binary - name: hw-s-info - type: array-nest + type: indexed-array + sub-type: nest nested-attributes: hw-s-info-one - name: l3-stats @@ -1643,6 +2115,9 @@ sub-messages: name: linkinfo-data-msg formats: - + value: bond + attribute-set: linkinfo-bond-attrs + - value: bridge attribute-set: linkinfo-bridge-attrs - @@ -1667,6 +2142,9 @@ sub-messages: value: tun attribute-set: linkinfo-tun-attrs - + value: vlan + attribute-set: linkinfo-vlan-attrs + - value: vrf attribute-set: linkinfo-vrf-attrs - @@ -1677,6 +2155,7 @@ sub-messages: attribute-set: linkinfo-brport-attrs - value: bond + attribute-set: bond-slave-attrs operations: enum-model: directional diff --git a/Documentation/netlink/specs/tc.yaml b/Documentation/netlink/specs/tc.yaml index 324fa182cd14..8c01e4e13195 100644 --- a/Documentation/netlink/specs/tc.yaml +++ b/Documentation/netlink/specs/tc.yaml @@ -1100,6 +1100,19 @@ definitions: name: offmask type: s32 - + name: tc-u32-mark + type: struct + members: + - + name: val + type: u32 + - + name: mask + type: u32 + - + name: success + type: u32 + - name: tc-u32-sel type: struct members: @@ -1775,6 +1788,44 @@ attribute-sets: name: key-ex type: binary - + name: tc-act-police-attrs + attributes: + - + name: tbf + type: binary + struct: tc-police + - + name: rate + type: binary # TODO + - + name: peakrate + type: binary # TODO + - + name: avrate + type: u32 + - + name: result + type: u32 + - + name: tm + type: binary + struct: tcf-t + - + name: pad + type: pad + - + name: rate64 + type: u64 + - + name: peakrate64 + type: u64 + - + name: pktrate64 + type: u64 + - + name: pktburst64 + type: u64 + - name: tc-act-simple-attrs attributes: - @@ -1937,7 +1988,8 @@ attribute-sets: nested-attributes: tc-ematch-attrs - name: act - type: array-nest + type: indexed-array + sub-type: nest nested-attributes: tc-act-attrs - name: police @@ -2077,7 +2129,8 @@ attribute-sets: type: u32 - name: tin-stats - type: array-nest + type: indexed-array + sub-type: nest nested-attributes: tc-cake-tin-stats-attrs - name: deficit @@ -2297,7 +2350,8 @@ attribute-sets: type: string - name: act - type: array-nest + type: indexed-array + sub-type: nest nested-attributes: tc-act-attrs - name: key-eth-dst @@ -2798,7 +2852,8 @@ attribute-sets: type: string - name: act - type: array-nest + type: indexed-array + sub-type: nest nested-attributes: tc-act-attrs - name: mask @@ -2951,7 +3006,8 @@ attribute-sets: type: u32 - name: act - type: array-nest + type: indexed-array + sub-type: nest nested-attributes: tc-act-attrs - name: flags @@ -3324,7 +3380,8 @@ attribute-sets: nested-attributes: tc-police-attrs - name: act - type: array-nest + type: indexed-array + sub-type: nest nested-attributes: tc-act-attrs - name: tc-taprio-attrs @@ -3542,7 +3599,8 @@ attribute-sets: nested-attributes: tc-police-attrs - name: act - type: array-nest + type: indexed-array + sub-type: nest nested-attributes: tc-act-attrs - name: indev diff --git a/Documentation/netlink/specs/team.yaml b/Documentation/netlink/specs/team.yaml new file mode 100644 index 000000000000..c13529e011c9 --- /dev/null +++ b/Documentation/netlink/specs/team.yaml @@ -0,0 +1,204 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: team + +protocol: genetlink-legacy + +doc: | + Network team device driver. + +c-family-name: team-genl-name +c-version-name: team-genl-version +kernel-policy: global +uapi-header: linux/if_team.h + +definitions: + - + name: string-max-len + type: const + value: 32 + - + name: genl-change-event-mc-grp-name + type: const + value: change_event + +attribute-sets: + - + name: team + doc: + The team nested layout of get/set msg looks like + [TEAM_ATTR_LIST_OPTION] + [TEAM_ATTR_ITEM_OPTION] + [TEAM_ATTR_OPTION_*], ... + [TEAM_ATTR_ITEM_OPTION] + [TEAM_ATTR_OPTION_*], ... + ... + [TEAM_ATTR_LIST_PORT] + [TEAM_ATTR_ITEM_PORT] + [TEAM_ATTR_PORT_*], ... + [TEAM_ATTR_ITEM_PORT] + [TEAM_ATTR_PORT_*], ... + ... + name-prefix: team-attr- + attributes: + - + name: unspec + type: unused + value: 0 + - + name: team-ifindex + type: u32 + - + name: list-option + type: nest + nested-attributes: item-option + - + name: list-port + type: nest + nested-attributes: item-port + - + name: item-option + name-prefix: team-attr-item- + attr-cnt-name: __team-attr-item-option-max + attr-max-name: team-attr-item-option-max + attributes: + - + name: option-unspec + type: unused + value: 0 + - + name: option + type: nest + nested-attributes: attr-option + - + name: attr-option + name-prefix: team-attr-option- + attributes: + - + name: unspec + type: unused + value: 0 + - + name: name + type: string + checks: + max-len: string-max-len + unterminated-ok: true + - + name: changed + type: flag + - + name: type + type: u8 + - + name: data + type: binary + - + name: removed + type: flag + - + name: port-ifindex + type: u32 + doc: for per-port options + - + name: array-index + type: u32 + doc: for array options + - + name: item-port + name-prefix: team-attr-item- + attr-cnt-name: __team-attr-item-port-max + attr-max-name: team-attr-item-port-max + attributes: + - + name: port-unspec + type: unused + value: 0 + - + name: port + type: nest + nested-attributes: attr-port + - + name: attr-port + name-prefix: team-attr-port- + attributes: + - + name: unspec + type: unused + value: 0 + - + name: ifindex + type: u32 + - + name: changed + type: flag + - + name: linkup + type: flag + - + name: speed + type: u32 + - + name: duplex + type: u8 + - + name: removed + type: flag + +operations: + list: + - + name: noop + doc: No operation + value: 0 + attribute-set: team + dont-validate: [ strict ] + + do: + # Actually it only reply the team netlink family + reply: + attributes: + - team-ifindex + + - + name: options-set + doc: Set team options + attribute-set: team + dont-validate: [ strict ] + flags: [ admin-perm ] + + do: + request: &option_attrs + attributes: + - team-ifindex + - list-option + reply: *option_attrs + + - + name: options-get + doc: Get team options info + attribute-set: team + dont-validate: [ strict ] + flags: [ admin-perm ] + + do: + request: + attributes: + - team-ifindex + reply: *option_attrs + + - + name: port-list-get + doc: Get team ports info + attribute-set: team + dont-validate: [ strict ] + flags: [ admin-perm ] + + do: + request: + attributes: + - team-ifindex + reply: &port_attrs + attributes: + - team-ifindex + - list-port diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst index f69ee1ebee01..fed821ef9b09 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst @@ -300,6 +300,11 @@ the software port. in the beginning of the queue. This is a normal condition. - Informative + * - `tx[i]_timestamps` + - Transmitted packets that were hardware timestamped at the device's DMA + layer. + - Informative + * - `tx[i]_added_vlan_packets` - The number of packets sent where vlan tag insertion was offloaded to the hardware. @@ -702,6 +707,12 @@ the software port. the device typically ensures not posting the CQE. - Error + * - `ptp_cq[i]_lost_cqe` + - Number of times a CQE is expected to not be delivered on the PTP + timestamping CQE by the device due to a time delta elapsing. If such a + CQE is somehow delivered, `ptp_cq[i]_late_cqe` is incremented. + - Error + .. [#ring_global] The corresponding ring and global counters do not share the same name (i.e. do not follow the common naming scheme). diff --git a/Documentation/networking/devlink/devlink-info.rst b/Documentation/networking/devlink/devlink-info.rst index 1242b0e6826b..23073bc219d8 100644 --- a/Documentation/networking/devlink/devlink-info.rst +++ b/Documentation/networking/devlink/devlink-info.rst @@ -146,6 +146,11 @@ board.manufacture An identifier of the company or the facility which produced the part. +board.part_number +----------------- + +Part number of the board and its components. + fw -- diff --git a/Documentation/networking/devlink/devlink-port.rst b/Documentation/networking/devlink/devlink-port.rst index 562f46b41274..9d22d41a7cd1 100644 --- a/Documentation/networking/devlink/devlink-port.rst +++ b/Documentation/networking/devlink/devlink-port.rst @@ -134,6 +134,9 @@ Users may also set the IPsec crypto capability of the function using Users may also set the IPsec packet capability of the function using `devlink port function set ipsec_packet` command. +Users may also set the maximum IO event queues of the function +using `devlink port function set max_io_eqs` command. + Function attributes =================== @@ -295,6 +298,36 @@ policy is processed in software by the kernel. function: hw_addr 00:00:00:00:00:00 ipsec_packet enabled +Maximum IO events queues setup +------------------------------ +When user sets maximum number of IO event queues for a SF or +a VF, such function driver is limited to consume only enforced +number of IO event queues. + +IO event queues deliver events related to IO queues, including network +device transmit and receive queues (txq and rxq) and RDMA Queue Pairs (QPs). +For example, the number of netdevice channels and RDMA device completion +vectors are derived from the function's IO event queues. Usually, the number +of interrupt vectors consumed by the driver is limited by the number of IO +event queues per device, as each of the IO event queues is connected to an +interrupt vector. + +- Get maximum IO event queues of the VF device:: + + $ devlink port show pci/0000:06:00.0/2 + pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1 + function: + hw_addr 00:00:00:00:00:00 ipsec_packet disabled max_io_eqs 10 + +- Set maximum IO event queues of the VF device:: + + $ devlink port function set pci/0000:06:00.0/2 max_io_eqs 32 + + $ devlink port show pci/0000:06:00.0/2 + pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1 + function: + hw_addr 00:00:00:00:00:00 ipsec_packet disabled max_io_eqs 32 + Subfunction ============ diff --git a/Documentation/networking/devlink/hns3.rst b/Documentation/networking/devlink/hns3.rst index 4562a6e4782f..72bc1b9f3785 100644 --- a/Documentation/networking/devlink/hns3.rst +++ b/Documentation/networking/devlink/hns3.rst @@ -23,3 +23,8 @@ The ``hns3`` driver reports the following versions * - ``fw`` - running - Used to represent the firmware version. + * - ``fw.scc`` + - running + - Used to represent the Soft Congestion Control (SSC) firmware version. + SCC is a firmware component which provides multiple RDMA congestion + control algorithms, including DCQCN. diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index 7f30ebd5debb..830c04354222 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -21,6 +21,53 @@ Parameters * - ``enable_iwarp`` - runtime - mutually exclusive with ``enable_roce`` + * - ``tx_scheduling_layers`` + - permanent + - The ice hardware uses hierarchical scheduling for Tx with a fixed + number of layers in the scheduling tree. Each of them are decision + points. Root node represents a port, while all the leaves represent + the queues. This way of configuring the Tx scheduler allows features + like DCB or devlink-rate (documented below) to configure how much + bandwidth is given to any given queue or group of queues, enabling + fine-grained control because scheduling parameters can be configured + at any given layer of the tree. + + The default 9-layer tree topology was deemed best for most workloads, + as it gives an optimal ratio of performance to configurability. However, + for some specific cases, this 9-layer topology might not be desired. + One example would be sending traffic to queues that are not a multiple + of 8. Because the maximum radix is limited to 8 in 9-layer topology, + the 9th queue has a different parent than the rest, and it's given + more bandwidth credits. This causes a problem when the system is + sending traffic to 9 queues: + + | tx_queue_0_packets: 24163396 + | tx_queue_1_packets: 24164623 + | tx_queue_2_packets: 24163188 + | tx_queue_3_packets: 24163701 + | tx_queue_4_packets: 24163683 + | tx_queue_5_packets: 24164668 + | tx_queue_6_packets: 23327200 + | tx_queue_7_packets: 24163853 + | tx_queue_8_packets: 91101417 < Too much traffic is sent from 9th + + To address this need, you can switch to a 5-layer topology, which + changes the maximum topology radix to 512. With this enhancement, + the performance characteristic is equal as all queues can be assigned + to the same parent in the tree. The obvious drawback of this solution + is a lower configuration depth of the tree. + + Use the ``tx_scheduling_layer`` parameter with the devlink command + to change the transmit scheduler topology. To use 5-layer topology, + use a value of 5. For example: + $ devlink dev param set pci/0000:16:00.0 name tx_scheduling_layers + value 5 cmode permanent + Use a value of 9 to set it back to the default value. + + You must do PCI slot powercycle for the selected topology to take effect. + + To verify that value has been set: + $ devlink dev param show pci/0000:16:00.0 name tx_scheduling_layers Info versions ============= diff --git a/Documentation/networking/devlink/nfp.rst b/Documentation/networking/devlink/nfp.rst index a1717db0dfcc..3093642bdae4 100644 --- a/Documentation/networking/devlink/nfp.rst +++ b/Documentation/networking/devlink/nfp.rst @@ -32,7 +32,7 @@ The ``nfp`` driver reports the following versions - Description * - ``board.id`` - fixed - - Part number identifying the board design + - Identifier of the board design * - ``board.rev`` - fixed - Revision of the board design @@ -42,6 +42,9 @@ The ``nfp`` driver reports the following versions * - ``board.model`` - fixed - Model name of the board design + * - ``board.part_number`` + - fixed + - Part number of the board and its components * - ``fw.bundle_id`` - stored, running - Firmware bundle id diff --git a/Documentation/networking/dns_resolver.rst b/Documentation/networking/dns_resolver.rst index add4d59a99a5..c0364f7070af 100644 --- a/Documentation/networking/dns_resolver.rst +++ b/Documentation/networking/dns_resolver.rst @@ -118,7 +118,7 @@ Keys of dns_resolver type can be read from userspace using keyctl_read() or Mechanism ========= -The dnsresolver module registers a key type called "dns_resolver". Keys of +The dns_resolver module registers a key type called "dns_resolver". Keys of this type are used to transport and cache DNS lookup results from userspace. When dns_query() is invoked, it calls request_key() to search the local @@ -152,4 +152,4 @@ Debugging Debugging messages can be turned on dynamically by writing a 1 into the following file:: - /sys/module/dnsresolver/parameters/debug + /sys/module/dns_resolver/parameters/debug diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index d583d9abf2f8..160bfb0ae8ba 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -1237,12 +1237,21 @@ Kernel response contents: ``ETHTOOL_A_TSINFO_TX_TYPES`` bitset supported Tx types ``ETHTOOL_A_TSINFO_RX_FILTERS`` bitset supported Rx filters ``ETHTOOL_A_TSINFO_PHC_INDEX`` u32 PTP hw clock index + ``ETHTOOL_A_TSINFO_STATS`` nested HW timestamping statistics ===================================== ====== ========================== ``ETHTOOL_A_TSINFO_PHC_INDEX`` is absent if there is no associated PHC (there is no special value for this case). The bitset attributes are omitted if they would be empty (no bit set). +Additional hardware timestamping statistics response contents: + + ===================================== ====== =================================== + ``ETHTOOL_A_TS_STAT_TX_PKTS`` uint Packets with Tx HW timestamps + ``ETHTOOL_A_TS_STAT_TX_LOST`` uint Tx HW timestamp not arrived count + ``ETHTOOL_A_TS_STAT_TX_ERR`` uint HW error request Tx timestamp count + ===================================== ====== =================================== + CABLE_TEST ========== @@ -1717,6 +1726,10 @@ Kernel response contents: PSE functions ``ETHTOOL_A_PODL_PSE_PW_D_STATUS`` u32 power detection status of the PoDL PSE. + ``ETHTOOL_A_C33_PSE_ADMIN_STATE`` u32 Operational state of the PoE + PSE functions. + ``ETHTOOL_A_C33_PSE_PW_D_STATUS`` u32 power detection status of the + PoE PSE. ====================================== ====== ============================= When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_STATE`` attribute identifies @@ -1728,6 +1741,12 @@ aPoDLPSEAdminState. Possible values are: .. kernel-doc:: include/uapi/linux/ethtool.h :identifiers: ethtool_podl_pse_admin_state +The same goes for ``ETHTOOL_A_C33_PSE_ADMIN_STATE`` implementing +``IEEE 802.3-2022`` 30.9.1.1.2 aPSEAdminState. + +.. kernel-doc:: include/uapi/linux/ethtool.h + :identifiers: ethtool_c33_pse_admin_state + When set, the optional ``ETHTOOL_A_PODL_PSE_PW_D_STATUS`` attribute identifies the power detection status of the PoDL PSE. The status depend on internal PSE state machine and automatic PD classification support. This option is @@ -1737,6 +1756,12 @@ Possible values are: .. kernel-doc:: include/uapi/linux/ethtool.h :identifiers: ethtool_podl_pse_pw_d_status +The same goes for ``ETHTOOL_A_C33_PSE_ADMIN_PW_D_STATUS`` implementing +``IEEE 802.3-2022`` 30.9.1.1.5 aPSEPowerDetectionStatus. + +.. kernel-doc:: include/uapi/linux/ethtool.h + :identifiers: ethtool_c33_pse_pw_d_status + PSE_SET ======= @@ -1747,6 +1772,7 @@ Request contents: ====================================== ====== ============================= ``ETHTOOL_A_PSE_HEADER`` nested request header ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` u32 Control PoDL PSE Admin state + ``ETHTOOL_A_C33_PSE_ADMIN_CONTROL`` u32 Control PSE Admin state ====================================== ====== ============================= When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` attribute is used @@ -1754,6 +1780,9 @@ to control PoDL PSE Admin functions. This option is implementing ``IEEE 802.3-2018`` 30.15.1.2.1 acPoDLPSEAdminControl. See ``ETHTOOL_A_PODL_PSE_ADMIN_STATE`` for supported values. +The same goes for ``ETHTOOL_A_C33_PSE_ADMIN_CONTROL`` implementing +``IEEE 802.3-2022`` 30.9.1.2.1 acPSEAdminControl. + RSS_GET ======= diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst index 7d8c5380492f..8eb9a5d40f31 100644 --- a/Documentation/networking/filter.rst +++ b/Documentation/networking/filter.rst @@ -513,7 +513,7 @@ JIT compiler ------------ The Linux kernel has a built-in BPF JIT compiler for x86_64, SPARC, -PowerPC, ARM, ARM64, MIPS, RISC-V and s390 and can be enabled through +PowerPC, ARM, ARM64, MIPS, RISC-V, s390, and ARC and can be enabled through CONFIG_BPF_JIT. The JIT compiler is transparently invoked for each attached filter from user space or for internal kernel users if it has been previously enabled by root:: @@ -650,7 +650,7 @@ before a conversion to the new layout is being done behind the scenes! Currently, the classic BPF format is being used for JITing on most 32-bit architectures, whereas x86-64, aarch64, s390x, powerpc64, -sparc64, arm32, riscv64, riscv32, loongarch64 perform JIT compilation +sparc64, arm32, riscv64, riscv32, loongarch64, arc perform JIT compilation from eBPF instruction set. Testing diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 473d72c36d61..7664c0bfe461 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -93,6 +93,7 @@ Contents: plip ppp_generic proc_net_tcp + pse-pd/index radiotap-headers rds regulatory diff --git a/Documentation/networking/nf_conntrack-sysctl.rst b/Documentation/networking/nf_conntrack-sysctl.rst index c383a394c665..238b66d0e059 100644 --- a/Documentation/networking/nf_conntrack-sysctl.rst +++ b/Documentation/networking/nf_conntrack-sysctl.rst @@ -222,11 +222,11 @@ nf_flowtable_tcp_timeout - INTEGER (seconds) Control offload timeout for tcp connections. TCP connections may be offloaded from nf conntrack to nf flow table. - Once aged, the connection is returned to nf conntrack with tcp pickup timeout. + Once aged, the connection is returned to nf conntrack. nf_flowtable_udp_timeout - INTEGER (seconds) default 30 Control offload timeout for udp connections. UDP connections may be offloaded from nf conntrack to nf flow table. - Once aged, the connection is returned to nf conntrack with udp pickup timeout. + Once aged, the connection is returned to nf conntrack. diff --git a/Documentation/networking/pse-pd/index.rst b/Documentation/networking/pse-pd/index.rst new file mode 100644 index 000000000000..de28a5aee316 --- /dev/null +++ b/Documentation/networking/pse-pd/index.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Power Sourcing Equipment (PSE) Documentation +============================================ + +.. toctree:: + :maxdepth: 2 + + introduction + pse-pi diff --git a/Documentation/networking/pse-pd/introduction.rst b/Documentation/networking/pse-pd/introduction.rst new file mode 100644 index 000000000000..e3d3faaef717 --- /dev/null +++ b/Documentation/networking/pse-pd/introduction.rst @@ -0,0 +1,73 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Power Sourcing Equipment (PSE) in IEEE 802.3 Standard +===================================================== + +Overview +-------- + +Power Sourcing Equipment (PSE) is essential in networks for delivering power +along with data over Ethernet cables. It usually refers to devices like +switches and hubs that supply power to Powered Devices (PDs) such as IP +cameras, VoIP phones, and wireless access points. + +PSE vs. PoDL PSE +---------------- + +PSE in the IEEE 802.3 standard generally refers to equipment that provides +power alongside data over Ethernet cables, typically associated with Power over +Ethernet (PoE). + +PoDL PSE, or Power over Data Lines PSE, specifically denotes PSEs operating +with single balanced twisted-pair PHYs, as per Clause 104 of IEEE 802.3. PoDL +is significant in contexts like automotive and industrial controls where power +and data delivery over a single pair is advantageous. + +IEEE 802.3-2018 Addendums and Related Clauses +--------------------------------------------- + +Key addenda to the IEEE 802.3-2018 standard relevant to power delivery over +Ethernet are as follows: + +- **802.3af (Approved in 2003-06-12)**: Known as PoE in the market, detailed in + Clause 33, delivering up to 15.4W of power. +- **802.3at (Approved in 2009-09-11)**: Marketed as PoE+, enhancing PoE as + covered in Clause 33, increasing power delivery to up to 30W. +- **802.3bt (Approved in 2018-09-27)**: Known as 4PPoE in the market, outlined + in Clause 33. Type 3 delivers up to 60W, and Type 4 up to 100W. +- **802.3bu (Approved in 2016-12-07)**: Formerly referred to as PoDL, detailed + in Clause 104. Introduces Classes 0 - 9. Class 9 PoDL PSE delivers up to ~65W + +Kernel Naming Convention Recommendations +---------------------------------------- + +For clarity and consistency within the Linux kernel's networking subsystem, the +following naming conventions are recommended: + +- For general PSE (PoE) code, use "c33_pse" key words. For example: + ``enum ethtool_c33_pse_admin_state c33_admin_control;``. + This aligns with Clause 33, encompassing various PoE forms. + +- For PoDL PSE - specific code, use "podl_pse". For example: + ``enum ethtool_podl_pse_admin_state podl_admin_control;`` to differentiate + PoDL PSE settings according to Clause 104. + +Summary of Clause 33: Data Terminal Equipment (DTE) Power via Media Dependent Interface (MDI) +--------------------------------------------------------------------------------------------- + +Clause 33 of the IEEE 802.3 standard defines the functional and electrical +characteristics of Powered Device (PD) and Power Sourcing Equipment (PSE). +These entities enable power delivery using the same generic cabling as for data +transmission, integrating power with data communication for devices such as +10BASE-T, 100BASE-TX, or 1000BASE-T. + +Summary of Clause 104: Power over Data Lines (PoDL) of Single Balanced Twisted-Pair Ethernet +-------------------------------------------------------------------------------------------- + +Clause 104 of the IEEE 802.3 standard delineates the functional and electrical +characteristics of PoDL Powered Devices (PDs) and PoDL Power Sourcing Equipment +(PSEs). These are designed for use with single balanced twisted-pair Ethernet +Physical Layers. In this clause, 'PSE' refers specifically to PoDL PSE, and +'PD' to PoDL PD. The key intent is to provide devices with a unified interface +for both data and the power required to process this data over a single +balanced twisted-pair Ethernet connection. diff --git a/Documentation/networking/pse-pd/pse-pi.rst b/Documentation/networking/pse-pd/pse-pi.rst new file mode 100644 index 000000000000..5cad14fedc13 --- /dev/null +++ b/Documentation/networking/pse-pd/pse-pi.rst @@ -0,0 +1,301 @@ +.. SPDX-License-Identifier: GPL-2.0 + +PSE Power Interface (PSE PI) Documentation +========================================== + +The Power Sourcing Equipment Power Interface (PSE PI) plays a pivotal role in +the architecture of Power over Ethernet (PoE) systems. It is essentially a +blueprint that outlines how one or multiple power sources are connected to the +eight-pin modular jack, commonly known as the Ethernet RJ45 port. This +connection scheme is crucial for enabling the delivery of power alongside data +over Ethernet cables. + +Documentation and Standards +--------------------------- + +The IEEE 802.3 standard provides detailed documentation on the PSE PI. +Specifically: + +- Section "33.2.3 PI pin assignments" covers the pin assignments for PoE + systems that utilize two pairs for power delivery. +- Section "145.2.4 PSE PI" addresses the configuration for PoE systems that + deliver power over all four pairs of an Ethernet cable. + +PSE PI and Single Pair Ethernet +------------------------------- + +Single Pair Ethernet (SPE) represents a different approach to Ethernet +connectivity, utilizing just one pair of conductors for both data and power +transmission. Unlike the configurations detailed in the PSE PI for standard +Ethernet, which can involve multiple power sourcing arrangements across four or +two pairs of wires, SPE operates on a simpler model due to its single-pair +design. As a result, the complexities of choosing between alternative pin +assignments for power delivery, as described in the PSE PI for multi-pair +Ethernet, are not applicable to SPE. + +Understanding PSE PI +-------------------- + +The Power Sourcing Equipment Power Interface (PSE PI) is a framework defining +how Power Sourcing Equipment (PSE) delivers power to Powered Devices (PDs) over +Ethernet cables. It details two main configurations for power delivery, known +as Alternative A and Alternative B, which are distinguished not only by their +method of power transmission but also by the implications for polarity and data +transmission direction. + +Alternative A and B Overview +---------------------------- + +- **Alternative A:** Utilizes RJ45 conductors 1, 2, 3 and 6. In either case of + networks 10/100BaseT or 1G/2G/5G/10GBaseT, the pairs used are carrying data. + The power delivery's polarity in this alternative can vary based on the MDI + (Medium Dependent Interface) or MDI-X (Medium Dependent Interface Crossover) + configuration. + +- **Alternative B:** Utilizes RJ45 conductors 4, 5, 7 and 8. In case of + 10/100BaseT network the pairs used are spare pairs without data and are less + influenced by data transmission direction. This is not the case for + 1G/2G/5G/10GBaseT network. Alternative B includes two configurations with + different polarities, known as variant X and variant S, to accommodate + different network requirements and device specifications. + +Table 145-3 PSE Pinout Alternatives +----------------------------------- + +The following table outlines the pin configurations for both Alternative A and +Alternative B. + ++------------+-------------------+-----------------+-----------------+-----------------+ +| Conductor | Alternative A | Alternative A | Alternative B | Alternative B | +| | (MDI-X) | (MDI) | (X) | (S) | ++============+===================+=================+=================+=================+ +| 1 | Negative V | Positive V | - | - | ++------------+-------------------+-----------------+-----------------+-----------------+ +| 2 | Negative V | Positive V | - | - | ++------------+-------------------+-----------------+-----------------+-----------------+ +| 3 | Positive V | Negative V | - | - | ++------------+-------------------+-----------------+-----------------+-----------------+ +| 4 | - | - | Negative V | Positive V | ++------------+-------------------+-----------------+-----------------+-----------------+ +| 5 | - | - | Negative V | Positive V | ++------------+-------------------+-----------------+-----------------+-----------------+ +| 6 | Positive V | Negative V | - | - | ++------------+-------------------+-----------------+-----------------+-----------------+ +| 7 | - | - | Positive V | Negative V | ++------------+-------------------+-----------------+-----------------+-----------------+ +| 8 | - | - | Positive V | Negative V | ++------------+-------------------+-----------------+-----------------+-----------------+ + +.. note:: + - "Positive V" and "Negative V" indicate the voltage polarity for each pin. + - "-" indicates that the pin is not used for power delivery in that + specific configuration. + +PSE PI compatibilities +---------------------- + +The following table outlines the compatibility between the pinout alternative +and the 1000/2.5G/5G/10GBaseT in the PSE 2 pairs connection. + ++---------+---------------+---------------------+-----------------------+ +| Variant | Alternative | Power Feeding Type | Compatibility with | +| | (A/B) | (Direct/Phantom) | 1000/2.5G/5G/10GBaseT | ++=========+===============+=====================+=======================+ +| 1 | A | Phantom | Yes | ++---------+---------------+---------------------+-----------------------+ +| 2 | B | Phantom | Yes | ++---------+---------------+---------------------+-----------------------+ +| 3 | B | Direct | No | ++---------+---------------+---------------------+-----------------------+ + +.. note:: + - "Direct" indicate a variant where the power is injected directly to pairs + without using magnetics in case of spare pairs. + - "Phantom" indicate power path over coils/magnetics as it is done for + Alternative A variant. + +In case of PSE 4 pairs, a PSE supporting only 10/100BaseT (which mean Direct +Power on pinout Alternative B) is not compatible with a 4 pairs +1000/2.5G/5G/10GBaseT. + +PSE Power Interface (PSE PI) Connection Diagram +----------------------------------------------- + +The diagram below illustrates the connection architecture between the RJ45 +port, the Ethernet PHY (Physical Layer), and the PSE PI (Power Sourcing +Equipment Power Interface), demonstrating how power and data are delivered +simultaneously through an Ethernet cable. The RJ45 port serves as the physical +interface for these connections, with each of its eight pins connected to both +the Ethernet PHY for data transmission and the PSE PI for power delivery. + +.. code-block:: + + +--------------------------+ + | | + | RJ45 Port | + | | + +--+--+--+--+--+--+--+--+--+ +-------------+ + 1| 2| 3| 4| 5| 6| 7| 8| | | + | | | | | | | o-------------------+ | + | | | | | | o--|-------------------+ +<--- PSE 1 + | | | | | o--|--|-------------------+ | + | | | | o--|--|--|-------------------+ | + | | | o--|--|--|--|-------------------+ PSE PI | + | | o--|--|--|--|--|-------------------+ | + | o--|--|--|--|--|--|-------------------+ +<--- PSE 2 (optional) + o--|--|--|--|--|--|--|-------------------+ | + | | | | | | | | | | + +--+--+--+--+--+--+--+--+--+ +-------------+ + | | + | Ethernet PHY | + | | + +--------------------------+ + +Simple PSE PI Configuration for Alternative A +--------------------------------------------- + +The diagram below illustrates a straightforward PSE PI (Power Sourcing +Equipment Power Interface) configuration designed to support the Alternative A +setup for Power over Ethernet (PoE). This implementation is tailored to provide +power delivery through the data-carrying pairs of an Ethernet cable, suitable +for either MDI or MDI-X configurations, albeit supporting one variation at a +time. + +.. code-block:: + + +-------------+ + | PSE PI | + 8 -----+ +-------------+ + 7 -----+ Rail 1 | + 6 -----+------+----------------------+ + 5 -----+ | | + 4 -----+ | Rail 2 | PSE 1 + 3 -----+------/ +------------+ + 2 -----+--+-------------/ | + 1 -----+--/ +-------------+ + | + +-------------+ + +In this configuration: + +- Pins 1 and 2, as well as pins 3 and 6, are utilized for power delivery in + addition to data transmission. This aligns with the standard wiring for + 10/100BaseT Ethernet networks where these pairs are used for data. +- Rail 1 and Rail 2 represent the positive and negative voltage rails, with + Rail 1 connected to pins 1 and 2, and Rail 2 connected to pins 3 and 6. + More advanced PSE PI configurations may include integrated or external + switches to change the polarity of the voltage rails, allowing for + compatibility with both MDI and MDI-X configurations. + +More complex PSE PI configurations may include additional components, to support +Alternative B, or to provide additional features such as power management, or +additional power delivery capabilities such as 2-pair or 4-pair power delivery. + +.. code-block:: + + +-------------+ + | PSE PI | + | +---+ + 8 -----+--------+ | +-------------+ + 7 -----+--------+ | Rail 1 | + 6 -----+--------+ +-----------------+ + 5 -----+--------+ | | + 4 -----+--------+ | Rail 2 | PSE 1 + 3 -----+--------+ +----------------+ + 2 -----+--------+ | | + 1 -----+--------+ | +-------------+ + | +---+ + +-------------+ + +Device Tree Configuration: Describing PSE PI Configurations +----------------------------------------------------------- + +The necessity for a separate PSE PI node in the device tree is influenced by +the intricacy of the Power over Ethernet (PoE) system's setup. Here are +descriptions of both simple and complex PSE PI configurations to illustrate +this decision-making process: + +**Simple PSE PI Configuration:** +In a straightforward scenario, the PSE PI setup involves a direct, one-to-one +connection between a single PSE controller and an Ethernet port. This setup +typically supports basic PoE functionality without the need for dynamic +configuration or management of multiple power delivery modes. For such simple +configurations, detailing the PSE PI within the existing PSE controller's node +may suffice, as the system does not encompass additional complexity that +warrants a separate node. The primary focus here is on the clear and direct +association of power delivery to a specific Ethernet port. + +**Complex PSE PI Configuration:** +Contrastingly, a complex PSE PI setup may encompass multiple PSE controllers or +auxiliary circuits that collectively manage power delivery to one Ethernet +port. Such configurations might support a range of PoE standards and require +the capability to dynamically configure power delivery based on the operational +mode (e.g., PoE2 versus PoE4) or specific requirements of connected devices. In +these instances, a dedicated PSE PI node becomes essential for accurately +documenting the system architecture. This node would serve to detail the +interactions between different PSE controllers, the support for various PoE +modes, and any additional logic required to coordinate power delivery across +the network infrastructure. + +**Guidance:** + +For simple PSE setups, including PSE PI information in the PSE controller node +might suffice due to the straightforward nature of these systems. However, +complex configurations, involving multiple components or advanced PoE features, +benefit from a dedicated PSE PI node. This method adheres to IEEE 802.3 +specifications, improving documentation clarity and ensuring accurate +representation of the PoE system's complexity. + +PSE PI Node: Essential Information +---------------------------------- + +The PSE PI (Power Sourcing Equipment Power Interface) node in a device tree can +include several key pieces of information critical for defining the power +delivery capabilities and configurations of a PoE (Power over Ethernet) system. +Below is a list of such information, along with explanations for their +necessity and reasons why they might not be found within a PSE controller node: + +1. **Powered Pairs Configuration** + + - *Description:* Identifies the pairs used for power delivery in the + Ethernet cable. + - *Necessity:* Essential to ensure the correct pairs are powered according + to the board's design. + - *PSE Controller Node:* Typically lacks details on physical pair usage, + focusing on power regulation. + +2. **Polarity of Powered Pairs** + + - *Description:* Specifies the polarity (positive or negative) for each + powered pair. + - *Necessity:* Critical for safe and effective power transmission to PDs. + - *PSE Controller Node:* Polarity management may exceed the standard + functionalities of PSE controllers. + +3. **PSE Cells Association** + + - *Description:* Details the association of PSE cells with Ethernet ports or + pairs in multi-cell configurations. + - *Necessity:* Allows for optimized power resource allocation in complex + systems. + - *PSE Controller Node:* Controllers may not manage cell associations + directly, focusing instead on power flow regulation. + +4. **Support for PoE Standards** + + - *Description:* Lists the PoE standards and configurations supported by the + system. + - *Necessity:* Ensures system compatibility with various PDs and adherence + to industry standards. + - *PSE Controller Node:* Specific capabilities may depend on the overall PSE + PI design rather than the controller alone. Multiple PSE cells per PI + do not necessarily imply support for multiple PoE standards. + +5. **Protection Mechanisms** + + - *Description:* Outlines additional protection mechanisms, such as + overcurrent protection and thermal management. + - *Necessity:* Provides extra safety and stability, complementing PSE + controller protections. + - *PSE Controller Node:* Some protections may be implemented via + board-specific hardware or algorithms external to the controller. diff --git a/Documentation/networking/xfrm_proc.rst b/Documentation/networking/xfrm_proc.rst index 0a771c5a7399..973d1571acac 100644 --- a/Documentation/networking/xfrm_proc.rst +++ b/Documentation/networking/xfrm_proc.rst @@ -73,6 +73,9 @@ XfrmAcquireError: XfrmFwdHdrError: Forward routing of a packet is not allowed +XfrmInStateDirError: + State direction mismatch (lookup found an output state on the input path, expected input or no direction) + Outbound errors ~~~~~~~~~~~~~~~ XfrmOutError: @@ -111,3 +114,6 @@ XfrmOutPolError: XfrmOutStateInvalid: State is invalid, perhaps expired + +XfrmOutStateDirError: + State direction mismatch (lookup found an input state on the output path, expected output or no direction) diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst index 12070320307e..e2c1fb8a569a 100644 --- a/Documentation/power/pci.rst +++ b/Documentation/power/pci.rst @@ -333,7 +333,7 @@ struct pci_dev. The PCI subsystem's first task related to device power management is to prepare the device for power management and initialize the fields of struct pci_dev used for this purpose. This happens in two functions defined in -drivers/pci/pci.c, pci_pm_init() and platform_pci_wakeup_init(). +drivers/pci/, pci_pm_init() and pci_acpi_setup(). The first of these functions checks if the device supports native PCI PM and if that's the case the offset of its power management capability structure diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 7ef8de58f7f8..5685d7bfe4d0 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -31,7 +31,7 @@ you probably needn't concern yourself with pcmciautils. ====================== =============== ======================================== GNU C 5.1 gcc --version Clang/LLVM (optional) 13.0.1 clang --version -Rust (optional) 1.76.0 rustc --version +Rust (optional) 1.78.0 rustc --version bindgen (optional) 0.65.1 bindgen --version GNU make 3.82 make --version bash 4.2 bash --version @@ -62,6 +62,7 @@ Sphinx\ [#f1]_ 2.4.4 sphinx-build --version cpio any cpio --version GNU tar 1.28 tar --version gtags (optional) 6.6.5 gtags --version +mkimage (optional) 2017.01 mkimage --version ====================== =============== ======================================== .. [#f1] Sphinx is needed only to build the Kernel documentation @@ -189,6 +190,14 @@ The kernel build requires GNU GLOBAL version 6.6.5 or later to generate tag files through ``make gtags``. This is due to its use of the gtags ``-C (--directory)`` flag. +mkimage +------- + +This tool is used when building a Flat Image Tree (FIT), commonly used on ARM +platforms. The tool is available via the ``u-boot-tools`` package or can be +built from the U-Boot source code. See the instructions at +https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux + System utilities **************** diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst index ce6753a674f3..49ba1410cfce 100644 --- a/Documentation/process/handling-regressions.rst +++ b/Documentation/process/handling-regressions.rst @@ -284,7 +284,7 @@ What else is there to known about regressions? Check out Documentation/admin-guide/reporting-regressions.rst, it covers a lot of other aspects you want might want to be aware of: - * the purpose of the "no regressions rule" + * the purpose of the "no regressions" rule * what issues actually qualify as regression diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst index 497bb39727c8..64739968afa6 100644 --- a/Documentation/process/maintainer-tip.rst +++ b/Documentation/process/maintainer-tip.rst @@ -409,20 +409,20 @@ See :ref:`resend_reminders`. Merge window ^^^^^^^^^^^^ -Please do not expect large patch series to be handled during the merge -window or even during the week before. Such patches should be submitted in -mergeable state *at* *least* a week before the merge window opens. -Exceptions are made for bug fixes and *sometimes* for small standalone -drivers for new hardware or minimally invasive patches for hardware -enablement. +Please do not expect patches to be reviewed or merged by tip +maintainers around or during the merge window. The trees are closed +to all but urgent fixes during this time. They reopen once the merge +window closes and a new -rc1 kernel has been released. + +Large series should be submitted in mergeable state *at* *least* a week +before the merge window opens. Exceptions are made for bug fixes and +*sometimes* for small standalone drivers for new hardware or minimally +invasive patches for hardware enablement. During the merge window, the maintainers instead focus on following the upstream changes, fixing merge window fallout, collecting bug fixes, and allowing themselves a breath. Please respect that. -The release candidate -rc1 is the starting point for new patches to be -applied which are targeted for the next merge window. - So called _urgent_ branches will be merged into mainline during the stabilization phase of each release. diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 1704f1c686d0..edf90bbe30f4 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -6,29 +6,29 @@ Everything you ever wanted to know about Linux -stable releases Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree: - - It or an equivalent fix must already exist in Linus' tree (upstream). - - It must be obviously correct and tested. - - It cannot be bigger than 100 lines, with context. - - It must follow the - :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` - rules. - - It must either fix a real bug that bothers people or just add a device ID. - To elaborate on the former: - - - It fixes a problem like an oops, a hang, data corruption, a real security - issue, a hardware quirk, a build error (but not for things marked - CONFIG_BROKEN), or some "oh, that's not good" issue. - - Serious issues as reported by a user of a distribution kernel may also - be considered if they fix a notable performance or interactivity issue. - As these fixes are not as obvious and have a higher risk of a subtle - regression they should only be submitted by a distribution kernel - maintainer and include an addendum linking to a bugzilla entry if it - exists and additional information on the user-visible impact. - - No "This could be a problem..." type of things like a "theoretical race - condition", unless an explanation of how the bug can be exploited is also - provided. - - No "trivial" fixes without benefit for users (spelling changes, whitespace - cleanups, etc). +- It or an equivalent fix must already exist in Linux mainline (upstream). +- It must be obviously correct and tested. +- It cannot be bigger than 100 lines, with context. +- It must follow the + :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` + rules. +- It must either fix a real bug that bothers people or just add a device ID. + To elaborate on the former: + + - It fixes a problem like an oops, a hang, data corruption, a real security + issue, a hardware quirk, a build error (but not for things marked + CONFIG_BROKEN), or some "oh, that's not good" issue. + - Serious issues as reported by a user of a distribution kernel may also + be considered if they fix a notable performance or interactivity issue. + As these fixes are not as obvious and have a higher risk of a subtle + regression they should only be submitted by a distribution kernel + maintainer and include an addendum linking to a bugzilla entry if it + exists and additional information on the user-visible impact. + - No "This could be a problem..." type of things like a "theoretical race + condition", unless an explanation of how the bug can be exploited is also + provided. + - No "trivial" fixes without benefit for users (spelling changes, whitespace + cleanups, etc). Procedure for submitting patches to the -stable tree @@ -42,11 +42,11 @@ Procedure for submitting patches to the -stable tree There are three options to submit a change to -stable trees: - 1. Add a 'stable tag' to the description of a patch you then submit for - mainline inclusion. - 2. Ask the stable team to pick up a patch already mainlined. - 3. Submit a patch to the stable team that is equivalent to a change already - mainlined. +1. Add a 'stable tag' to the description of a patch you then submit for + mainline inclusion. +2. Ask the stable team to pick up a patch already mainlined. +3. Submit a patch to the stable team that is equivalent to a change already + mainlined. The sections below describe each of the options in more detail. @@ -68,82 +68,72 @@ Option 1 ******** To have a patch you submit for mainline inclusion later automatically picked up -for stable trees, add the tag +for stable trees, add this tag in the sign-off area:: -.. code-block:: none + Cc: stable@vger.kernel.org - Cc: stable@vger.kernel.org +Use ``Cc: stable@kernel.org`` instead when fixing unpublished vulnerabilities: +it reduces the chance of accidentally exposing the fix to the public by way of +'git send-email', as mails sent to that address are not delivered anywhere. -in the sign-off area. Once the patch is mainlined it will be applied to the -stable tree without anything else needing to be done by the author or -subsystem maintainer. +Once the patch is mainlined it will be applied to the stable tree without +anything else needing to be done by the author or subsystem maintainer. -To sent additional instructions to the stable team, use a shell-style inline -comment: +To send additional instructions to the stable team, use a shell-style inline +comment to pass arbitrary or predefined notes: - * To specify any additional patch prerequisites for cherry picking use the - following format in the sign-off area: +* Specify any additional patch prerequisites for cherry picking:: - .. code-block:: none + Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle + Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle + Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic + Cc: <stable@vger.kernel.org> # 3.3.x + Signed-off-by: Ingo Molnar <mingo@elte.hu> - Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle - Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle - Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic - Cc: <stable@vger.kernel.org> # 3.3.x - Signed-off-by: Ingo Molnar <mingo@elte.hu> + The tag sequence has the meaning of:: - The tag sequence has the meaning of: + git cherry-pick a1f84a3 + git cherry-pick 1b9508f + git cherry-pick fd21073 + git cherry-pick <this commit> - .. code-block:: none + Note that for a patch series, you do not have to list as prerequisites the + patches present in the series itself. For example, if you have the following + patch series:: - git cherry-pick a1f84a3 - git cherry-pick 1b9508f - git cherry-pick fd21073 - git cherry-pick <this commit> + patch1 + patch2 - Note that for a patch series, you do not have to list as prerequisites the - patches present in the series itself. For example, if you have the following - patch series: + where patch2 depends on patch1, you do not have to list patch1 as + prerequisite of patch2 if you have already marked patch1 for stable + inclusion. - .. code-block:: none +* Point out kernel version prerequisites:: - patch1 - patch2 + Cc: <stable@vger.kernel.org> # 3.3.x - where patch2 depends on patch1, you do not have to list patch1 as - prerequisite of patch2 if you have already marked patch1 for stable - inclusion. + The tag has the meaning of:: - * For patches that may have kernel version prerequisites specify them using - the following format in the sign-off area: + git cherry-pick <this commit> - .. code-block:: none + For each "-stable" tree starting with the specified version. - Cc: <stable@vger.kernel.org> # 3.3.x + Note, such tagging is unnecessary if the stable team can derive the + appropriate versions from Fixes: tags. - The tag has the meaning of: +* Delay pick up of patches:: - .. code-block:: none + Cc: <stable@vger.kernel.org> # after -rc3 - git cherry-pick <this commit> +* Point out known problems:: - For each "-stable" tree starting with the specified version. + Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3 - Note, such tagging is unnecessary if the stable team can derive the - appropriate versions from Fixes: tags. +There furthermore is a variant of the stable tag you can use to make the stable +team's backporting tools (e.g AUTOSEL or scripts that look for commits +containing a 'Fixes:' tag) ignore a change:: - * To delay pick up of patches, use the following format: - - .. code-block:: none - - Cc: <stable@vger.kernel.org> # after 4 weeks in mainline - - * For any other requests, just add a note to the stable tag. This for example - can be used to point out known problems: - - .. code-block:: none - - Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3 + Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present .. _option_2: @@ -163,17 +153,13 @@ Option 3 Send the patch, after verifying that it follows the above rules, to stable@vger.kernel.org and mention the kernel versions you wish it to be applied to. When doing so, you must note the upstream commit ID in the changelog of your -submission with a separate line above the commit text, like this: - -.. code-block:: none - - commit <sha1> upstream. +submission with a separate line above the commit text, like this:: -or alternatively: + commit <sha1> upstream. -.. code-block:: none +Or alternatively:: - [ Upstream commit <sha1> ] + [ Upstream commit <sha1> ] If the submitted patch deviates from the original upstream patch (for example because it had to be adjusted for the older API), this must be very clearly @@ -194,55 +180,55 @@ developers and by the relevant subsystem maintainer. Review cycle ------------ - - When the -stable maintainers decide for a review cycle, the patches will be - sent to the review committee, and the maintainer of the affected area of - the patch (unless the submitter is the maintainer of the area) and CC: to - the linux-kernel mailing list. - - The review committee has 48 hours in which to ACK or NAK the patch. - - If the patch is rejected by a member of the committee, or linux-kernel - members object to the patch, bringing up issues that the maintainers and - members did not realize, the patch will be dropped from the queue. - - The ACKed patches will be posted again as part of release candidate (-rc) - to be tested by developers and testers. - - Usually only one -rc release is made, however if there are any outstanding - issues, some patches may be modified or dropped or additional patches may - be queued. Additional -rc releases are then released and tested until no - issues are found. - - Responding to the -rc releases can be done on the mailing list by sending - a "Tested-by:" email with any testing information desired. The "Tested-by:" - tags will be collected and added to the release commit. - - At the end of the review cycle, the new -stable release will be released - containing all the queued and tested patches. - - Security patches will be accepted into the -stable tree directly from the - security kernel team, and not go through the normal review cycle. - Contact the kernel security team for more details on this procedure. +- When the -stable maintainers decide for a review cycle, the patches will be + sent to the review committee, and the maintainer of the affected area of + the patch (unless the submitter is the maintainer of the area) and CC: to + the linux-kernel mailing list. +- The review committee has 48 hours in which to ACK or NAK the patch. +- If the patch is rejected by a member of the committee, or linux-kernel + members object to the patch, bringing up issues that the maintainers and + members did not realize, the patch will be dropped from the queue. +- The ACKed patches will be posted again as part of release candidate (-rc) + to be tested by developers and testers. +- Usually only one -rc release is made, however if there are any outstanding + issues, some patches may be modified or dropped or additional patches may + be queued. Additional -rc releases are then released and tested until no + issues are found. +- Responding to the -rc releases can be done on the mailing list by sending + a "Tested-by:" email with any testing information desired. The "Tested-by:" + tags will be collected and added to the release commit. +- At the end of the review cycle, the new -stable release will be released + containing all the queued and tested patches. +- Security patches will be accepted into the -stable tree directly from the + security kernel team, and not go through the normal review cycle. + Contact the kernel security team for more details on this procedure. Trees ----- - - The queues of patches, for both completed versions and in progress - versions can be found at: +- The queues of patches, for both completed versions and in progress + versions can be found at: - https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git + https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git - - The finalized and tagged releases of all stable kernels can be found - in separate branches per version at: +- The finalized and tagged releases of all stable kernels can be found + in separate branches per version at: - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git - - The release candidate of all stable kernel versions can be found at: +- The release candidate of all stable kernel versions can be found at: - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ - .. warning:: - The -stable-rc tree is a snapshot in time of the stable-queue tree and - will change frequently, hence will be rebased often. It should only be - used for testing purposes (e.g. to be consumed by CI systems). + .. warning:: + The -stable-rc tree is a snapshot in time of the stable-queue tree and + will change frequently, hence will be rebased often. It should only be + used for testing purposes (e.g. to be consumed by CI systems). Review committee ---------------- - - This is made up of a number of kernel developers who have volunteered for - this task, and a few that haven't. +- This is made up of a number of kernel developers who have volunteered for + this task, and a few that haven't. diff --git a/Documentation/rust/general-information.rst b/Documentation/rust/general-information.rst index 081397827a7e..4bb6ac12d482 100644 --- a/Documentation/rust/general-information.rst +++ b/Documentation/rust/general-information.rst @@ -64,6 +64,63 @@ but it is intended that coverage is expanded as time goes on. "Leaf" modules (e.g. drivers) should not use the C bindings directly. Instead, subsystems should provide as-safe-as-possible abstractions as needed. +.. code-block:: + + rust/bindings/ + (rust/helpers.c) + + include/ -----+ <-+ + | | + drivers/ rust/kernel/ +----------+ <-+ | + fs/ | bindgen | | + .../ +-------------------+ +----------+ --+ | + | Abstractions | | | + +---------+ | +------+ +------+ | +----------+ | | + | my_foo | -----> | | foo | | bar | | -------> | Bindings | <-+ | + | driver | Safe | | sub- | | sub- | | Unsafe | | | + +---------+ | |system| |system| | | bindings | <-----+ + | | +------+ +------+ | | crate | | + | | kernel crate | +----------+ | + | +-------------------+ | + | | + +------------------# FORBIDDEN #--------------------------------+ + +The main idea is to encapsulate all direct interaction with the kernel's C APIs +into carefully reviewed and documented abstractions. Then users of these +abstractions cannot introduce undefined behavior (UB) as long as: + +#. The abstractions are correct ("sound"). +#. Any ``unsafe`` blocks respect the safety contract necessary to call the + operations inside the block. Similarly, any ``unsafe impl``\ s respect the + safety contract necessary to implement the trait. + +Bindings +~~~~~~~~ + +By including a C header from ``include/`` into +``rust/bindings/bindings_helper.h``, the ``bindgen`` tool will auto-generate the +bindings for the included subsystem. After building, see the ``*_generated.rs`` +output files in the ``rust/bindings/`` directory. + +For parts of the C header that ``bindgen`` does not auto generate, e.g. C +``inline`` functions or non-trivial macros, it is acceptable to add a small +wrapper function to ``rust/helpers.c`` to make it available for the Rust side as +well. + +Abstractions +~~~~~~~~~~~~ + +Abstractions are the layer between the bindings and the in-kernel users. They +are located in ``rust/kernel/`` and their role is to encapsulate the unsafe +access to the bindings into an as-safe-as-possible API that they expose to their +users. Users of the abstractions include things like drivers or file systems +written in Rust. + +Besides the safety aspect, the abstractions are supposed to be "ergonomic", in +the sense that they turn the C interfaces into "idiomatic" Rust code. Basic +examples are to turn the C resource acquisition and release into Rust +constructors and destructors or C integer error codes into Rust's ``Result``\ s. + Conditional compilation ----------------------- diff --git a/Documentation/rust/testing.rst b/Documentation/rust/testing.rst index 6658998d1b6c..acfd0c2be48d 100644 --- a/Documentation/rust/testing.rst +++ b/Documentation/rust/testing.rst @@ -6,10 +6,11 @@ Testing This document contains useful information how to test the Rust code in the kernel. -There are two sorts of tests: +There are three sorts of tests: - The KUnit tests. - The ``#[test]`` tests. +- The Kselftests. The KUnit tests --------------- @@ -133,3 +134,25 @@ Additionally, there are the ``#[test]`` tests. These can be run using the This requires the kernel ``.config`` and downloads external repositories. It runs the ``#[test]`` tests on the host (currently) and thus is fairly limited in what these tests can test. + +The Kselftests +-------------- + +Kselftests are also available in the ``tools/testing/selftests/rust`` folder. + +The kernel config options required for the tests are listed in the +``tools/testing/selftests/rust/config`` file and can be included with the aid +of the ``merge_config.sh`` script:: + + ./scripts/kconfig/merge_config.sh .config tools/testing/selftests/rust/config + +The kselftests are built within the kernel source tree and are intended to +be executed on a system that is running the same kernel. + +Once a kernel matching the source tree has been installed and booted, the +tests can be compiled and executed using the following command:: + + make TARGETS="rust" kselftest + +Refer to Documentation/dev-tools/kselftest.rst for the general Kselftest +documentation. diff --git a/Documentation/scheduler/sched-domains.rst b/Documentation/scheduler/sched-domains.rst index e57ad28301bd..5e996fe973b1 100644 --- a/Documentation/scheduler/sched-domains.rst +++ b/Documentation/scheduler/sched-domains.rst @@ -31,21 +31,21 @@ is treated as one entity. The load of a group is defined as the sum of the load of each of its member CPUs, and only when the load of a group becomes out of balance are tasks moved between groups. -In kernel/sched/core.c, trigger_load_balance() is run periodically on each CPU -through scheduler_tick(). It raises a softirq after the next regularly scheduled +In kernel/sched/core.c, sched_balance_trigger() is run periodically on each CPU +through sched_tick(). It raises a softirq after the next regularly scheduled rebalancing event for the current runqueue has arrived. The actual load -balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run +balancing workhorse, sched_balance_softirq()->sched_balance_domains(), is then run in softirq context (SCHED_SOFTIRQ). The latter function takes two arguments: the runqueue of current CPU and whether -the CPU was idle at the time the scheduler_tick() happened and iterates over all +the CPU was idle at the time the sched_tick() happened and iterates over all sched domains our CPU is on, starting from its base domain and going up the ->parent chain. While doing that, it checks to see if the current domain has exhausted its -rebalance interval. If so, it runs load_balance() on that domain. It then checks +rebalance interval. If so, it runs sched_balance_rq() on that domain. It then checks the parent sched_domain (if it exists), and the parent of the parent and so forth. -Initially, load_balance() finds the busiest group in the current sched domain. +Initially, sched_balance_rq() finds the busiest group in the current sched domain. If it succeeds, it looks for the busiest runqueue of all the CPUs' runqueues in that group. If it manages to find such a runqueue, it locks both our initial CPU's runqueue and the newly found busiest one and starts moving tasks from it diff --git a/Documentation/scheduler/sched-stats.rst b/Documentation/scheduler/sched-stats.rst index 03c062915998..7c2b16c4729d 100644 --- a/Documentation/scheduler/sched-stats.rst +++ b/Documentation/scheduler/sched-stats.rst @@ -2,6 +2,11 @@ Scheduler Statistics ==================== +Version 16 of schedstats changed the order of definitions within +'enum cpu_idle_type', which changed the order of [CPU_MAX_IDLE_TYPES] +columns in show_schedstat(). In particular the position of CPU_IDLE +and __CPU_NOT_IDLE changed places. The size of the array is unchanged. + Version 15 of schedstats dropped counters for some sched_yield: yld_exp_empty, yld_act_empty and yld_both_empty. Otherwise, it is identical to version 14. @@ -72,53 +77,53 @@ domain<N> <cpumask> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 The first field is a bit mask indicating what cpus this domain operates over. -The next 24 are a variety of load_balance() statistics in grouped into types +The next 24 are a variety of sched_balance_rq() statistics in grouped into types of idleness (idle, busy, and newly idle): - 1) # of times in this domain load_balance() was called when the + 1) # of times in this domain sched_balance_rq() was called when the cpu was idle - 2) # of times in this domain load_balance() checked but found + 2) # of times in this domain sched_balance_rq() checked but found the load did not require balancing when the cpu was idle - 3) # of times in this domain load_balance() tried to move one or + 3) # of times in this domain sched_balance_rq() tried to move one or more tasks and failed, when the cpu was idle 4) sum of imbalances discovered (if any) with each call to - load_balance() in this domain when the cpu was idle + sched_balance_rq() in this domain when the cpu was idle 5) # of times in this domain pull_task() was called when the cpu was idle 6) # of times in this domain pull_task() was called even though the target task was cache-hot when idle - 7) # of times in this domain load_balance() was called but did + 7) # of times in this domain sched_balance_rq() was called but did not find a busier queue while the cpu was idle 8) # of times in this domain a busier queue was found while the cpu was idle but no busier group was found - 9) # of times in this domain load_balance() was called when the + 9) # of times in this domain sched_balance_rq() was called when the cpu was busy - 10) # of times in this domain load_balance() checked but found the + 10) # of times in this domain sched_balance_rq() checked but found the load did not require balancing when busy - 11) # of times in this domain load_balance() tried to move one or + 11) # of times in this domain sched_balance_rq() tried to move one or more tasks and failed, when the cpu was busy 12) sum of imbalances discovered (if any) with each call to - load_balance() in this domain when the cpu was busy + sched_balance_rq() in this domain when the cpu was busy 13) # of times in this domain pull_task() was called when busy 14) # of times in this domain pull_task() was called even though the target task was cache-hot when busy - 15) # of times in this domain load_balance() was called but did not + 15) # of times in this domain sched_balance_rq() was called but did not find a busier queue while the cpu was busy 16) # of times in this domain a busier queue was found while the cpu was busy but no busier group was found - 17) # of times in this domain load_balance() was called when the + 17) # of times in this domain sched_balance_rq() was called when the cpu was just becoming idle - 18) # of times in this domain load_balance() checked but found the + 18) # of times in this domain sched_balance_rq() checked but found the load did not require balancing when the cpu was just becoming idle - 19) # of times in this domain load_balance() tried to move one or more + 19) # of times in this domain sched_balance_rq() tried to move one or more tasks and failed, when the cpu was just becoming idle 20) sum of imbalances discovered (if any) with each call to - load_balance() in this domain when the cpu was just becoming idle + sched_balance_rq() in this domain when the cpu was just becoming idle 21) # of times in this domain pull_task() was called when newly idle 22) # of times in this domain pull_task() was called even though the target task was cache-hot when just becoming idle - 23) # of times in this domain load_balance() was called but did not + 23) # of times in this domain sched_balance_rq() was called but did not find a busier queue while the cpu was just becoming idle 24) # of times in this domain a busier queue was found while the cpu was just becoming idle but no busier group was found diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst index 022198c51350..2df29b92e196 100644 --- a/Documentation/scsi/scsi_mid_low_api.rst +++ b/Documentation/scsi/scsi_mid_low_api.rst @@ -42,18 +42,18 @@ This version of the document roughly matches linux kernel version 2.6.8 . Documentation ============= There is a SCSI documentation directory within the kernel source tree, -typically Documentation/scsi . Most documents are in plain -(i.e. ASCII) text. This file is named scsi_mid_low_api.txt and can be +typically Documentation/scsi . Most documents are in reStructuredText +format. This file is named scsi_mid_low_api.rst and can be found in that directory. A more recent copy of this document may be found -at http://web.archive.org/web/20070107183357rn_1/sg.torque.net/scsi/. -Many LLDs are documented there (e.g. aic7xxx.txt). The SCSI mid-level is -briefly described in scsi.txt which contains a url to a document -describing the SCSI subsystem in the lk 2.4 series. Two upper level -drivers have documents in that directory: st.txt (SCSI tape driver) and -scsi-generic.txt (for the sg driver). - -Some documentation (or urls) for LLDs may be found in the C source code -or in the same directory as the C source code. For example to find a url +at https://docs.kernel.org/scsi/scsi_mid_low_api.html. Many LLDs are +documented in Documentation/scsi (e.g. aic7xxx.rst). The SCSI mid-level is +briefly described in scsi.rst which contains a URL to a document describing +the SCSI subsystem in the Linux Kernel 2.4 series. Two upper level +drivers have documents in that directory: st.rst (SCSI tape driver) and +scsi-generic.rst (for the sg driver). + +Some documentation (or URLs) for LLDs may be found in the C source code +or in the same directory as the C source code. For example to find a URL about the USB mass storage driver see the /usr/src/linux/drivers/usb/storage directory. diff --git a/Documentation/security/SCTP.rst b/Documentation/security/SCTP.rst index b73eb764a001..6d80d464ab6e 100644 --- a/Documentation/security/SCTP.rst +++ b/Documentation/security/SCTP.rst @@ -81,7 +81,7 @@ A summary of the ``@optname`` entries is as follows:: destination addresses. SCTP_SENDMSG_CONNECT - Initiate a connection that is generated by a - sendmsg(2) or sctp_sendmsg(3) on a new asociation. + sendmsg(2) or sctp_sendmsg(3) on a new association. SCTP_PRIMARY_ADDR - Set local primary address. diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst index e989b9802f92..f4d7e162d5e4 100644 --- a/Documentation/security/keys/trusted-encrypted.rst +++ b/Documentation/security/keys/trusted-encrypted.rst @@ -42,6 +42,14 @@ safe. randomly generated and fused into each SoC at manufacturing time. Otherwise, a common fixed test key is used instead. + (4) DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) + + Rooted to a one-time programmable key (OTP) that is generally burnt + in the on-chip fuses and is accessible to the DCP encryption engine only. + DCP provides two keys that can be used as root of trust: the OTP key + and the UNIQUE key. Default is to use the UNIQUE key, but selecting + the OTP key can be done via a module parameter (dcp_use_otp_key). + * Execution isolation (1) TPM @@ -57,6 +65,12 @@ safe. Fixed set of operations running in isolated execution environment. + (4) DCP + + Fixed set of cryptographic operations running in isolated execution + environment. Only basic blob key encryption is executed there. + The actual key sealing/unsealing is done on main processor/kernel space. + * Optional binding to platform integrity state (1) TPM @@ -79,6 +93,11 @@ safe. Relies on the High Assurance Boot (HAB) mechanism of NXP SoCs for platform integrity. + (4) DCP + + Relies on Secure/Trusted boot process (called HAB by vendor) for + platform integrity. + * Interfaces and APIs (1) TPM @@ -94,6 +113,11 @@ safe. Interface is specific to silicon vendor. + (4) DCP + + Vendor-specific API that is implemented as part of the DCP crypto driver in + ``drivers/crypto/mxs-dcp.c``. + * Threat model The strength and appropriateness of a particular trust source for a given @@ -129,6 +153,13 @@ selected trust source: CAAM HWRNG, enable CRYPTO_DEV_FSL_CAAM_RNG_API and ensure the device is probed. + * DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) + + The DCP hardware device itself does not provide a dedicated RNG interface, + so the kernel default RNG is used. SoCs with DCP like the i.MX6ULL do have + a dedicated hardware RNG that is independent from DCP which can be enabled + to back the kernel RNG. + Users may override this by specifying ``trusted.rng=kernel`` on the kernel command-line to override the used RNG with the kernel's random number pool. @@ -231,6 +262,19 @@ Usage:: CAAM-specific format. The key length for new keys is always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). +Trusted Keys usage: DCP +----------------------- + +Usage:: + + keyctl add trusted name "new keylen" ring + keyctl add trusted name "load hex_blob" ring + keyctl print keyid + +"keyctl print" returns an ASCII hex copy of the sealed key, which is in format +specific to this DCP key-blob implementation. The key length for new keys is +always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). + Encrypted Keys usage -------------------- @@ -426,3 +470,12 @@ string length. privkey is the binary representation of TPM2B_PUBLIC excluding the initial TPM2B header which can be reconstructed from the ASN.1 octed string length. + +DCP Blob Format +--------------- + +.. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c + :doc: dcp blob format + +.. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c + :identifiers: struct dcp_blob_fmt diff --git a/Documentation/security/snp-tdx-threat-model.rst b/Documentation/security/snp-tdx-threat-model.rst index ec66f2ed80c9..3a2d41d2e645 100644 --- a/Documentation/security/snp-tdx-threat-model.rst +++ b/Documentation/security/snp-tdx-threat-model.rst @@ -4,7 +4,7 @@ Confidential Computing in Linux for x86 virtualization .. contents:: :local: -By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao@amd.com> +By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao.osdev@gmail.com> Motivation ========== diff --git a/Documentation/security/tpm/index.rst b/Documentation/security/tpm/index.rst index fc40e9f23c85..fa593d960040 100644 --- a/Documentation/security/tpm/index.rst +++ b/Documentation/security/tpm/index.rst @@ -5,6 +5,8 @@ Trusted Platform Module documentation .. toctree:: tpm_event_log + tpm-security + tpm_tis tpm_vtpm_proxy xen-tpmfront tpm_ftpm_tee diff --git a/Documentation/security/tpm/tpm-security.rst b/Documentation/security/tpm/tpm-security.rst new file mode 100644 index 000000000000..4f633f251033 --- /dev/null +++ b/Documentation/security/tpm/tpm-security.rst @@ -0,0 +1,216 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +TPM Security +============ + +The object of this document is to describe how we make the kernel's +use of the TPM reasonably robust in the face of external snooping and +packet alteration attacks (called passive and active interposer attack +in the literature). The current security document is for TPM 2.0. + +Introduction +------------ + +The TPM is usually a discrete chip attached to a PC via some type of +low bandwidth bus. There are exceptions to this such as the Intel +PTT, which is a software TPM running inside a software environment +close to the CPU, which are subject to different attacks, but right at +the moment, most hardened security environments require a discrete +hardware TPM, which is the use case discussed here. + +Snooping and Alteration Attacks against the bus +----------------------------------------------- + +The current state of the art for snooping the `TPM Genie`_ hardware +interposer which is a simple external device that can be installed in +a couple of seconds on any system or laptop. Recently attacks were +successfully demonstrated against the `Windows Bitlocker TPM`_ system. +Most recently the same `attack against TPM based Linux disk +encryption`_ schemes. The next phase of research seems to be hacking +existing devices on the bus to act as interposers, so the fact that +the attacker requires physical access for a few seconds might +evaporate. However, the goal of this document is to protect TPM +secrets and integrity as far as we are able in this environment and to +try to insure that if we can't prevent the attack then at least we can +detect it. + +Unfortunately, most of the TPM functionality, including the hardware +reset capability can be controlled by an attacker who has access to +the bus, so we'll discuss some of the disruption possibilities below. + +Measurement (PCR) Integrity +--------------------------- + +Since the attacker can send their own commands to the TPM, they can +send arbitrary PCR extends and thus disrupt the measurement system, +which would be an annoying denial of service attack. However, there +are two, more serious, classes of attack aimed at entities sealed to +trust measurements. + +1. The attacker could intercept all PCR extends coming from the system + and completely substitute their own values, producing a replay of + an untampered state that would cause PCR measurements to attest to + a trusted state and release secrets + +2. At some point in time the attacker could reset the TPM, clearing + the PCRs and then send down their own measurements which would + effectively overwrite the boot time measurements the TPM has + already done. + +The first can be thwarted by always doing HMAC protection of the PCR +extend and read command meaning measurement values cannot be +substituted without producing a detectable HMAC failure in the +response. However, the second can only really be detected by relying +on some sort of mechanism for protection which would change over TPM +reset. + +Secrets Guarding +---------------- + +Certain information passing in and out of the TPM, such as key sealing +and private key import and random number generation, is vulnerable to +interception which HMAC protection alone cannot protect against, so +for these types of command we must also employ request and response +encryption to prevent the loss of secret information. + +Establishing Initial Trust with the TPM +--------------------------------------- + +In order to provide security from the beginning, an initial shared or +asymmetric secret must be established which must also be unknown to +the attacker. The most obvious avenues for this are the endorsement +and storage seeds, which can be used to derive asymmetric keys. +However, using these keys is difficult because the only way to pass +them into the kernel would be on the command line, which requires +extensive support in the boot system, and there's no guarantee that +either hierarchy would not have some type of authorization. + +The mechanism chosen for the Linux Kernel is to derive the primary +elliptic curve key from the null seed using the standard storage seed +parameters. The null seed has two advantages: firstly the hierarchy +physically cannot have an authorization, so we are always able to use +it and secondly, the null seed changes across TPM resets, meaning if +we establish trust on the null seed at start of day, all sessions +salted with the derived key will fail if the TPM is reset and the seed +changes. + +Obviously using the null seed without any other prior shared secrets, +we have to create and read the initial public key which could, of +course, be intercepted and substituted by the bus interposer. +However, the TPM has a key certification mechanism (using the EK +endorsement certificate, creating an attestation identity key and +certifying the null seed primary with that key) which is too complex +to run within the kernel, so we keep a copy of the null primary key +name, which is what is exported via sysfs so user-space can run the +full certification when it boots. The definitive guarantee here is +that if the null primary key certifies correctly, you know all your +TPM transactions since start of day were secure and if it doesn't, you +know there's an interposer on your system (and that any secret used +during boot may have been leaked). + +Stacking Trust +-------------- + +In the current null primary scenario, the TPM must be completely +cleared before handing it on to the next consumer. However the kernel +hands to user-space the name of the derived null seed key which can +then be verified by certification in user-space. Therefore, this chain +of name handoff can be used between the various boot components as +well (via an unspecified mechanism). For instance, grub could use the +null seed scheme for security and hand the name off to the kernel in +the boot area. The kernel could make its own derivation of the key +and the name and know definitively that if they differ from the handed +off version that tampering has occurred. Thus it becomes possible to +chain arbitrary boot components together (UEFI to grub to kernel) via +the name handoff provided each successive component knows how to +collect the name and verifies it against its derived key. + +Session Properties +------------------ + +All TPM commands the kernel uses allow sessions. HMAC sessions may be +used to check the integrity of requests and responses and decrypt and +encrypt flags may be used to shield parameters and responses. The +HMAC and encryption keys are usually derived from the shared +authorization secret, but for a lot of kernel operations that is well +known (and usually empty). Thus, every HMAC session used by the +kernel must be created using the null primary key as the salt key +which thus provides a cryptographic input into the session key +derivation. Thus, the kernel creates the null primary key once (as a +volatile TPM handle) and keeps it around in a saved context stored in +tpm_chip for every in-kernel use of the TPM. Currently, because of a +lack of de-gapping in the in-kernel resource manager, the session must +be created and destroyed for each operation, but, in future, a single +session may also be reused for the in-kernel HMAC, encryption and +decryption sessions. + +Protection Types +---------------- + +For every in-kernel operation we use null primary salted HMAC to +protect the integrity. Additionally, we use parameter encryption to +protect key sealing and parameter decryption to protect key unsealing +and random number generation. + +Null Primary Key Certification in Userspace +=========================================== + +Every TPM comes shipped with a couple of X.509 certificates for the +primary endorsement key. This document assumes that the Elliptic +Curve version of the certificate exists at 01C00002, but will work +equally well with the RSA certificate (at 01C00001). + +The first step in the certification is primary creation using the +template from the `TCG EK Credential Profile`_ which allows comparison +of the generated primary key against the one in the certificate (the +public key must match). Note that generation of the EK primary +requires the EK hierarchy password, but a pre-generated version of the +EC primary should exist at 81010002 and a TPM2_ReadPublic() may be +performed on this without needing the key authority. Next, the +certificate itself must be verified to chain back to the manufacturer +root (which should be published on the manufacturer website). Once +this is done, an attestation key (AK) is generated within the TPM and +it's name and the EK public key can be used to encrypt a secret using +TPM2_MakeCredential. The TPM then runs TPM2_ActivateCredential which +will only recover the secret if the binding between the TPM, the EK +and the AK is true. the generated AK may now be used to run a +certification of the null primary key whose name the kernel has +exported. Since TPM2_MakeCredential/ActivateCredential are somewhat +complicated, a more simplified process involving an externally +generated private key is described below. + +This process is a simplified abbreviation of the usual privacy CA +based attestation process. The assumption here is that the +attestation is done by the TPM owner who thus has access to only the +owner hierarchy. The owner creates an external public/private key +pair (assume elliptic curve in this case) and wraps the private key +for import using an inner wrapping process and parented to the EC +derived storage primary. The TPM2_Import() is done using a parameter +decryption HMAC session salted to the EK primary (which also does not +require the EK key authority) meaning that the inner wrapping key is +the encrypted parameter and thus the TPM will not be able to perform +the import unless is possesses the certified EK so if the command +succeeds and the HMAC verifies on return we know we have a loadable +copy of the private key only for the certified TPM. This key is now +loaded into the TPM and the Storage primary flushed (to free up space +for the null key generation). + +The null EC primary is now generated using the Storage profile +outlined in the `TCG TPM v2.0 Provisioning Guidance`_; the name of +this key (the hash of the public area) is computed and compared to the +null seed name presented by the kernel in +/sys/class/tpm/tpm0/null_name. If the names do not match, the TPM is +compromised. If the names match, the user performs a TPM2_Certify() +using the null primary as the object handle and the loaded private key +as the sign handle and providing randomized qualifying data. The +signature of the returned certifyInfo is verified against the public +part of the loaded private key and the qualifying data checked to +prevent replay. If all of these tests pass, the user is now assured +that TPM integrity and privacy was preserved across the entire boot +sequence of this kernel. + +.. _TPM Genie: https://www.nccgroup.trust/globalassets/about-us/us/documents/tpm-genie.pdf +.. _Windows Bitlocker TPM: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network +.. _attack against TPM based Linux disk encryption: https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets +.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/ +.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/ diff --git a/Documentation/security/tpm/tpm_tis.rst b/Documentation/security/tpm/tpm_tis.rst new file mode 100644 index 000000000000..b9637f295638 --- /dev/null +++ b/Documentation/security/tpm/tpm_tis.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +TPM FIFO interface driver +========================= + +TCG PTP Specification defines two interface types: FIFO and CRB. The former is +based on sequenced read and write operations, and the latter is based on a +buffer containing the full command or response. + +FIFO (First-In-First-Out) interface is used by the tpm_tis_core dependent +drivers. Originally Linux had only a driver called tpm_tis, which covered +memory mapped (aka MMIO) interface but it was later on extended to cover other +physical interfaces supported by the TCG standard. + +For historical reasons above the original MMIO driver is called tpm_tis and the +framework for FIFO drivers is named as tpm_tis_core. The postfix "tis" in +tpm_tis comes from the TPM Interface Specification, which is the hardware +interface specification for TPM 1.x chips. + +Communication is based on a 20 KiB buffer shared by the TPM chip through a +hardware bus or memory map, depending on the physical wiring. The buffer is +further split into five equal-size 4 KiB buffers, which provide equivalent +sets of registers for communication between the CPU and TPM. These +communication endpoints are called localities in the TCG terminology. + +When the kernel wants to send commands to the TPM chip, it first reserves +locality 0 by setting the requestUse bit in the TPM_ACCESS register. The bit is +cleared by the chip when the access is granted. Once it completes its +communication, the kernel writes the TPM_ACCESS.activeLocality bit. This +informs the chip that the locality has been relinquished. + +Pending localities are served in order by the chip in descending order, one at +a time: + +- Locality 0 has the lowest priority. +- Locality 5 has the highest priority. + +Further information on the purpose and meaning of the localities can be found +in section 3.2 of the TCG PC Client Platform TPM Profile Specification. + +References +========== + +TCG PC Client Platform TPM Profile (PTP) Specification +https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/ diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 2d2998faff62..801b0bb57e97 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -3976,7 +3976,7 @@ Driver with A Single Source File Suppose you have a file xyz.c. Add the following two lines:: - snd-xyz-objs := xyz.o + snd-xyz-y := xyz.o obj-$(CONFIG_SND_XYZ) += snd-xyz.o 2. Create the Kconfig entry @@ -4019,7 +4019,7 @@ located in the new subdirectory, sound/pci/xyz. 2. Under the directory ``sound/pci/xyz``, create a Makefile:: - snd-xyz-objs := xyz.o abc.o def.o + snd-xyz-y := xyz.o abc.o def.o obj-$(CONFIG_SND_XYZ) += snd-xyz.o 3. Create the Kconfig entry diff --git a/Documentation/sound/soc/dapm-graph.svg b/Documentation/sound/soc/dapm-graph.svg new file mode 100644 index 000000000000..d783672db815 --- /dev/null +++ b/Documentation/sound/soc/dapm-graph.svg @@ -0,0 +1,375 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" + "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> +<!-- Generated by graphviz version 2.43.0 (0) + --> +<!-- Title: G Pages: 1 --> +<svg width="900pt" height="630pt" + viewBox="0.00 0.00 900.00 630.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> +<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 626)"> +<title>G</title> +<polygon fill="white" stroke="transparent" points="-4,4 -4,-626 896,-626 896,4 -4,4"/> +<g id="clust1" class="cluster"> +<title>ROOT</title> +<polygon fill="none" stroke="dodgerblue" points="8,-537 8,-614 102,-614 102,-537 8,-537"/> +<text text-anchor="middle" x="55" y="-598.8" font-family="sans-serif" font-size="14.00">ROOT</text> +</g> +<g id="clust2" class="cluster"> +<title>4000b000.audio-controller</title> +<polygon fill="none" stroke="dodgerblue" points="120,-378 120,-455 312,-455 312,-378 120,-378"/> +<text text-anchor="middle" x="216" y="-439.8" font-family="sans-serif" font-size="14.00">4000b000.audio-controller</text> +</g> +<g id="clust5" class="cluster"> +<title>cs42l51.0-004a</title> +<polygon fill="none" stroke="dodgerblue" points="330,-8 330,-614 884,-614 884,-8 330,-8"/> +<text text-anchor="middle" x="607" y="-598.8" font-family="sans-serif" font-size="14.00">cs42l51.0-004a</text> +</g> +<g id="clust9" class="cluster"> +<title>hdmi-audio-codec.1.auto</title> +<polygon fill="none" stroke="dodgerblue" points="110,-463 110,-614 314,-614 314,-463 110,-463"/> +<text text-anchor="middle" x="212" y="-598.8" font-family="sans-serif" font-size="14.00">hdmi-audio-codec.1.auto</text> +</g> +<!-- ROOT_Amplifier --> +<g id="node1" class="node"> +<title>ROOT_Amplifier</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="93.5,-583 16.5,-583 16.5,-545 93.5,-545 93.5,-583"/> +<text text-anchor="middle" x="55" y="-567.8" font-family="sans-serif" font-size="14.00">Amplifier</text> +<text text-anchor="middle" x="55" y="-552.8" font-family="sans-serif" font-size="14.00">[out_drv]</text> +</g> +<!-- 4000b000.audio-controller_capture --> +<g id="node2" class="node"> +<title>4000b000.audio-controller_capture</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="202,-424 128,-424 128,-386 202,-386 202,-424"/> +<text text-anchor="middle" x="165" y="-408.8" font-family="sans-serif" font-size="14.00">capture</text> +<text text-anchor="middle" x="165" y="-393.8" font-family="sans-serif" font-size="14.00">[dai_out]</text> +</g> +<!-- 4000b000.audio-controller_playback --> +<g id="node3" class="node"> +<title>4000b000.audio-controller_playback</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="304,-424 230,-424 230,-386 304,-386 304,-424"/> +<text text-anchor="middle" x="267" y="-408.8" font-family="sans-serif" font-size="14.00">playback</text> +<text text-anchor="middle" x="267" y="-393.8" font-family="sans-serif" font-size="14.00">[dai_in]</text> +</g> +<!-- hdmi-audio-codec.1.auto_I2S Playback --> +<g id="node28" class="node"> +<title>hdmi-audio-codec.1.auto_I2S Playback</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="306,-583 208,-583 208,-545 306,-545 306,-583"/> +<text text-anchor="middle" x="257" y="-567.8" font-family="sans-serif" font-size="14.00">I2S Playback</text> +<text text-anchor="middle" x="257" y="-552.8" font-family="sans-serif" font-size="14.00">[dai_in]</text> +</g> +<!-- 4000b000.audio-controller_playback->hdmi-audio-codec.1.auto_I2S Playback --> +<g id="edge21" class="edge"> +<title>4000b000.audio-controller_playback->hdmi-audio-codec.1.auto_I2S Playback</title> +<path fill="none" stroke="black" d="M276.84,-424.14C282.19,-435.06 288.26,-449.42 291,-463 295.05,-483.04 296.67,-489.36 291,-509 288.25,-518.54 283.26,-528.01 277.93,-536.3"/> +<polygon fill="black" stroke="black" points="274.89,-534.55 272.11,-544.78 280.66,-538.51 274.89,-534.55"/> +</g> +<!-- hdmi-audio-codec.1.auto_Capture --> +<g id="node4" class="node"> +<title>hdmi-audio-codec.1.auto_Capture</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="192,-509 118,-509 118,-471 192,-471 192,-509"/> +<text text-anchor="middle" x="155" y="-493.8" font-family="sans-serif" font-size="14.00">Capture</text> +<text text-anchor="middle" x="155" y="-478.8" font-family="sans-serif" font-size="14.00">[dai_out]</text> +</g> +<!-- hdmi-audio-codec.1.auto_Capture->4000b000.audio-controller_capture --> +<g id="edge1" class="edge"> +<title>hdmi-audio-codec.1.auto_Capture->4000b000.audio-controller_capture</title> +<path fill="none" stroke="black" d="M157.17,-470.99C158.46,-460.3 160.12,-446.5 161.58,-434.37"/> +<polygon fill="black" stroke="black" points="165.08,-434.61 162.8,-424.26 158.13,-433.77 165.08,-434.61"/> +</g> +<!-- cs42l51.0-004a_AIN1L --> +<g id="node5" class="node"> +<title>cs42l51.0-004a_AIN1L</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="836.5,-583 775.5,-583 775.5,-545 836.5,-545 836.5,-583"/> +<text text-anchor="middle" x="806" y="-567.8" font-family="sans-serif" font-size="14.00">AIN1L</text> +<text text-anchor="middle" x="806" y="-552.8" font-family="sans-serif" font-size="14.00">[input]</text> +</g> +<!-- cs42l51.0-004a_PGA-ADC Mux Left --> +<g id="node22" class="node"> +<title>cs42l51.0-004a_PGA-ADC Mux Left</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="876,-509 736,-509 736,-471 876,-471 876,-509"/> +<text text-anchor="middle" x="806" y="-493.8" font-family="sans-serif" font-size="14.00">PGA-ADC Mux Left</text> +<text text-anchor="middle" x="806" y="-478.8" font-family="sans-serif" font-size="14.00">[mux]</text> +</g> +<!-- cs42l51.0-004a_AIN1L->cs42l51.0-004a_PGA-ADC Mux Left --> +<g id="edge14" class="edge"> +<title>cs42l51.0-004a_AIN1L->cs42l51.0-004a_PGA-ADC Mux Left</title> +<path fill="none" stroke="black" d="M806,-544.83C806,-537.13 806,-527.97 806,-519.42"/> +<polygon fill="black" stroke="black" points="809.5,-519.41 806,-509.41 802.5,-519.41 809.5,-519.41"/> +</g> +<!-- cs42l51.0-004a_AIN1R --> +<g id="node6" class="node"> +<title>cs42l51.0-004a_AIN1R</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="738.5,-583 677.5,-583 677.5,-545 738.5,-545 738.5,-583"/> +<text text-anchor="middle" x="708" y="-567.8" font-family="sans-serif" font-size="14.00">AIN1R</text> +<text text-anchor="middle" x="708" y="-552.8" font-family="sans-serif" font-size="14.00">[input]</text> +</g> +<!-- cs42l51.0-004a_PGA-ADC Mux Right --> +<g id="node23" class="node"> +<title>cs42l51.0-004a_PGA-ADC Mux Right</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="717.5,-509 568.5,-509 568.5,-471 717.5,-471 717.5,-509"/> +<text text-anchor="middle" x="643" y="-493.8" font-family="sans-serif" font-size="14.00">PGA-ADC Mux Right</text> +<text text-anchor="middle" x="643" y="-478.8" font-family="sans-serif" font-size="14.00">[mux]</text> +</g> +<!-- cs42l51.0-004a_AIN1R->cs42l51.0-004a_PGA-ADC Mux Right --> +<g id="edge15" class="edge"> +<title>cs42l51.0-004a_AIN1R->cs42l51.0-004a_PGA-ADC Mux Right</title> +<path fill="none" stroke="black" d="M691.6,-544.83C683.96,-536.37 674.73,-526.15 666.38,-516.9"/> +<polygon fill="black" stroke="black" points="668.92,-514.49 659.62,-509.41 663.73,-519.18 668.92,-514.49"/> +</g> +<!-- cs42l51.0-004a_AIN2L --> +<g id="node7" class="node"> +<title>cs42l51.0-004a_AIN2L</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="659.5,-583 598.5,-583 598.5,-545 659.5,-545 659.5,-583"/> +<text text-anchor="middle" x="629" y="-567.8" font-family="sans-serif" font-size="14.00">AIN2L</text> +<text text-anchor="middle" x="629" y="-552.8" font-family="sans-serif" font-size="14.00">[input]</text> +</g> +<!-- cs42l51.0-004a_AIN2R --> +<g id="node8" class="node"> +<title>cs42l51.0-004a_AIN2R</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="580.5,-583 519.5,-583 519.5,-545 580.5,-545 580.5,-583"/> +<text text-anchor="middle" x="550" y="-567.8" font-family="sans-serif" font-size="14.00">AIN2R</text> +<text text-anchor="middle" x="550" y="-552.8" font-family="sans-serif" font-size="14.00">[input]</text> +</g> +<!-- cs42l51.0-004a_Capture --> +<g id="node9" class="node"> +<title>cs42l51.0-004a_Capture</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="692,-276 618,-276 618,-238 692,-238 692,-276"/> +<text text-anchor="middle" x="655" y="-260.8" font-family="sans-serif" font-size="14.00">Capture</text> +<text text-anchor="middle" x="655" y="-245.8" font-family="sans-serif" font-size="14.00">[dai_out]</text> +</g> +<!-- cs42l51.0-004a_DAC Mux --> +<g id="node10" class="node"> +<title>cs42l51.0-004a_DAC Mux</title> +<polygon fill="none" stroke="#008b00" stroke-width="2" points="598.5,-202 521.5,-202 521.5,-164 598.5,-164 598.5,-202"/> +<text text-anchor="middle" x="560" y="-186.8" font-family="sans-serif" font-size="14.00">DAC Mux</text> +<text text-anchor="middle" x="560" y="-171.8" font-family="sans-serif" font-size="14.00">[mux]</text> +</g> +<!-- cs42l51.0-004a_Left DAC --> +<g id="node14" class="node"> +<title>cs42l51.0-004a_Left DAC</title> +<polygon fill="none" stroke="#008b00" stroke-width="2" points="548,-128 474,-128 474,-90 548,-90 548,-128"/> +<text text-anchor="middle" x="511" y="-112.8" font-family="sans-serif" font-size="14.00">Left DAC</text> +<text text-anchor="middle" x="511" y="-97.8" font-family="sans-serif" font-size="14.00">[dac]</text> +</g> +<!-- cs42l51.0-004a_DAC Mux->cs42l51.0-004a_Left DAC --> +<g id="edge9" class="edge"> +<title>cs42l51.0-004a_DAC Mux->cs42l51.0-004a_Left DAC</title> +<path fill="none" stroke="black" d="M547.64,-163.83C542.05,-155.62 535.34,-145.76 529.19,-136.73"/> +<polygon fill="black" stroke="black" points="532.05,-134.71 523.53,-128.41 526.26,-138.65 532.05,-134.71"/> +</g> +<!-- cs42l51.0-004a_Right DAC --> +<g id="node26" class="node"> +<title>cs42l51.0-004a_Right DAC</title> +<polygon fill="none" stroke="#008b00" stroke-width="2" points="649.5,-128 566.5,-128 566.5,-90 649.5,-90 649.5,-128"/> +<text text-anchor="middle" x="608" y="-112.8" font-family="sans-serif" font-size="14.00">Right DAC</text> +<text text-anchor="middle" x="608" y="-97.8" font-family="sans-serif" font-size="14.00">[dac]</text> +</g> +<!-- cs42l51.0-004a_DAC Mux->cs42l51.0-004a_Right DAC --> +<g id="edge18" class="edge"> +<title>cs42l51.0-004a_DAC Mux->cs42l51.0-004a_Right DAC</title> +<path fill="none" stroke="black" d="M572.11,-163.83C577.53,-155.71 584.02,-145.96 589.99,-137.01"/> +<polygon fill="black" stroke="black" points="593.09,-138.68 595.72,-128.41 587.27,-134.79 593.09,-138.68"/> +</g> +<!-- cs42l51.0-004a_HPL --> +<g id="node11" class="node"> +<title>cs42l51.0-004a_HPL</title> +<polygon fill="none" stroke="#008b00" stroke-width="2" points="546.5,-54 475.5,-54 475.5,-16 546.5,-16 546.5,-54"/> +<text text-anchor="middle" x="511" y="-38.8" font-family="sans-serif" font-size="14.00">HPL</text> +<text text-anchor="middle" x="511" y="-23.8" font-family="sans-serif" font-size="14.00">[output]</text> +</g> +<!-- cs42l51.0-004a_HPR --> +<g id="node12" class="node"> +<title>cs42l51.0-004a_HPR</title> +<polygon fill="none" stroke="#008b00" stroke-width="2" points="643.5,-54 572.5,-54 572.5,-16 643.5,-16 643.5,-54"/> +<text text-anchor="middle" x="608" y="-38.8" font-family="sans-serif" font-size="14.00">HPR</text> +<text text-anchor="middle" x="608" y="-23.8" font-family="sans-serif" font-size="14.00">[output]</text> +</g> +<!-- cs42l51.0-004a_Left ADC --> +<g id="node13" class="node"> +<title>cs42l51.0-004a_Left ADC</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="822,-350 748,-350 748,-312 822,-312 822,-350"/> +<text text-anchor="middle" x="785" y="-334.8" font-family="sans-serif" font-size="14.00">Left ADC</text> +<text text-anchor="middle" x="785" y="-319.8" font-family="sans-serif" font-size="14.00">[adc]</text> +</g> +<!-- cs42l51.0-004a_Left ADC->cs42l51.0-004a_Capture --> +<g id="edge4" class="edge"> +<title>cs42l51.0-004a_Left ADC->cs42l51.0-004a_Capture</title> +<path fill="none" stroke="black" d="M752.2,-311.83C735.41,-302.54 714.8,-291.12 696.88,-281.2"/> +<polygon fill="black" stroke="black" points="698.24,-277.95 687.79,-276.16 694.85,-284.07 698.24,-277.95"/> +</g> +<!-- cs42l51.0-004a_Left DAC->cs42l51.0-004a_HPL --> +<g id="edge6" class="edge"> +<title>cs42l51.0-004a_Left DAC->cs42l51.0-004a_HPL</title> +<path fill="none" stroke="black" d="M511,-89.83C511,-82.13 511,-72.97 511,-64.42"/> +<polygon fill="black" stroke="black" points="514.5,-64.41 511,-54.41 507.5,-64.41 514.5,-64.41"/> +</g> +<!-- cs42l51.0-004a_Left PGA --> +<g id="node15" class="node"> +<title>cs42l51.0-004a_Left PGA</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="838,-424 764,-424 764,-386 838,-386 838,-424"/> +<text text-anchor="middle" x="801" y="-408.8" font-family="sans-serif" font-size="14.00">Left PGA</text> +<text text-anchor="middle" x="801" y="-393.8" font-family="sans-serif" font-size="14.00">[pga]</text> +</g> +<!-- cs42l51.0-004a_Left PGA->cs42l51.0-004a_Left ADC --> +<g id="edge8" class="edge"> +<title>cs42l51.0-004a_Left PGA->cs42l51.0-004a_Left ADC</title> +<path fill="none" stroke="black" d="M796.96,-385.83C795.25,-378.13 793.22,-368.97 791.31,-360.42"/> +<polygon fill="black" stroke="black" points="794.68,-359.42 789.09,-350.41 787.84,-360.93 794.68,-359.42"/> +</g> +<!-- cs42l51.0-004a_MCLK --> +<g id="node16" class="node"> +<title>cs42l51.0-004a_MCLK</title> +<polygon fill="none" stroke="#008b00" stroke-width="2" points="594.5,-350 525.5,-350 525.5,-312 594.5,-312 594.5,-350"/> +<text text-anchor="middle" x="560" y="-334.8" font-family="sans-serif" font-size="14.00">MCLK</text> +<text text-anchor="middle" x="560" y="-319.8" font-family="sans-serif" font-size="14.00">[supply]</text> +</g> +<!-- cs42l51.0-004a_MCLK->cs42l51.0-004a_Capture --> +<g id="edge2" class="edge"> +<title>cs42l51.0-004a_MCLK->cs42l51.0-004a_Capture</title> +<path fill="none" stroke="black" d="M583.97,-311.83C595.79,-302.88 610.2,-291.96 622.94,-282.3"/> +<polygon fill="black" stroke="black" points="625.18,-284.99 631.04,-276.16 620.95,-279.41 625.18,-284.99"/> +</g> +<!-- cs42l51.0-004a_Playback --> +<g id="node24" class="node"> +<title>cs42l51.0-004a_Playback</title> +<polygon fill="none" stroke="#008b00" stroke-width="2" points="597,-276 523,-276 523,-238 597,-238 597,-276"/> +<text text-anchor="middle" x="560" y="-260.8" font-family="sans-serif" font-size="14.00">Playback</text> +<text text-anchor="middle" x="560" y="-245.8" font-family="sans-serif" font-size="14.00">[dai_in]</text> +</g> +<!-- cs42l51.0-004a_MCLK->cs42l51.0-004a_Playback --> +<g id="edge16" class="edge"> +<title>cs42l51.0-004a_MCLK->cs42l51.0-004a_Playback</title> +<path fill="none" stroke="black" d="M560,-311.83C560,-304.13 560,-294.97 560,-286.42"/> +<polygon fill="black" stroke="black" points="563.5,-286.41 560,-276.41 556.5,-286.41 563.5,-286.41"/> +</g> +<!-- cs42l51.0-004a_MICL --> +<g id="node17" class="node"> +<title>cs42l51.0-004a_MICL</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="399.5,-509 338.5,-509 338.5,-471 399.5,-471 399.5,-509"/> +<text text-anchor="middle" x="369" y="-493.8" font-family="sans-serif" font-size="14.00">MICL</text> +<text text-anchor="middle" x="369" y="-478.8" font-family="sans-serif" font-size="14.00">[input]</text> +</g> +<!-- cs42l51.0-004a_Mic Preamp Left --> +<g id="node20" class="node"> +<title>cs42l51.0-004a_Mic Preamp Left</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="461.5,-424 338.5,-424 338.5,-386 461.5,-386 461.5,-424"/> +<text text-anchor="middle" x="400" y="-408.8" font-family="sans-serif" font-size="14.00">Mic Preamp Left</text> +<text text-anchor="middle" x="400" y="-393.8" font-family="sans-serif" font-size="14.00">[mixer]</text> +</g> +<!-- cs42l51.0-004a_MICL->cs42l51.0-004a_Mic Preamp Left --> +<g id="edge12" class="edge"> +<title>cs42l51.0-004a_MICL->cs42l51.0-004a_Mic Preamp Left</title> +<path fill="none" stroke="black" d="M375.73,-470.99C379.8,-460.08 385.08,-445.94 389.68,-433.64"/> +<polygon fill="black" stroke="black" points="392.96,-434.85 393.18,-424.26 386.4,-432.4 392.96,-434.85"/> +</g> +<!-- cs42l51.0-004a_MICR --> +<g id="node18" class="node"> +<title>cs42l51.0-004a_MICR</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="501.5,-583 440.5,-583 440.5,-545 501.5,-545 501.5,-583"/> +<text text-anchor="middle" x="471" y="-567.8" font-family="sans-serif" font-size="14.00">MICR</text> +<text text-anchor="middle" x="471" y="-552.8" font-family="sans-serif" font-size="14.00">[input]</text> +</g> +<!-- cs42l51.0-004a_Mic Preamp Right --> +<g id="node21" class="node"> +<title>cs42l51.0-004a_Mic Preamp Right</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="550.5,-509 417.5,-509 417.5,-471 550.5,-471 550.5,-509"/> +<text text-anchor="middle" x="484" y="-493.8" font-family="sans-serif" font-size="14.00">Mic Preamp Right</text> +<text text-anchor="middle" x="484" y="-478.8" font-family="sans-serif" font-size="14.00">[mixer]</text> +</g> +<!-- cs42l51.0-004a_MICR->cs42l51.0-004a_Mic Preamp Right --> +<g id="edge13" class="edge"> +<title>cs42l51.0-004a_MICR->cs42l51.0-004a_Mic Preamp Right</title> +<path fill="none" stroke="black" d="M474.28,-544.83C475.67,-537.13 477.32,-527.97 478.87,-519.42"/> +<polygon fill="black" stroke="black" points="482.34,-519.88 480.68,-509.41 475.45,-518.63 482.34,-519.88"/> +</g> +<!-- cs42l51.0-004a_Mic Bias --> +<g id="node19" class="node"> +<title>cs42l51.0-004a_Mic Bias</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="409.5,-583 338.5,-583 338.5,-545 409.5,-545 409.5,-583"/> +<text text-anchor="middle" x="374" y="-567.8" font-family="sans-serif" font-size="14.00">Mic Bias</text> +<text text-anchor="middle" x="374" y="-552.8" font-family="sans-serif" font-size="14.00">[supply]</text> +</g> +<!-- cs42l51.0-004a_Mic Bias->cs42l51.0-004a_MICL --> +<g id="edge11" class="edge"> +<title>cs42l51.0-004a_Mic Bias->cs42l51.0-004a_MICL</title> +<path fill="none" stroke="black" d="M372.74,-544.83C372.2,-537.13 371.57,-527.97 370.97,-519.42"/> +<polygon fill="black" stroke="black" points="374.46,-519.15 370.28,-509.41 367.48,-519.63 374.46,-519.15"/> +</g> +<!-- cs42l51.0-004a_PGA-ADC Mux Left->cs42l51.0-004a_Left PGA --> +<g id="edge10" class="edge"> +<title>cs42l51.0-004a_PGA-ADC Mux Left->cs42l51.0-004a_Left PGA</title> +<path fill="none" stroke="black" d="M804.92,-470.99C804.27,-460.3 803.44,-446.5 802.71,-434.37"/> +<polygon fill="black" stroke="black" points="806.2,-434.03 802.1,-424.26 799.21,-434.45 806.2,-434.03"/> +</g> +<!-- cs42l51.0-004a_Right PGA --> +<g id="node27" class="node"> +<title>cs42l51.0-004a_Right PGA</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="688.5,-424 605.5,-424 605.5,-386 688.5,-386 688.5,-424"/> +<text text-anchor="middle" x="647" y="-408.8" font-family="sans-serif" font-size="14.00">Right PGA</text> +<text text-anchor="middle" x="647" y="-393.8" font-family="sans-serif" font-size="14.00">[pga]</text> +</g> +<!-- cs42l51.0-004a_PGA-ADC Mux Right->cs42l51.0-004a_Right PGA --> +<g id="edge19" class="edge"> +<title>cs42l51.0-004a_PGA-ADC Mux Right->cs42l51.0-004a_Right PGA</title> +<path fill="none" stroke="black" d="M643.87,-470.99C644.38,-460.3 645.05,-446.5 645.63,-434.37"/> +<polygon fill="black" stroke="black" points="649.13,-434.42 646.12,-424.26 642.14,-434.08 649.13,-434.42"/> +</g> +<!-- cs42l51.0-004a_Playback->cs42l51.0-004a_DAC Mux --> +<g id="edge5" class="edge"> +<title>cs42l51.0-004a_Playback->cs42l51.0-004a_DAC Mux</title> +<path fill="none" stroke="black" d="M560,-237.83C560,-230.13 560,-220.97 560,-212.42"/> +<polygon fill="black" stroke="black" points="563.5,-212.41 560,-202.41 556.5,-212.41 563.5,-212.41"/> +</g> +<!-- cs42l51.0-004a_Right ADC --> +<g id="node25" class="node"> +<title>cs42l51.0-004a_Right ADC</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="697,-350 613,-350 613,-312 697,-312 697,-350"/> +<text text-anchor="middle" x="655" y="-334.8" font-family="sans-serif" font-size="14.00">Right ADC</text> +<text text-anchor="middle" x="655" y="-319.8" font-family="sans-serif" font-size="14.00">[adc]</text> +</g> +<!-- cs42l51.0-004a_Right ADC->cs42l51.0-004a_Capture --> +<g id="edge3" class="edge"> +<title>cs42l51.0-004a_Right ADC->cs42l51.0-004a_Capture</title> +<path fill="none" stroke="black" d="M655,-311.83C655,-304.13 655,-294.97 655,-286.42"/> +<polygon fill="black" stroke="black" points="658.5,-286.41 655,-276.41 651.5,-286.41 658.5,-286.41"/> +</g> +<!-- cs42l51.0-004a_Right DAC->cs42l51.0-004a_HPR --> +<g id="edge7" class="edge"> +<title>cs42l51.0-004a_Right DAC->cs42l51.0-004a_HPR</title> +<path fill="none" stroke="black" d="M608,-89.83C608,-82.13 608,-72.97 608,-64.42"/> +<polygon fill="black" stroke="black" points="611.5,-64.41 608,-54.41 604.5,-64.41 611.5,-64.41"/> +</g> +<!-- cs42l51.0-004a_Right PGA->cs42l51.0-004a_Right ADC --> +<g id="edge17" class="edge"> +<title>cs42l51.0-004a_Right PGA->cs42l51.0-004a_Right ADC</title> +<path fill="none" stroke="black" d="M649.02,-385.83C649.87,-378.13 650.89,-368.97 651.84,-360.42"/> +<polygon fill="black" stroke="black" points="655.33,-360.74 652.95,-350.41 648.37,-359.97 655.33,-360.74"/> +</g> +<!-- hdmi-audio-codec.1.auto_TX --> +<g id="node30" class="node"> +<title>hdmi-audio-codec.1.auto_TX</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="281.5,-509 210.5,-509 210.5,-471 281.5,-471 281.5,-509"/> +<text text-anchor="middle" x="246" y="-493.8" font-family="sans-serif" font-size="14.00">TX</text> +<text text-anchor="middle" x="246" y="-478.8" font-family="sans-serif" font-size="14.00">[output]</text> +</g> +<!-- hdmi-audio-codec.1.auto_I2S Playback->hdmi-audio-codec.1.auto_TX --> +<g id="edge22" class="edge"> +<title>hdmi-audio-codec.1.auto_I2S Playback->hdmi-audio-codec.1.auto_TX</title> +<path fill="none" stroke="black" d="M254.22,-544.83C253.05,-537.13 251.65,-527.97 250.34,-519.42"/> +<polygon fill="black" stroke="black" points="253.78,-518.77 248.81,-509.41 246.86,-519.83 253.78,-518.77"/> +</g> +<!-- hdmi-audio-codec.1.auto_RX --> +<g id="node29" class="node"> +<title>hdmi-audio-codec.1.auto_RX</title> +<polygon fill="#f2f2f2" stroke="#4d4d4d" points="189.5,-583 118.5,-583 118.5,-545 189.5,-545 189.5,-583"/> +<text text-anchor="middle" x="154" y="-567.8" font-family="sans-serif" font-size="14.00">RX</text> +<text text-anchor="middle" x="154" y="-552.8" font-family="sans-serif" font-size="14.00">[output]</text> +</g> +<!-- hdmi-audio-codec.1.auto_RX->hdmi-audio-codec.1.auto_Capture --> +<g id="edge20" class="edge"> +<title>hdmi-audio-codec.1.auto_RX->hdmi-audio-codec.1.auto_Capture</title> +<path fill="none" stroke="black" d="M154.25,-544.83C154.36,-537.13 154.49,-527.97 154.61,-519.42"/> +<polygon fill="black" stroke="black" points="158.1,-519.46 154.74,-509.41 151.11,-519.36 158.1,-519.46"/> +</g> +</g> +</svg> diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index c3154ce6e1b2..14c4dc026e6b 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -7,8 +7,8 @@ Description Dynamic Audio Power Management (DAPM) is designed to allow portable Linux devices to use the minimum amount of power within the audio -subsystem at all times. It is independent of other kernel PM and as -such, can easily co-exist with the other PM systems. +subsystem at all times. It is independent of other kernel power +management frameworks and, as such, can easily co-exist with them. DAPM is also completely transparent to all user space applications as all power switching is done within the ASoC core. No code changes or @@ -16,11 +16,29 @@ recompiling are required for user space applications. DAPM makes power switching decisions based upon any audio stream (capture/playback) activity and audio mixer settings within the device. -DAPM spans the whole machine. It covers power control within the entire -audio subsystem, this includes internal codec power blocks and machine -level power systems. +DAPM is based on two basic elements, called widgets and routes: -There are 4 power domains within DAPM + * a **widget** is every part of the audio hardware that can be enabled by + software when in use and disabled to save power when not in use + * a **route** is an interconnection between widgets that exists when sound + can flow from one widget to the other + +All DAPM power switching decisions are made automatically by consulting an +audio routing graph. This graph is specific to each sound card and spans +the whole sound card, so some DAPM routes connect two widgets belonging to +different components (e.g. the LINE OUT pin of a CODEC and the input pin of +an amplifier). + +The graph for the STM32MP1-DK1 sound card is shown in picture: + +.. kernel-figure:: dapm-graph.svg + :alt: Example DAPM graph + :align: center + +DAPM power domains +================== + +There are 4 power domains within DAPM: Codec bias domain VREF, VMID (core codec and audio power) @@ -47,17 +65,11 @@ Stream domain Enabled and disabled when stream playback/capture is started and stopped respectively. e.g. aplay, arecord. -All DAPM power switching decisions are made automatically by consulting an audio -routing map of the whole machine. This map is specific to each machine and -consists of the interconnections between every audio component (including -internal codec components). All audio components that effect power are called -widgets hereafter. - DAPM Widgets ============ -Audio DAPM widgets fall into a number of types:- +Audio DAPM widgets fall into a number of types: Mixer Mixes several analog signals into a single analog signal. @@ -141,14 +153,14 @@ Stream Widgets relate to the stream power domain and only consist of ADCs (analog to digital converters), DACs (digital to analog converters), AIF IN and AIF OUT. -Stream widgets have the following format:- +Stream widgets have the following format: :: SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert), SND_SOC_DAPM_AIF_IN(name, stream, slot, reg, shift, invert) NOTE: the stream name must match the corresponding stream name in your codec -snd_soc_codec_dai. +snd_soc_dai_driver. e.g. stream widgets for HiFi playback and capture :: @@ -167,7 +179,7 @@ Path Domain Widgets ------------------- Path domain widgets have a ability to control or affect the audio signal or -audio paths within the audio subsystem. They have the following form:- +audio paths within the audio subsystem. They have the following form: :: SND_SOC_DAPM_PGA(name, reg, shift, invert, controls, num_controls) @@ -207,7 +219,7 @@ powered. e.g. A machine widget can have an optional call back. e.g. Jack connector widget for an external Mic that enables Mic Bias -when the Mic is inserted:-:: +when the Mic is inserted:: static int spitz_mic_bias(struct snd_soc_dapm_widget* w, int event) { @@ -221,7 +233,7 @@ when the Mic is inserted:-:: Codec (BIAS) Domain ------------------- -The codec bias power domain has no widgets and is handled by the codecs DAPM +The codec bias power domain has no widgets and is handled by the codec DAPM event handler. This handler is called when the codec powerstate is changed wrt to any stream event or by kernel PM events. @@ -229,17 +241,58 @@ to any stream event or by kernel PM events. Virtual Widgets --------------- -Sometimes widgets exist in the codec or machine audio map that don't have any +Sometimes widgets exist in the codec or machine audio graph that don't have any corresponding soft power control. In this case it is necessary to create a virtual widget - a widget with no control bits e.g. :: SND_SOC_DAPM_MIXER("AC97 Mixer", SND_SOC_NOPM, 0, 0, NULL, 0), -This can be used to merge to signal paths together in software. +This can be used to merge two signal paths together in software. -After all the widgets have been defined, they can then be added to the DAPM -subsystem individually with a call to snd_soc_dapm_new_control(). +Registering DAPM controls +========================= + +In many cases the DAPM widgets are implemented statically in a ``static +const struct snd_soc_dapm_widget`` array in a codec driver, and simply +declared via the ``dapm_widgets`` and ``num_dapm_widgets`` fields of the +``struct snd_soc_component_driver``. + +Similarly, routes connecting them are implemented statically in a ``static +const struct snd_soc_dapm_route`` array and declared via the +``dapm_routes`` and ``num_dapm_routes`` fields of the same struct. + +With the above declared, the driver registration will take care of +populating them:: + + static const struct snd_soc_dapm_widget wm2000_dapm_widgets[] = { + SND_SOC_DAPM_OUTPUT("SPKN"), + SND_SOC_DAPM_OUTPUT("SPKP"), + ... + }; + + /* Target, Path, Source */ + static const struct snd_soc_dapm_route wm2000_audio_map[] = { + { "SPKN", NULL, "ANC Engine" }, + { "SPKP", NULL, "ANC Engine" }, + ... + }; + + static const struct snd_soc_component_driver soc_component_dev_wm2000 = { + ... + .dapm_widgets = wm2000_dapm_widgets, + .num_dapm_widgets = ARRAY_SIZE(wm2000_dapm_widgets), + .dapm_routes = wm2000_audio_map, + .num_dapm_routes = ARRAY_SIZE(wm2000_audio_map), + ... + }; + +In more complex cases the list of DAPM widgets and/or routes can be only +known at probe time. This happens for example when a driver supports +different models having a different set of features. In those cases +separate widgets and routes arrays implementing the case-specific features +can be registered programmatically by calling snd_soc_dapm_new_controls() +and snd_soc_dapm_add_routes(). Codec/DSP Widget Interconnections @@ -247,31 +300,29 @@ Codec/DSP Widget Interconnections Widgets are connected to each other within the codec, platform and machine by audio paths (called interconnections). Each interconnection must be defined in -order to create a map of all audio paths between widgets. +order to create a graph of all audio paths between widgets. This is easiest with a diagram of the codec or DSP (and schematic of the machine audio system), as it requires joining widgets together via their audio signal paths. -e.g., from the WM8731 output mixer (wm8731.c) - -The WM8731 output mixer has 3 inputs (sources) +For example the WM8731 output mixer (wm8731.c) has 3 inputs (sources): 1. Line Bypass Input 2. DAC (HiFi playback) 3. Mic Sidetone Input -Each input in this example has a kcontrol associated with it (defined in example -above) and is connected to the output mixer via its kcontrol name. We can now -connect the destination widget (wrt audio signal) with its source widgets. -:: +Each input in this example has a kcontrol associated with it (defined in +the example above) and is connected to the output mixer via its kcontrol +name. We can now connect the destination widget (wrt audio signal) with its +source widgets. :: /* output mixer */ {"Output Mixer", "Line Bypass Switch", "Line Input"}, {"Output Mixer", "HiFi Playback Switch", "DAC"}, {"Output Mixer", "Mic Sidetone Switch", "Mic Bias"}, -So we have :- +So we have: * Destination Widget <=== Path Name <=== Source Widget, or * Sink, Path, Source, or @@ -280,12 +331,11 @@ So we have :- When there is no path name connecting widgets (e.g. a direct connection) we pass NULL for the path name. -Interconnections are created with a call to:- -:: +Interconnections are created with a call to:: snd_soc_dapm_connect_input(codec, sink, path, source); -Finally, snd_soc_dapm_new_widgets(codec) must be called after all widgets and +Finally, snd_soc_dapm_new_widgets() must be called after all widgets and interconnections have been registered with the core. This causes the core to scan the codec and machine so that the internal DAPM state matches the physical state of the machine. @@ -326,35 +376,44 @@ jacks can also be switched OFF. DAPM Widget Events ================== -Some widgets can register their interest with the DAPM core in PM events. -e.g. A Speaker with an amplifier registers a widget so the amplifier can be -powered only when the spk is in use. -:: +Widgets needing to implement a more complex behaviour than what DAPM can do +can set a custom "event handler" by setting a function pointer. An example +is a power supply needing to enable a GPIO:: - /* turn speaker amplifier on/off depending on use */ - static int corgi_amp_event(struct snd_soc_dapm_widget *w, int event) + static int sof_es8316_speaker_power_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) { - gpio_set_value(CORGI_GPIO_APM_ON, SND_SOC_DAPM_EVENT_ON(event)); - return 0; + if (SND_SOC_DAPM_EVENT_ON(event)) + gpiod_set_value_cansleep(gpio_pa, true); + else + gpiod_set_value_cansleep(gpio_pa, false); + + return 0; } - /* corgi machine dapm widgets */ - static const struct snd_soc_dapm_widget wm8731_dapm_widgets = - SND_SOC_DAPM_SPK("Ext Spk", corgi_amp_event); + static const struct snd_soc_dapm_widget st_widgets[] = { + ... + SND_SOC_DAPM_SUPPLY("Speaker Power", SND_SOC_NOPM, 0, 0, + sof_es8316_speaker_power_event, + SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMU), + }; -Please see soc-dapm.h for all other widgets that support events. +See soc-dapm.h for all other widgets that support events. Event types ----------- -The following event types are supported by event widgets. -:: +The following event types are supported by event widgets:: /* dapm event types */ - #define SND_SOC_DAPM_PRE_PMU 0x1 /* before widget power up */ - #define SND_SOC_DAPM_POST_PMU 0x2 /* after widget power up */ - #define SND_SOC_DAPM_PRE_PMD 0x4 /* before widget power down */ - #define SND_SOC_DAPM_POST_PMD 0x8 /* after widget power down */ - #define SND_SOC_DAPM_PRE_REG 0x10 /* before audio path setup */ - #define SND_SOC_DAPM_POST_REG 0x20 /* after audio path setup */ + #define SND_SOC_DAPM_PRE_PMU 0x1 /* before widget power up */ + #define SND_SOC_DAPM_POST_PMU 0x2 /* after widget power up */ + #define SND_SOC_DAPM_PRE_PMD 0x4 /* before widget power down */ + #define SND_SOC_DAPM_POST_PMD 0x8 /* after widget power down */ + #define SND_SOC_DAPM_PRE_REG 0x10 /* before audio path setup */ + #define SND_SOC_DAPM_POST_REG 0x20 /* after audio path setup */ + #define SND_SOC_DAPM_WILL_PMU 0x40 /* called at start of sequence */ + #define SND_SOC_DAPM_WILL_PMD 0x80 /* called at start of sequence */ + #define SND_SOC_DAPM_PRE_POST_PMD (SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMD) + #define SND_SOC_DAPM_PRE_POST_PMU (SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU) diff --git a/Documentation/sphinx/kernel_include.py b/Documentation/sphinx/kernel_include.py index abe768088377..638762442336 100755 --- a/Documentation/sphinx/kernel_include.py +++ b/Documentation/sphinx/kernel_include.py @@ -97,7 +97,6 @@ class KernelInclude(Include): # HINT: this is the only line I had to change / commented out: #path = utils.relative_path(None, path) - path = nodes.reprunicode(path) encoding = self.options.get( 'encoding', self.state.document.settings.input_encoding) e_handler=self.state.document.settings.input_encoding_error_handler diff --git a/Documentation/sphinx/kerneldoc-preamble.sty b/Documentation/sphinx/kerneldoc-preamble.sty index 3092df051c95..d479cfa73658 100644 --- a/Documentation/sphinx/kerneldoc-preamble.sty +++ b/Documentation/sphinx/kerneldoc-preamble.sty @@ -215,11 +215,12 @@ due to the lack of suitable font families and/or the texlive-xecjk package. - If you want them, please install ``Noto Sans CJK'' font families - along with the texlive-xecjk package by following instructions from + If you want them, please install non-variable ``Noto Sans CJK'' + font families along with the texlive-xecjk package by following + instructions from \sphinxcode{./scripts/sphinx-pre-install}. - Having optional ``Noto Serif CJK'' font families will improve - the looks of those translations. + Having optional non-variable ``Noto Serif CJK'' font families will + improve the looks of those translations. \end{sphinxadmonition}} \newcommand{\kerneldocEndSC}{} \newcommand{\kerneldocBeginTC}[1]{} diff --git a/Documentation/spi/index.rst b/Documentation/spi/index.rst index 06c34ea11bcf..824ce42ed4f0 100644 --- a/Documentation/spi/index.rst +++ b/Documentation/spi/index.rst @@ -10,7 +10,6 @@ Serial Peripheral Interface (SPI) spi-summary spidev butterfly - pxa2xx spi-lm70llp spi-sc18is602 diff --git a/Documentation/spi/pxa2xx.rst b/Documentation/spi/pxa2xx.rst deleted file mode 100644 index 19479b801826..000000000000 --- a/Documentation/spi/pxa2xx.rst +++ /dev/null @@ -1,211 +0,0 @@ -============================== -PXA2xx SPI on SSP driver HOWTO -============================== - -This a mini HOWTO on the pxa2xx_spi driver. The driver turns a PXA2xx -synchronous serial port into an SPI host controller -(see Documentation/spi/spi-summary.rst). The driver has the following features - -- Support for any PXA2xx and compatible SSP. -- SSP PIO and SSP DMA data transfers. -- External and Internal (SSPFRM) chip selects. -- Per peripheral device (chip) configuration. -- Full suspend, freeze, resume support. - -The driver is built around a &struct spi_message FIFO serviced by kernel -thread. The kernel thread, spi_pump_messages(), drives message FIFO and -is responsible for queuing SPI transactions and setting up and launching -the DMA or interrupt driven transfers. - -Declaring PXA2xx host controllers ---------------------------------- -Typically, for a legacy platform, an SPI host controller is defined in the -arch/.../mach-*/board-*.c as a "platform device". The host controller configuration -is passed to the driver via a table found in include/linux/spi/pxa2xx_spi.h:: - - struct pxa2xx_spi_controller { - u16 num_chipselect; - u8 enable_dma; - ... - }; - -The "pxa2xx_spi_controller.num_chipselect" field is used to determine the number of -peripheral devices (chips) attached to this SPI host controller. - -The "pxa2xx_spi_controller.enable_dma" field informs the driver that SSP DMA should -be used. This caused the driver to acquire two DMA channels: Rx channel and -Tx channel. The Rx channel has a higher DMA service priority than the Tx channel. -See the "PXA2xx Developer Manual" section "DMA Controller". - -For the new platforms the description of the controller and peripheral devices -comes from Device Tree or ACPI. - -NSSP HOST SAMPLE ----------------- -Below is a sample configuration using the PXA255 NSSP for a legacy platform:: - - static struct resource pxa_spi_nssp_resources[] = { - [0] = { - .start = __PREG(SSCR0_P(2)), /* Start address of NSSP */ - .end = __PREG(SSCR0_P(2)) + 0x2c, /* Range of registers */ - .flags = IORESOURCE_MEM, - }, - [1] = { - .start = IRQ_NSSP, /* NSSP IRQ */ - .end = IRQ_NSSP, - .flags = IORESOURCE_IRQ, - }, - }; - - static struct pxa2xx_spi_controller pxa_nssp_controller_info = { - .num_chipselect = 1, /* Matches the number of chips attached to NSSP */ - .enable_dma = 1, /* Enables NSSP DMA */ - }; - - static struct platform_device pxa_spi_nssp = { - .name = "pxa2xx-spi", /* MUST BE THIS VALUE, so device match driver */ - .id = 2, /* Bus number, MUST MATCH SSP number 1..n */ - .resource = pxa_spi_nssp_resources, - .num_resources = ARRAY_SIZE(pxa_spi_nssp_resources), - .dev = { - .platform_data = &pxa_nssp_controller_info, /* Passed to driver */ - }, - }; - - static struct platform_device *devices[] __initdata = { - &pxa_spi_nssp, - }; - - static void __init board_init(void) - { - (void)platform_add_device(devices, ARRAY_SIZE(devices)); - } - -Declaring peripheral devices ----------------------------- -Typically, for a legacy platform, each SPI peripheral device (chip) is defined in the -arch/.../mach-*/board-*.c using the "spi_board_info" structure found in -"linux/spi/spi.h". See "Documentation/spi/spi-summary.rst" for additional -information. - -Each peripheral device (chip) attached to the PXA2xx must provide specific chip configuration -information via the structure "pxa2xx_spi_chip" found in -"include/linux/spi/pxa2xx_spi.h". The PXA2xx host controller driver will use -the configuration whenever the driver communicates with the peripheral -device. All fields are optional. - -:: - - struct pxa2xx_spi_chip { - u8 tx_threshold; - u8 rx_threshold; - u8 dma_burst_size; - u32 timeout; - }; - -The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are -used to configure the SSP hardware FIFO. These fields are critical to the -performance of pxa2xx_spi driver and misconfiguration will result in rx -FIFO overruns (especially in PIO mode transfers). Good default values are:: - - .tx_threshold = 8, - .rx_threshold = 8, - -The range is 1 to 16 where zero indicates "use default". - -The "pxa2xx_spi_chip.dma_burst_size" field is used to configure PXA2xx DMA -engine and is related the "spi_device.bits_per_word" field. Read and understand -the PXA2xx "Developer Manual" sections on the DMA controller and SSP Controllers -to determine the correct value. An SSP configured for byte-wide transfers would -use a value of 8. The driver will determine a reasonable default if -dma_burst_size == 0. - -The "pxa2xx_spi_chip.timeout" fields is used to efficiently handle -trailing bytes in the SSP receiver FIFO. The correct value for this field is -dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific -peripheral device. Please note that the PXA2xx SSP 1 does not support trailing byte -timeouts and must busy-wait any trailing bytes. - -NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the -chipselect is dropped after each spi_transfer. Most devices need chip select -asserted around the complete message. Use SSPFRM as a GPIO (through a descriptor) -to accommodate these chips. - - -NSSP PERIPHERAL SAMPLE ----------------------- -For a legacy platform or in some other cases, the pxa2xx_spi_chip structure -is passed to the pxa2xx_spi driver in the "spi_board_info.controller_data" -field. Below is a sample configuration using the PXA255 NSSP. - -:: - - static struct pxa2xx_spi_chip cs8415a_chip_info = { - .tx_threshold = 8, /* SSP hardware FIFO threshold */ - .rx_threshold = 8, /* SSP hardware FIFO threshold */ - .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ - .timeout = 235, /* See Intel documentation */ - }; - - static struct pxa2xx_spi_chip cs8405a_chip_info = { - .tx_threshold = 8, /* SSP hardware FIFO threshold */ - .rx_threshold = 8, /* SSP hardware FIFO threshold */ - .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ - .timeout = 235, /* See Intel documentation */ - }; - - static struct spi_board_info streetracer_spi_board_info[] __initdata = { - { - .modalias = "cs8415a", /* Name of spi_driver for this device */ - .max_speed_hz = 3686400, /* Run SSP as fast a possible */ - .bus_num = 2, /* Framework bus number */ - .chip_select = 0, /* Framework chip select */ - .platform_data = NULL; /* No spi_driver specific config */ - .controller_data = &cs8415a_chip_info, /* Host controller config */ - .irq = STREETRACER_APCI_IRQ, /* Peripheral device interrupt */ - }, - { - .modalias = "cs8405a", /* Name of spi_driver for this device */ - .max_speed_hz = 3686400, /* Run SSP as fast a possible */ - .bus_num = 2, /* Framework bus number */ - .chip_select = 1, /* Framework chip select */ - .controller_data = &cs8405a_chip_info, /* Host controller config */ - .irq = STREETRACER_APCI_IRQ, /* Peripheral device interrupt */ - }, - }; - - static void __init streetracer_init(void) - { - spi_register_board_info(streetracer_spi_board_info, - ARRAY_SIZE(streetracer_spi_board_info)); - } - - -DMA and PIO I/O Support ------------------------ -The pxa2xx_spi driver supports both DMA and interrupt driven PIO message -transfers. The driver defaults to PIO mode and DMA transfers must be enabled -by setting the "enable_dma" flag in the "pxa2xx_spi_controller" structure. -For the newer platforms, that are known to support DMA, the driver will enable -it automatically and try it first with a possible fallback to PIO. The DMA -mode supports both coherent and stream based DMA mappings. - -The following logic is used to determine the type of I/O to be used on -a per "spi_transfer" basis:: - - if spi_message.len > 65536 then - if spi_message.is_dma_mapped or rx_dma_buf != 0 or tx_dma_buf != 0 then - reject premapped transfers - - print "rate limited" warning - use PIO transfers - - if enable_dma and the size is in the range [DMA burst size..65536] then - use streaming DMA mode - - otherwise - use PIO transfer - -THANKS TO ---------- -David Brownell and others for mentoring the development of this driver. diff --git a/Documentation/spi/spi-summary.rst b/Documentation/spi/spi-summary.rst index 546de37d6caf..7f8accfae6f9 100644 --- a/Documentation/spi/spi-summary.rst +++ b/Documentation/spi/spi-summary.rst @@ -348,7 +348,6 @@ SPI protocol drivers somewhat resemble platform device drivers:: static struct spi_driver CHIP_driver = { .driver = { .name = "CHIP", - .owner = THIS_MODULE, .pm = &CHIP_pm_ops, }, @@ -419,10 +418,6 @@ any more such messages. to make extra copies unless the hardware requires it (e.g. working around hardware errata that force the use of bounce buffering). - If standard dma_map_single() handling of these buffers is inappropriate, - you can use spi_message.is_dma_mapped to tell the controller driver - that you've already provided the relevant DMA addresses. - - The basic I/O primitive is spi_async(). Async requests may be issued in any context (irq handler, task, etc) and completion is reported using a callback provided with the message. diff --git a/Documentation/tee/index.rst b/Documentation/tee/index.rst index a23bd08847e5..4be6e69d7837 100644 --- a/Documentation/tee/index.rst +++ b/Documentation/tee/index.rst @@ -10,6 +10,7 @@ TEE Subsystem tee op-tee amd-tee + ts-tee .. only:: subproject and html diff --git a/Documentation/tee/ts-tee.rst b/Documentation/tee/ts-tee.rst new file mode 100644 index 000000000000..843e34422648 --- /dev/null +++ b/Documentation/tee/ts-tee.rst @@ -0,0 +1,71 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +TS-TEE (Trusted Services project) +================================= + +This driver provides access to secure services implemented by Trusted Services. + +Trusted Services [1] is a TrustedFirmware.org project that provides a framework +for developing and deploying device Root of Trust services in FF-A [2] S-EL0 +Secure Partitions. The project hosts the reference implementation of the Arm +Platform Security Architecture [3] for Arm A-profile devices. + +The FF-A Secure Partitions (SP) are accessible through the FF-A driver [4] which +provides the low level communication for this driver. On top of that the Trusted +Services RPC protocol is used [5]. To use the driver from user space a reference +implementation is provided at [6], which is part of the Trusted Services client +library called libts [7]. + +All Trusted Services (TS) SPs have the same FF-A UUID; it identifies the TS RPC +protocol. A TS SP can host one or more services (e.g. PSA Crypto, PSA ITS, etc). +A service is identified by its service UUID; the same type of service cannot be +present twice in the same SP. During SP boot each service in the SP is assigned +an "interface ID". This is just a short ID to simplify message addressing. + +The generic TEE design is to share memory at once with the Trusted OS, which can +then be reused to communicate with multiple applications running on the Trusted +OS. However, in case of FF-A, memory sharing works on an endpoint level, i.e. +memory is shared with a specific SP. User space has to be able to separately +share memory with each SP based on its endpoint ID; therefore a separate TEE +device is registered for each discovered TS SP. Opening the SP corresponds to +opening the TEE device and creating a TEE context. A TS SP hosts one or more +services. Opening a service corresponds to opening a session in the given +tee_context. + +Overview of a system with Trusted Services components:: + + User space Kernel space Secure world + ~~~~~~~~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~ + +--------+ +-------------+ + | Client | | Trusted | + +--------+ | Services SP | + /\ +-------------+ + || /\ + || || + || || + \/ \/ + +-------+ +----------+--------+ +-------------+ + | libts | | TEE | TS-TEE | | FF-A SPMC | + | | | subsys | driver | | + SPMD | + +-------+----------------+----+-----+--------+-----------+-------------+ + | Generic TEE API | | FF-A | TS RPC protocol | + | IOCTL (TEE_IOC_*) | | driver | over FF-A | + +-----------------------------+ +--------+-------------------------+ + +References +========== + +[1] https://www.trustedfirmware.org/projects/trusted-services/ + +[2] https://developer.arm.com/documentation/den0077/ + +[3] https://www.arm.com/architecture/security-features/platform-security + +[4] drivers/firmware/arm_ffa/ + +[5] https://trusted-services.readthedocs.io/en/v1.0.0/developer/service-access-protocols.html#abi + +[6] https://git.trustedfirmware.org/TS/trusted-services.git/tree/components/rpc/ts_rpc/caller/linux/ts_rpc_caller_linux.c?h=v1.0.0 + +[7] https://git.trustedfirmware.org/TS/trusted-services.git/tree/deployments/libts/arm-linux/CMakeLists.txt?h=v1.0.0 diff --git a/Documentation/trace/fprobetrace.rst b/Documentation/trace/fprobetrace.rst index 0f187e3796e4..b4c2ca3d02c1 100644 --- a/Documentation/trace/fprobetrace.rst +++ b/Documentation/trace/fprobetrace.rst @@ -74,7 +74,7 @@ Function arguments at exit -------------------------- Function arguments can be accessed at exit probe using $arg<N> fetcharg. This is useful to record the function parameter and return value at once, and -trace the difference of structure fields (for debuging a function whether it +trace the difference of structure fields (for debugging a function whether it correctly updates the given data structure or not) See the :ref:`sample<fprobetrace_exit_args_sample>` below for how it works. @@ -248,4 +248,4 @@ mode. You can trace that changes with return probe. cat-143 [007] ...1. 1945.720616: vfs_open__entry: (vfs_open+0x4/0x40) mode=0x1 inode=0x0 cat-143 [007] ...1. 1945.728263: vfs_open__exit: (do_open+0x274/0x3d0 <- vfs_open) mode=0xa800d inode=0xffff888004ada8d8 -You can see the `file::f_mode` and `file::f_inode` are upated in `vfs_open()`. +You can see the `file::f_mode` and `file::f_inode` are updated in `vfs_open()`. diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index 7e7b8ec17934..5aba74872ba7 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -1968,7 +1968,7 @@ wakeup One common case that people are interested in tracing is the time it takes for a task that is woken to actually wake up. Now for non Real-Time tasks, this can be arbitrary. But tracing -it none the less can be interesting. +it nonetheless can be interesting. Without function tracing:: diff --git a/Documentation/trace/kprobes.rst b/Documentation/trace/kprobes.rst index e1636e579c9c..5e606730cec6 100644 --- a/Documentation/trace/kprobes.rst +++ b/Documentation/trace/kprobes.rst @@ -322,6 +322,7 @@ architectures: - s390 - parisc - loongarch +- riscv Configuring Kprobes =================== diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst index a49662ccd53c..69cb7776ae99 100644 --- a/Documentation/trace/kprobetrace.rst +++ b/Documentation/trace/kprobetrace.rst @@ -74,7 +74,7 @@ Function arguments at kretprobe ------------------------------- Function arguments can be accessed at kretprobe using $arg<N> fetcharg. This is useful to record the function parameter and return value at once, and -trace the difference of structure fields (for debuging a function whether it +trace the difference of structure fields (for debugging a function whether it correctly updates the given data structure or not). See the :ref:`sample<fprobetrace_exit_args_sample>` in fprobe event for how it works. diff --git a/Documentation/trace/tracepoints.rst b/Documentation/trace/tracepoints.rst index 0cb8d9ca3d60..decabcc77b56 100644 --- a/Documentation/trace/tracepoints.rst +++ b/Documentation/trace/tracepoints.rst @@ -27,7 +27,7 @@ the tracepoint site). You can put tracepoints at important locations in the code. They are lightweight hooks that can pass an arbitrary number of parameters, -which prototypes are described in a tracepoint declaration placed in a +whose prototypes are described in a tracepoint declaration placed in a header file. They can be used for tracing and performance accounting. diff --git a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst index 5cece223b46b..74057d203539 100644 --- a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst +++ b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst @@ -180,9 +180,9 @@ Il valore di ritorno, se c'è, viene descritto in una sezione dedicata di nome se provate a formattare bene il vostro testo come nel seguente esempio:: * Return: - * 0 - OK - * -EINVAL - invalid argument - * -ENOMEM - out of memory + * %0 - OK + * %-EINVAL - invalid argument + * %-ENOMEM - out of memory le righe verranno unite e il risultato sarà:: @@ -192,8 +192,8 @@ Il valore di ritorno, se c'è, viene descritto in una sezione dedicata di nome utilizzare una lista ReST, ad esempio:: * Return: - * * 0 - OK to runtime suspend the device - * * -EBUSY - Device should not be runtime suspended + * * %0 - OK to runtime suspend the device + * * %-EBUSY - Device should not be runtime suspended #) Se il vostro testo ha delle righe che iniziano con una frase seguita dai due punti, allora ognuna di queste frasi verrà considerata come il nome diff --git a/Documentation/translations/it_IT/index.rst b/Documentation/translations/it_IT/index.rst index 70ccd23b2cde..9220f65e30d1 100644 --- a/Documentation/translations/it_IT/index.rst +++ b/Documentation/translations/it_IT/index.rst @@ -132,4 +132,4 @@ Documentazione varia Ci sono documenti che sono difficili da inserire nell'attuale organizzazione della documentazione; altri hanno bisogno di essere migliorati e/o convertiti -nel formato *ReStructured Text*; altri sono semplicamente troppo vecchi. +nel formato *reStructuredText*; altri sono semplicamente troppo vecchi. diff --git a/Documentation/translations/it_IT/process/2.Process.rst b/Documentation/translations/it_IT/process/2.Process.rst index 25cd00351c03..0a62c0f33faf 100644 --- a/Documentation/translations/it_IT/process/2.Process.rst +++ b/Documentation/translations/it_IT/process/2.Process.rst @@ -462,9 +462,12 @@ linux-kernel: di far domande. Molti sviluppatori possono divenire impazienti con le persone che chiaramente non hanno svolto i propri compiti a casa. -- Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra - alla frase alla quale state rispondendo). Ciò renderebbe la vostra risposta - difficile da leggere e genera scarsa impressione. +- Rispondete sotto alla porzione di righe citate, così da dare un contesto alle + vostre risposte, e quindi renderle più leggibili (in altre parole, evitate di + rispondere in cima, ovvero prima del testo citato). Per maggiori dettagli + leggete :ref:`Documentation/translations/it_IT/process/submitting-patches.rst + <it_interleaved_replies>`. + - Chiedete nella lista di discussione corretta. Linux-kernel può essere un punto di incontro generale, ma non è il miglior posto dove trovare diff --git a/Documentation/translations/it_IT/process/4.Coding.rst b/Documentation/translations/it_IT/process/4.Coding.rst index 54fd255b77d0..ec874a8dfb9d 100644 --- a/Documentation/translations/it_IT/process/4.Coding.rst +++ b/Documentation/translations/it_IT/process/4.Coding.rst @@ -72,6 +72,10 @@ compiti del genere. Consultate il file :ref:`Documentation/translations/it_IT/process/clang-format.rst <clangformat>` per maggiori dettagli +Se utilizzate un programma compatibile con EditorConfig, allora alcune +configurazioni basilari come l'indentazione e la fine delle righe verranno +applicate automaticamente. Per maggiori informazioni consultate la pagina: +https://editorconfig.org/ Livelli di astrazione ********************* diff --git a/Documentation/translations/it_IT/process/7.AdvancedTopics.rst b/Documentation/translations/it_IT/process/7.AdvancedTopics.rst index dffd813a0910..a83fcfe18024 100644 --- a/Documentation/translations/it_IT/process/7.AdvancedTopics.rst +++ b/Documentation/translations/it_IT/process/7.AdvancedTopics.rst @@ -160,6 +160,8 @@ preparerà una richiesta nel modo in cui gli altri sviluppatori se l'aspettano, e verificherà che vi siate ricordati di pubblicare quelle patch su un server pubblico. +.. _development_advancedtopics_reviews_it: + Revisionare le patch -------------------- @@ -180,6 +182,13 @@ i commenti come domande e non come critiche. Chiedere "Come viene rilasciato il *lock* in questo percorso?" funziona sempre molto meglio che "qui la sincronizzazione è sbagliata". +In caso di disaccordi, può essere utile chiedere una terza opinione. Se dopo +pochi scambi la discussione raggiunge un punto morto, allora chiedete ai +manutentori o altri revisori di partecipare esprimendo la loro opinione. Spesso +vige un silenzio assenso per cui gli altri revisori non intervengono se non gli +viene richiesto esplicitamente. L'opinione di più persone avrà sicuramente un +peso maggiore. + Diversi sviluppatori revisioneranno il codice con diversi punti di vista. Alcuni potrebbero concentrarsi principalmente sullo stile del codice e se alcune linee hanno degli spazio bianchi di troppo. Altri si chiederanno @@ -189,3 +198,13 @@ l'uso eccessivo di *stack*, problemi di sicurezza, duplicazione del codice in altri contesti, documentazione, effetti negativi sulle prestazioni, cambi all'ABI dello spazio utente, eccetera. Qualunque tipo di revisione è ben accetta e di valore, se porta ad avere un codice migliore nel kernel. + +Non esistono requisiti particolarmente stringenti per l'uso di etichette come +``Reviewd-by``. Tuttavia, perché la revisione sia efficace ci si aspetta un +qualche tipo di messaggio che dica "ho verificato A, B e C nel codice che è +appena stato inviato e mi sembra tutto in ordine". Inoltre, questo permette ai +manutentori di prendere conoscenza circa una revisione avvenuta per davvero. + +Per finire, la revisione delle patch può diventare un processo negativo, troppo +focalizzato sulla ricerca dei problemi. Provate a fare qualche complimento di +tanto in tanto, specialmente con i nuovi arrivati. diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst index f37c53f8b524..ade695a7de19 100644 --- a/Documentation/translations/it_IT/process/changes.rst +++ b/Documentation/translations/it_IT/process/changes.rst @@ -34,13 +34,15 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils. ====================== ================= ======================================== GNU C 5.1 gcc --version Clang/LLVM (optional) 11.0.0 clang --version +Rust (opzionale) 1.74.1 rustc --version +bindgen (opzionale) 0.65.1 bindgen --version GNU make 3.81 make --version bash 4.2 bash --version binutils 2.25 ld -v flex 2.5.35 flex --version bison 2.0 bison --version pahole 1.16 pahole --version -util-linux 2.10o fdformat --version +util-linux 2.10o mount --version kmod 13 depmod -V e2fsprogs 1.41.4 e2fsck -V jfsutils 1.1.3 fsck.jfs -V @@ -59,8 +61,10 @@ mcelog 0.6 mcelog --version iptables 1.4.2 iptables -V openssl & libcrypto 1.0.0 openssl version bc 1.06.95 bc --version -Sphinx\ [#f1]_ 1.7 sphinx-build --version +Sphinx\ [#f1]_ 2.4.4 sphinx-build --version cpio any cpio --version +GNU tar 1.28 tar --version +gtags (opzionale) 6.6.5 gtags --version ====================== ================= ======================================== .. [#f1] Sphinx è necessario solo per produrre la documentazione del Kernel @@ -151,6 +155,18 @@ Se la firma dei moduli è abilitata, allora vi servirà openssl per compilare il kernel 3.7 e successivi. Vi serviranno anche i pacchetti di sviluppo di openssl per compilare il kernel 4.3 o successivi. +Tar +--- + +GNU Tar è necessario per accedere ai file d'intestazione del kernel usando sysfs +(CONFIG_IKHEADERS) + +gtags / GNU GLOBAL (opzionale) +------------------------------ + +Il programma GNU GLOBAL versione 6.6.5, o successiva, è necessario quando si +vuole eseguire ``make gtags`` e generare i relativi indici. Internamente si fa +uso del parametro gtags ``-C (--directory)`` che compare in questa versione. Strumenti di sistema ******************** @@ -434,7 +450,7 @@ E2fsprogs JFSutils -------- -- <http://jfs.sourceforge.net/> +- <https://jfs.sourceforge.net/> Reiserfsprogs ------------- @@ -455,7 +471,7 @@ Pcmciautils Quota-tools ----------- -- <http://sourceforge.net/projects/linuxquota/> +- <https://sourceforge.net/projects/linuxquota/> Microcodice Intel P6 @@ -476,7 +492,7 @@ FUSE mcelog ------ -- <http://www.mcelog.org/> +- <https://www.mcelog.org/> cpio ---- @@ -497,7 +513,8 @@ PPP NFS-utils --------- -- <http://sourceforge.net/project/showfiles.php?group_id=14> +- <https://sourceforge.net/project/showfiles.php?group_id=14> +- <https://nfs.sourceforge.net/> Iptables -------- @@ -512,12 +529,7 @@ Ip-route2 OProfile -------- -- <http://oprofile.sf.net/download/> - -NFS-Utils ---------- - -- <http://nfs.sourceforge.net/> +- <https://oprofile.sf.net/download/> Documentazione del kernel ************************* diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index 284a75ac19f8..a4b9f44081da 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -214,7 +214,7 @@ Non usate inutilmente le graffe dove una singola espressione è sufficiente. e -.. code-block:: none +.. code-block:: c if (condition) do_this(); @@ -652,7 +652,7 @@ Quindi, potete sbarazzarvi di GNU emacs, o riconfigurarlo con valori più sensati. Per fare quest'ultima cosa, potete appiccicare il codice che segue nel vostro file .emacs: -.. code-block:: none +.. code-block:: elisp (defun c-lineup-arglist-tabs-only (ignored) "Line up argument lists by tabs, not spaces" @@ -728,6 +728,10 @@ il testo e altre cose simili. Per maggiori dettagli, consultate il file :ref:`Documentation/translations/it_IT/process/clang-format.rst <it_clangformat>`. +Se utilizzate un programma compatibile con EditorConfig, allora alcune +configurazioni basilari come l'indentazione e la fine delle righe verranno +applicate automaticamente. Per maggiori informazioni consultate la pagina: +https://editorconfig.org/ 10) File di configurazione Kconfig ---------------------------------- @@ -898,7 +902,9 @@ usare per assicurarvi che i messaggi vengano associati correttamente ai dispositivi e ai driver, e che siano etichettati correttamente: dev_err(), dev_warn(), dev_info(), e così via. Per messaggi che non sono associati ad alcun dispositivo, <linux/printk.h> definisce pr_info(), pr_warn(), pr_err(), -eccetera. +eccetera. Quando tutto funziona correttamente, non dovrebbero esserci stampe, +per cui preferite dev_dbg/pr_debug a meno che non sia qualcosa di sbagliato +da segnalare. Tirar fuori un buon messaggio di debug può essere una vera sfida; e quando l'avete può essere d'enorme aiuto per risolvere problemi da remoto. diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst index ba0ed7dc154c..d4ab76e9be49 100644 --- a/Documentation/translations/it_IT/process/deprecated.rst +++ b/Documentation/translations/it_IT/process/deprecated.rst @@ -86,7 +86,7 @@ da kcalloc(). Se questo tipo di allocatore non è disponibile, allora dovrebbero essere usate le funzioni del tipo *saturate-on-overflow*:: - bar = vmalloc(array_size(count, size)); + bar = dma_alloc_coherent(dev, array_size(count, size), &dma, GFP_KERNEL); Un altro tipico caso da evitare è quello di calcolare la dimensione di una struttura seguita da un vettore di altre strutture, come nel seguente caso:: diff --git a/Documentation/translations/it_IT/process/howto.rst b/Documentation/translations/it_IT/process/howto.rst index 052f1b3610cb..090941a0a898 100644 --- a/Documentation/translations/it_IT/process/howto.rst +++ b/Documentation/translations/it_IT/process/howto.rst @@ -85,8 +85,8 @@ relativi file di documentatione che spiegano come usarele. Quando un cambiamento del kernel genera anche un cambiamento nell'interfaccia con lo spazio utente, è raccomandabile che inviate una notifica o una correzione alle pagine *man* spiegando tale modifica agli amministratori di -queste pagine all'indirizzo mtk.manpages@gmail.com, aggiungendo -in CC la lista linux-api@vger.kernel.org. +queste pagine all'indirizzo alx@kernel.org, aggiungendo in CC la +lista linux-api@vger.kernel.org. Di seguito una lista di file che sono presenti nei sorgente del kernel e che è richiesto che voi leggiate: @@ -144,7 +144,7 @@ Di seguito una lista di file che sono presenti nei sorgente del kernel e che dello sviluppo di Linux ed è molto importante per le persone che arrivano da esperienze con altri Sistemi Operativi. - :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>` + :ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>` Se ritenete di aver trovato un problema di sicurezza nel kernel Linux, seguite i passaggi scritti in questo documento per notificarlo agli sviluppatori del kernel, ed aiutare la risoluzione del problema. diff --git a/Documentation/translations/it_IT/process/index.rst b/Documentation/translations/it_IT/process/index.rst index cd7977905fb8..73c643dcc541 100644 --- a/Documentation/translations/it_IT/process/index.rst +++ b/Documentation/translations/it_IT/process/index.rst @@ -21,19 +21,75 @@ l'accettazione delle vostre modifiche con il minimo sforzo. Di seguito le guide che ogni sviluppatore dovrebbe leggere. +Introduzione al funzionamento dello sviluppo del kernel +------------------------------------------------------- + +Innanzitutto, leggete questi documenti che vi aiuteranno ad entrare nella +comunità del kernel. + .. toctree:: :maxdepth: 1 howto - code-of-conduct development-process submitting-patches + submit-checklist + +Strumenti e guide tecniche per gli sviluppatori del kernel +---------------------------------------------------------- + +Quella che segue è una raccolta di documenti che uno sviluppatore del kernel +Linux dovrebbe conoscere. + +.. toctree:: + :maxdepth: 1 + + changes programming-language coding-style maintainer-pgp-guide email-clients + applying-patches + adding-syscalls + volatile-considered-harmful + botching-up-ioctls + +Politiche e dichiarazioni degli sviluppatori +-------------------------------------------- + +Quelle che seguono rappresentano le regole che cerchiamo di seguire all'interno +della comunità del kernel (e oltre). + +.. toctree:: + :maxdepth: 1 + + code-of-conduct kernel-enforcement-statement kernel-driver-statement + stable-api-nonsense + stable-kernel-rules + management-style + +Gestire i bachi +--------------- + +I bachi sono parte della nostra vita; dunque è importante che vengano trattati +con riguardo. I documenti che seguono descrivono le nostre politiche riguardo al +trattamento di alcune classi particolari di bachi: le regressioni e i problemi +di sicurezza. + +Informazioni per i manutentori +------------------------------ + +Come trovare le persone che accetteranno le vostre modifiche. + +.. toctree:: + :maxdepth: 1 + + maintainers + +Altri documenti +--------------- Poi ci sono altre guide sulla comunità che sono di interesse per molti degli sviluppatori: @@ -41,13 +97,7 @@ degli sviluppatori: .. toctree:: :maxdepth: 1 - changes - stable-api-nonsense - management-style - stable-kernel-rules - submit-checklist kernel-docs - maintainers Ed infine, qui ci sono alcune guide più tecniche che son state messe qua solo perché non si è trovato un posto migliore. @@ -55,11 +105,7 @@ perché non si è trovato un posto migliore. .. toctree:: :maxdepth: 1 - applying-patches - adding-syscalls magic-number - volatile-considered-harmful - botching-up-ioctls clang-format ../riscv/patch-acceptance diff --git a/Documentation/translations/it_IT/admin-guide/security-bugs.rst b/Documentation/translations/it_IT/process/security-bugs.rst index 20994f4bfa31..20994f4bfa31 100644 --- a/Documentation/translations/it_IT/admin-guide/security-bugs.rst +++ b/Documentation/translations/it_IT/process/security-bugs.rst diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index 248bf1e4b171..a2577a806a18 100644 --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst @@ -44,7 +44,7 @@ Procedura per sottomettere patch per i sorgenti -stable .. note:: Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo di revisione -stable, ma dovrebbe seguire le procedure descritte in - :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`. + :ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>`. Per tutte le altre sottomissioni, scegliere una delle seguenti procedure ------------------------------------------------------------------------ diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index f91c8092844f..4c6a276bdc08 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -349,6 +349,33 @@ Leggete Documentation/translations/it_IT/process/email-clients.rst per le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare sulle liste di discussione. +.. _it_interleaved_replies: + +Rispondere alle email in riga e riducendo la citazioni +------------------------------------------------------ + +Nelle discussioni riguardo allo sviluppo del kernel viene fortemente scoraggiato +l'uso di risposte in cima ai messaggi di posta elettronica. Rispondere in riga +rende le conversazioni molto più scorrevoli. Maggiori dettagli possono essere +trovati qui: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style + +Come spesso citato nelle liste di discussione:: + + R: http://en.wikipedia.org/wiki/Top_post + D: Dove posso trovare informazioni riguardo alle "risposte in cima"? + R: Perché incasina il normale ordine con cui si legge un testo. + D: Perché è così terribile rispondere in cima? + R: Risposte in cima. + Q: Qual è la cosa più fastidiosa nei messaggi di posta elettronica? + +Allo stesso modo, per favore eliminate tutte le citazioni non necessarie per la +vostra risposta. Questo permette di trovare più facilmente le risposte, e +permette di risparmiare tempo e spazio. Per maggiori dettagli: +http://daringfireball.net/2007/07/on_top :: + + R: No. + D: Dovrei includere un blocco di citazione dopo la mia risposta? + .. _it_resend_reminders: Non scoraggiatevi - o impazientitevi diff --git a/Documentation/translations/ja_JP/process/howto.rst b/Documentation/translations/ja_JP/process/howto.rst index 8d856ebe873c..872876c67896 100644 --- a/Documentation/translations/ja_JP/process/howto.rst +++ b/Documentation/translations/ja_JP/process/howto.rst @@ -110,7 +110,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを 新しいドキュメントファイルも追加することを勧めます。 カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの 変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報 -をマニュアルページのメンテナ mtk.manpages@gmail.com に送り、CC を +をマニュアルページのメンテナ alx@kernel.org に送り、CC を linux-api@vger.kernel.org に送ることを勧めます。 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst index c543b495c042..274ef4ad96b9 100644 --- a/Documentation/translations/sp_SP/index.rst +++ b/Documentation/translations/sp_SP/index.rst @@ -7,7 +7,7 @@ Traducción al español \kerneldocCJKoff -:maintainer: Carlos Bilbao <carlos.bilbao@amd.com> +:maintainer: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_disclaimer: diff --git a/Documentation/translations/sp_SP/memory-barriers.txt b/Documentation/translations/sp_SP/memory-barriers.txt index 27097a808c88..153e57130775 100644 --- a/Documentation/translations/sp_SP/memory-barriers.txt +++ b/Documentation/translations/sp_SP/memory-barriers.txt @@ -1,6 +1,6 @@ NOTE: This is a version of Documentation/memory-barriers.txt translated into -Spanish by Carlos Bilbao <carlos.bilbao@amd.com>. If you find any +Spanish by Carlos Bilbao <carlos.bilbao.osdev@gmail.com>. If you find any difference between this document and the original file or a problem with the translation, please contact the maintainer of this file. Please also note that the purpose of this file is to be easier to read for non English @@ -18,7 +18,7 @@ Documento original: David Howells <dhowells@redhat.com> Will Deacon <will.deacon@arm.com> Peter Zijlstra <peterz@infradead.org> -Traducido por: Carlos Bilbao <carlos.bilbao@amd.com> +Traducido por: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> Nota: Si tiene alguna duda sobre la exactitud del contenido de esta traducción, la única referencia válida es la documentación oficial en inglés. diff --git a/Documentation/translations/sp_SP/process/1.Intro.rst b/Documentation/translations/sp_SP/process/1.Intro.rst new file mode 100644 index 000000000000..9b92b6c85221 --- /dev/null +++ b/Documentation/translations/sp_SP/process/1.Intro.rst @@ -0,0 +1,302 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/1.Intro.rst +:Translator: Avadhut Naik <avadhut.naik@amd.com> + +.. _sp_development_process_intro: + +Introducción +============ + +Resumen ejecutivo +----------------- + +El resto de esta sección cubre el alcance del proceso de desarrollo del +kernel y los tipos de frustraciones que los desarrolladores y sus +empleadores pueden encontrar allí. Hay muchas razones por las que el +código del kernel debe fusionarse con el kernel oficial (“mainline”), +incluyendo la disponibilidad automática para los usuarios, el apoyo de la +comunidad en muchas formas, y la capacidad de influir en la dirección del +desarrollo del kernel. El código contribuido al kernel de Linux debe +estar disponible bajo una licencia compatible con GPL. + +:ref:`sp_development_process` introduce el proceso de desarrollo, el ciclo +de lanzamiento del kernel y la mecánica de la "ventana de combinación" +(merge window). Se cubren las distintas fases en el desarrollo del parche, +la revisión y, el ciclo de fusión. Hay algunas discusiones sobre +herramientas y listas de correo. Se anima a los desarrolladores que deseen +comenzar con el desarrollo del kernel a encontrar y corregir errores como +ejercicio inicial. + +:ref:`sp_development_early_stage` cubre la planificación de proyectos en +etapas tempranas, con énfasis en involucrar a la comunidad de desarrollo +lo antes posible. + +:ref:`sp_development_coding` trata sobre el proceso de codificación. Se +discuten varios escollos encontrados por otros desarrolladores. Se cubren +algunos requisitos para los parches, y hay una introducción a algunas de +las herramientas que pueden ayudar a garantizar que los parches del kernel +sean correctos. + +:ref:`sp_development_posting` trata sobre el proceso de enviar parches para +su revisión. Para ser tomados en serio por la comunidad de desarrollo, +los parches deben estar correctamente formateados y descritos, y deben +enviarse al lugar correcto. Seguir los consejos de esta sección debería +ayudar a garantizar la mejor recepción posible para su trabajo. + +:ref:`sp_development_followthrough` cubre lo que sucede después de publicar +parches; el trabajo está lejos de terminar en ese momento. Trabajar con +revisores es una parte crucial del proceso de desarrollo; esta sección +ofrece varios consejos sobre cómo evitar problemas en esta importante +etapa. Se advierte a los desarrolladores que no asuman que el trabajo está +terminado cuando un parche se fusiona en mainline. + +:ref:`sp_development_advancedtopics` introduce un par de temas “avanzados”: +la administración de parches con git y la revisión de parches publicados +por otros. + +:ref:`sp_development_conclusion` concluye el documento con punteros a las +fuentes para obtener más información sobre el desarrollo del kernel. + +De qué trata este documento +--------------------------- + +El kernel de Linux, con más de 8 millones de líneas de código y más de +1000 colaboradores en cada versión, en uno de los proyectos de software +libre más grandes y activos que existen. Desde sus humildes comienzos en +1991, este kernel ha evolucionado hasta convertirse en el mejor componente +del sistema operativo que se ejecuta en reproductores de música digital +de bolsillo, PC de escritorio, las supercomputadoras más grandes que +existen y todo tipo de sistemas intermedios. Es una solución robusta, +eficiente, y escalable para casi cualquier situación. + +Con el crecimiento de Linux, ha llegado un aumento en el número de +desarrolladores (y empresas) que desean participar en su desarrollo. Los +vendedores de hardware quieren asegurarse de que Linux sea compatible con +sus productos, lo que hace que esos productos sean atractivos para los +usuarios de Linux. Los vendedores de sistemas embebidos, que utilizan +Linux como componente de un producto integrado, quieren que Linux sea lo +más capaz y adecuado posible para tarea en cuestión. Los distribuidores +y otros vendedores de software que basan sus productos en Linux tienen un +claro interés en las capacidades, el rendimiento, y la fiabilidad del +kernel de Linux. Y los usuarios finales, también, a menudo desearán +cambiar Linux para que se adapte mejor a sus necesidades. + +Una de las características más convincentes de Linux es que es accesible +a estos desarrolladores; cualquier persona con las habilidades necesarias +puede mejorar Linux e influir en la dirección de su desarrollo. Los +productos propietarios no pueden ofrecer este tipo de apertura, que es una +característica del proceso de software libre. Pero, en todo caso, el +kernel es aún más libre que la mayoría de los otros proyectos de software +libre. Un ciclo típico de desarrollo de kernel de tres meses puede +involucrar a más de 1000 desarrolladores que trabajan para más de 100 +empresas diferentes (o sin pertenecer a ninguna empresa). + +Trabajar con la comunidad de desarrollo del kernel no es especialmente +difícil. Pero, a pesar de eso, muchos colaboradores potenciales han +experimentado dificultades al tratar de hacer el trabajo del kernel. La +comunidad del kernel ha desarrollado sus propias formas distintivas de +operar, lo que le permite funcionar de manera fluida (y producir un +producto de alta calidad) en un entorno donde miles de líneas de código +se cambian todos los días. Por lo tanto, no es sorprendente que el +proceso de desarrollo del kernel de Linux difiera mucho de los métodos de +desarrollo propietarios. + +El proceso de desarrollo del kernel puede parecer extraño e intimidante +para los nuevos desarrolladores, pero hay buenas razones y una sólida +experiencia detrás de él. Un desarrollador que no entienda las formas de +la comunidad del kernel (o, peor aún, que intente burlarse o eludirlas) +tendrá una experiencia frustrante por delante. La comunidad de +desarrollo, si bien es servicial para aquellos que están tratando de +aprender, tiene poco tiempo para aquellos que no escuchan o que no se +preocupan por el proceso de desarrollo. + +Se espera que quienes lean este documento puedan evitar esa experiencia +frustrante. Hay mucho material aquí, pero el esfuerzo que implica leerlo +será recompensado en poco tiempo. La comunidad de desarrollo siempre +necesita desarrolladores que ayudan a mejorar el kernel; el siguiente +texto debería ayudarle – o a quienes trabajan para usted, a unirse a +nuestra comunidad. + +Créditos +-------- + +Este documento fue escrito por Jonathan Corbet, corbet@lwn.net. Ha sido +mejorado por los comentarios de Johannes Berg, James Berry, Alex Chiang, +Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur +Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata y +Jochen Voß. +Este trabajo fue respaldado por la Fundación Linux; gracias especialmente +a Amanda McPherson, quien reconoció el valor de este esfuerzo e hizo que +todo sucediera. + +Importancia de integrar el código en el mainline +------------------------------------------------ + +Algunas empresas y desarrolladores ocasionalmente se preguntan por qué +deberían molestarse en aprender cómo trabajar con la comunidad del +kernel y obtener su código en el kernel mainline (el “mainline” es el +kernel mantenido por Linus Torvalds y utilizado como base por los +distribuidores de Linux. A corto plazo, contribuir con código puede +parecer un gasto evitable; parece más fácil mantener el código separado +y dar soporte a los usuarios directamente. La verdad del asunto es que +mantener el código separado (“fuera del árbol”) es pan para hoy y hambre +para mañana. + +Para ilustrar los costos del código fuera-del-árbol, aquí hay algunos +aspectos relevantes del proceso de desarrollo del kernel. La mayoría de +estos se discutirán con mayor detalle más adelante en este documento. +Considerar: + +- El código que se ha fusionado con el kernel mainline está disponible + para todos los usuarios de Linux. Estará presente automáticamente en + todas las distribuciones que lo habiliten. No hay necesidad de discos + de controladores, descargas, o las molestias de admitir múltiples + versiones de múltiples distribuciones; todo simplemente funciona, para + el desarrollador y para el usuario. La incorporación al mainline + resuelve un gran número de problemas de distribución y soporte. + +- Mientras los desarrolladores del kernel se esfuerzan por mantener una + interfaz estable para el espacio de usuario, la API interna de kernel + está en constante cambio. La falta de una interfaz interna estable es + una decisión deliberada de diseño; permite realizar mejoras + fundamentales en cualquier momento y da como resultado un código de + mayor calidad. Pero uno resultado de esa política es que cualquier + código fuera-del-árbol requiere un mantenimiento constante si va a + funcionar con los nuevos kernels. Mantener el código fuera-del-árbol + requiere una cantidad significativa de trabajo sólo para que ese código + siga funcionando. + + En su lugar, el código en el mainline no requiere este trabajo como + resultado de una regla simple que requiere que cualquier desarrollador + que realice un cambio en la API también corrija cualquier código que + se rompa como resultado de ese cambio. Así que, el código fusionado en + el mainline tiene costos de mantenimiento significativamente más bajos. + +- Más allá de eso, el código que está en el kernel a menudo será + mejorado por otros desarrolladores. Resultados sorprendentes pueden + provenir de capacitar a su comunidad de usuarios y clientes para mejorar + su producto. + +- El código del kernel se somete a revisión, tanto antes como después + de fusionarse con el mainline. No importa cuán fuertes sean las + habilidades del desarrollador original, este proceso de revisión + invariablemente encuentra formas en las que se puede mejorar el código. + A menudo la revisión encuentra errores graves y problemas de seguridad. + Esto es especialmente cierto para el código que se ha desarrollado en + un entorno cerrado; dicho código se beneficia fuertemente de la + revisión por desarrolladores externos. El código fuera-del-árbol es + de menor calidad. + +- La participación en el proceso de desarrollo es su manera de influir en + la dirección del desarrollo del kernel. Los usuarios que se quejan + desde el sofa son escuchados, pero los desarrolladores activos tienen + una voz más fuerte – y la capacidad de implementar cambios que hacen + que el kernel funcione mejor para sus necesidades. + +- Cuando el código se mantiene por separado, siempre existe la posibilidad + de que un tercero contribuya a una implementación diferente de una + característica similar. Si eso sucede, conseguir que su código + fusionado será mucho más difícil – hasta el punto de la imposibilidad. + Entonces se enfrentará a las desagradables alternativas de (1) mantener + una característica no estándar fuera del árbol indefinidamente, o + (2) abandonar su código y migrar sus usuarios a la versión en el árbol. + +- La contribución del código es la acción fundamental que hace que todo + el proceso funcione. Al contribuir con su código, puede agregar nuevas + funcionalidades al kernel y proporcionar capacidades y ejemplos que son + útiles para otros desarrolladores del kernel. Si ha desarrollado código + para Linux (o está pensando en hacerlo), claramente tiene un interés + en el éxito continuo de esta plataforma; contribuir con código es una + de las mejores maneras de ayudar a garantizar ese éxito. + +Todo el razonamiento anterior se aplica a cualquier código de kernel +fuera-del-árbol, incluido el código que se distribuye en forma propietaria +y únicamente en binario. Sin embargo, hay factores adicionales que deben +tenerse en cuenta antes de considerar cualquier tipo de distribución de +código de kernel únicamente en binario. Estos incluyen: + +- Las cuestiones legales en torno a la distribución de módulos + propietarios del kernel son, en el mejor de los casos, confusas; + bastantes titulares de derechos de autor del kernel creen que la + mayoría de los módulos binarios son productos derivados del kernel y + que, como resultado, su distribución es una violación de la licencia + Pública General de GNU (sobre la que se dirá más adelante). El autor + de este texto no es abogado, y nada en este documento puede considerarse + asesoramiento legal. Solo los tribunales pueden determinar el verdadero + estatus legal de los módulos de código cerrado. Pero la incertidumbre + que acecha a esos módulos está ahí a pesar de todo. + +- Los módulos binarios aumentan enormemente la dificultad de depurar + problemas del kernel, hasta el punto de que la mayoría de los + desarrolladores del kernel ni siquiera lo intentarán. Por lo tanto, + la distribución de módulos únicamente en binario hará que sea más + difícil para sus usuarios obtener soporte de la comunidad. + +- El soporte también es más difícil para los distribuidores de módulos + únicamente en binario, que deben proporcionar una versión del módulo + para cada distribución y cada versión del kernel que deseen apoyar. + Podría requerir docenas de compilaciones de un solo módulo para + proporcionar una cobertura razonablemente completa, y sus usuarios + tendrán que actualizar su módulo por separado cada vez que + actualicen su kernel. + +- Todo lo que se dijo anteriormente sobre la revisión de código se aplica + doblemente al código cerrado. Dado que este código no está disponible + en absoluto, no puede haber sido revisado por la comunidad y, sin duda, + tendrá serios problemas. + +Los fabricantes de sistemas embebidos, en particular, pueden verse +tentados a ignorar gran parte de lo que se ha dicho en esta sección +creyendo que están enviando un producto autónomo que utiliza una +versión de kernel congelada y no requiere más desarrollo después de su +lanzamiento. Este argumento desaprovecha el valor de la revisión +generalizad del código y el valor de permitir que sus usuarios agreguen +capacidades a su producto. Pero estos productos también tienen una vida +comercial limitada, después de la cual se debe lanzar una nueva versión. +En ese punto, los vendedores cuyo código esté en el mainline y bien +mantenido estarán en una posición mucho mejor para preparar el nuevo +producto rápidamente para el mercado. + +Licencias +--------- + +El código se contribuye al kernel de Linux bajo varias licencias, pero +todo el código debe ser compatible con la versión 2 de la Licencia +Pública General de GNU (GPLv2), que cubre la distribución del kernel. En +la práctica, esto significa que todas las contribuciones de código están +cubiertas ya sea por la GPLv2 (con, opcionalmente, un lenguaje que permite +la distribución en versiones posteriores de la GPL) o por la licencia BSD +de tres cláusulas. Cualquier contribución que no esté cubierta por una +licencia compatible no será aceptada en el kernel. + +No se requieren (ni se solicitan) cesiones de derechos de autor para el +código aportado al kernel. Todo el código fusionado en el kernel +mainline conserva su propiedad original; como resultado, el kernel ahora +tiene miles de propietarios. + +Una implicación de esta estructura de propiedad es que cualquier intento +de cambiar la licencia del kernel está condenado a un fracaso casi seguro. +Hay pocos escenarios prácticos en los que se pueda obtener el acuerdo de +todos los titulares de derechos de autor (o eliminar su código del +kernel). Así que, en particular, no hay perspectivas de una migración a +la versión 3 de la GPL en un futuro previsible. + +Es imperativo que todo el código aportado al kernel sea legítimamente +software libre. Por esa razón, no se aceptará código de colaboradores +anónimos (o seudónimos). Todos los colaboradores están obligados a +“firmar” su código, indicando que el código puede ser distribuido con +el kernel bajo la GPL. El código que no ha sido licenciado como software +libre por su propietario, o que corre el riesgo de crear problemas +relacionadas con los derechos de autor para el kernel (como el código que +se deriva de esfuerzos de ingeniería inversa que carecen de las garantías +adecuadas) no puede ser contribuido. + +Las preguntas sobre cuestiones relacionadas con los derechos de autor son +comunes en las listas de correo de desarrollo de Linux. Normalmente, estas +preguntas no recibirán escasez de respuestas, pero se debe tener en cuenta +que las personas que responden a esas preguntas no son abogados y no +pueden proporcionar consejo legal. Si tiene preguntas legales relacionadas +con el código fuente de Linux, no hay sustituto para hablar con un abogado +que entienda este campo. Confiar en las respuestas obtenidas en listas +técnicas de correo es un asunto arriesgado. diff --git a/Documentation/translations/sp_SP/process/2.Process.rst b/Documentation/translations/sp_SP/process/2.Process.rst new file mode 100644 index 000000000000..5993eed71563 --- /dev/null +++ b/Documentation/translations/sp_SP/process/2.Process.rst @@ -0,0 +1,542 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/2.Process.rst +:Translator: Avadhut Naik <avadhut.naik@amd.com> + +.. _sp_development_process: + +Cómo funciona el proceso de desarrollo +====================================== + +El desarrollo del kernel de Linux a principios de la década de 1990 fue +un asunto relajado, con un número relativamente pequeño de usuarios y +desarrolladores involucrados. Con una base de usuarios en los millones y +alrededor de 2,000 desarrolladores involucrados durante un año, el kernel +ha tenido que adaptar varios procesos para mantener el desarrollo sin +problemas. Se requiere una comprensión solida de cómo funciona el proceso +para ser una parte efectiva del mismo. + +El panorama general +------------------- + +Los desarrolladores del kernel utilizan un proceso de lanzamiento basado +en el tiempo de manera flexible, con uno nuevo lanzamiento principal del +kernel ocurriendo cada dos o tres meses. El historial reciente de +lanzamientos se ve así: + + ====== ================== + 5.0 Marzo 3, 2019 + 5.1 Mayo 5, 2019 + 5.2 Julio 7, 2019 + 5.3 Septiembre 15, 2019 + 5.4 Noviembre 24, 2019 + 5.5 Enero 6, 2020 + ====== ================== + +Cada lanzamiento 5.x es un lanzamiento principal del kernel con nuevas +características, cambios internos en la API y más. Un lanzamiento típico +puede contener alrededor de 13,000 conjuntos de cambios incluyendo en +varias centenas de miles de líneas de código. 5.x es la vanguardia del +desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo +continuo que está integrando continuamente cambios importantes. + +Se sigue una disciplina relativamente sencilla con respecto a la fusión +de parches para cada lanzamiento. Al comienzo de cada ciclo de desarrollo, +se dice que la "merge window" (ventana de fusión) está abierta. En ese +momento, el código que se considera lo suficientemente estable (y que es +aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline. +La mayor parte de los cambios para un nuevo ciclo de desarrollo (y todos +los cambios principales) se fusionarán durante este tiempo, a un ritmo +cercano a los 1,000 cambios (“parches” o “conjuntos de cambios”) por +día. + +(Aparte, vale la pena señalar que los cambios integrados durante la +ventana de fusión no surgen de la nada; han sido recolectados, probados +y montados con anticipación. Como funciona ese proceso se describirá en +detalle más adelante). + +La ventana de fusión dura aproximadamente dos semanas. Al final de este +tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará +el primero de los kernels “rc”. Para el kernel destinado a ser 5.6, por +ejemplo, el lanzamiento al final de la ventana de fusión se llamará +5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas +características ha pasado y que el tiempo para estabilizar el siguiente +kernel ha comenzado. + +Durante las próximas seis a diez semanas, solo los parches que solucionen +problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio +más significativo, pero tales ocasiones son raras; los desarrolladores que +intentan fusionar nuevas características fuera de la ventana de fusión +suelen recibir una recepción poco amistosa. Como regla general, si se +pierde la ventana de fusión de una característica determinada, lo mejor +que puede hacer es esperar al siguiente ciclo de desarrollo. (Se hace una +excepción ocasional para los drivers de hardware que no se admitía +anteriormente; si no afectan a ningún código en árbol, no pueden causar +regresiones y debería ser seguro agregarlos en cualquier momento). + +A medida que las correcciones se abren paso en el mainline, la tasa de +parches se ralentizará con el tiempo. Linus lanza nuevos kernels -rc +aproximadamente una vez a la semana; una serie normal llegará a algún +punto entre -rc6 y -rc9 antes de que se considere que el kernel es +suficientemente estable y realice el lanzamiento final. En ese momento, +todo el proceso vuelve a empezar. + +Como ejemplo, así fue el ciclo de desarrollo de 5.4 (todas las fechas son +de 2019): + + ============== ======================================= + Septiembre 15 5.3 lanzamiento estable + Septiembre 30 5.4-rc1, la ventana de fusion se cierra + Octubre 6 5.4-rc2 + Octubre 13 5.4-rc3 + Octubre 20 5.4-rc4 + Octubre 27 5.4-rc5 + Noviembre 3 5.4-rc6 + Noviembre 10 5.4-rc7 + Noviembre 17 5.4-rc8 + Noviembre 24 5.4 lanzamiento estable + ============== ======================================= + +¿Cómo deciden los desarrolladores cuándo cerrar el ciclo de desarrollo +y crear el lanzamiento estable? La métrica más significativa utilizada +es la lista de regresiones de lanzamientos anteriores. Ningunos errores +son bienvenidos, pero aquellos que rompen sistemas que funcionaron en el +pasado se consideran especialmente graves. Por esta razón, los parches +que causan regresiones se ven con malos ojos y es bastante probable que +se reviertan durante el periodo de estabilización. + +El objetivo de los desarrolladores es corregir todas las regresiones +conocidas antes de que se realice el lanzamiento estable. En el mundo +real, este tipo de perfección es difícil de lograr; hay demasiados +variables en un proyecto de este tamaño. Llega un punto en el que +retrasar el lanzamiento final solo empeora el problema; la pila de cambios +que esperan la siguiente ventana de fusión crecerá, creando aún más +regresiones la próxima vez. Por lo tanto, la mayoría de los kernels 5.x +se lanzan con un punado de regresiones conocidas, aunque, con suerte, +ninguna de ellas es seria. + +Una vez que se realiza un lanzamiento estable, su mantenimiento continuo +se transfiere al “equipo estable”, actualmente encabezado por Greg +Kroah-Hartman. El equipo estable lanzará actualizaciones ocasionales al +lanzamiento estable utilizando el esquema de numeración 5.x.y. Para ser +considerado para un lanzamiento de actualización, un parche debe +(1) corregir un error significativo y (2) ya estar fusionado en el +mainline para el siguiente kernel de desarrollo. Por lo general, los +kernels recibirán actualizaciones estables durante un poco más de un +ciclo de desarrollo después de su lanzamiento inicial. Así, por ejemplo, +la historia del kernel 5.2 se veía así (todas las fechas en 2019): + + ============== =============================== + Julio 7 5.2 lanzamiento estable + Julio 14 5.2.1 + Julio 21 5.2.2 + Julio 26 5.2.3 + Julio 28 5.2.4 + Julio 31 5.2.5 + ... ... + Octubre 11 5.2.21 + ============== =============================== + +5.2.21 fue la última actualización estable del lanzamiento 5.2. + +Algunos kernels se designan como kernels “a largo plazo”; recibirán +soporte durante un periodo más largo. Consulte el siguiente enlace para +obtener la lista de versiones activas del kernel a largo plazos y sus +maintainers: + + https://www.kernel.org/category/releases.html + +La selección de un kernel para soporte a largo plazo es puramente una +cuestión de que un maintainer tenga la necesidad y el tiempo para +mantener ese lanzamiento. No hay planes conocidos para ofrecer soporte a +largo plazo para ningún lanzamiento especifico próximo. + +Ciclo de vida de un parche +-------------------------- + +Los parches no van directamente desde el teclado del desarrollador al +kernel mainline. Hay, en cambio, un proceso algo complicado (aunque algo +informal) diseñado para garantizar que cada parche sea revisado en cuanto +a calidad y que cada parche implemente un cambio que es deseable tener en +el mainline. Este proceso puede ocurrir rápidamente para correcciones +menores, o, en el caso de cambios grandes y controvertidos, continuar +durante años. Gran parte de la frustración de los desarrolladores proviene +de la falta de compresión de este proceso o de sus intentos de eludirlo. + +Con la esperanza de reducir esa frustración, este documento describirá +cómo un parche entra en el kernel. Lo que sigue a continuación es una +introducción que describe el proceso de una manera tanto idealizada. Un +tratamiento mucho más detallado vendrá en secciones posteriores. + +Las etapas por las que pasa un parche son, generalmente: + + - Diseño. Aquí es donde se establecen los requisitos reales para el + parche – y la forma en que se cumplirán esos requisitos. El trabajo + de diseño a menudo se realiza sin involucrar a la comunidad, pero es + mejor hacer este trabajo de manera abierta si es posible; puede ahorrar + mucho tiempo rediseñando las cosas más tarde. + + - Revisión inicial. Los parches se publican en la lista de correo + relevante y los desarrolladores en esa lista responden con cualquier + comentario que puedan tener. Este proceso debería revelar cualquier + problema importante con un parche si todo va bien. + + - Revisión más amplia. Cuando el parche se acerca a estar listo para su + inclusión en el mainline, debe ser aceptado por un maintainer del + subsistema relevante – aunque esta aceptación no es una garantía de + que el parche llegara hasta el mainline. El parche aparecerá en el + árbol de subsistemas del maintainer y en los árboles -next (descritos + a continuación). Cuando el proceso funciona, este paso conduce a una + revisión exhaustiva del parche y al descubrimiento de cualquier + problema resultante de la integración de este parche con el trabajo + realizado por otros. + + - Tenga en cuenta que la mayoría de los maintainers también tienen + trabajos diurnos, por lo que fusionar su parche no puede ser su máxima + prioridad. Si su parche está recibiendo comentarios sobre los cambios + que se necesitan, debería realizar esos cambios o justificar por qué + no deberían realizarse. Si su parche no tiene quejas de revisión, pero + no está siendo fusionado por el maintainer apropiado del subsistema o + del driver, debe ser persistente en la actualización del parche + al kernel actual para que se aplique limpiamente y seguir enviándolo + para su revisión y fusión. + + - Fusión en el mainline. Eventualmente, un parche exitoso se fusionará + en el repositorio mainline administrado por Linux Torvalds. Mas + comentarios y/o problemas pueden surgir en este momento; es importante + que el desarrollador responda a estos y solucione cualquier problema + que surja. + + - Lanzamiento estable. El número de usuarios potencialmente afectados por + el parche es ahora grande, por lo que, una vez más, pueden surgir + nuevos problemas. + + - Mantenimiento a largo plazo. Si bien un desarrollador puede olvidarse + del código después de fusionarlo, ese comportamiento tiende a dejar + una impresión negativa en la comunidad de desarrollo. Fusionar el + código elimina parte de la carga de mantenimiento; otros solucionarán + los problemas causados por los cambios en la API. Sin embargo, el + desarrollador original debe seguir asumiendo la responsabilidad del + código si quiere seguir siendo útil a largo plazo. + +Uno de los peores errores cometidos por los desarrolladores del kernel +(o sus empleadores) es tratar de reducir el proceso a un solo paso de +“fusión en el mainline”. Este enfoque conduce invariablemente a la +frustración de todos los involucrados. + +Cómo se integran los parches en el kernel +----------------------------------------- + +Hay exactamente una persona que puede fusionar parches en el repositorio +mainline del kernel: Linus Torvalds. Pero, por ejemplo, de los más de +9,500 parches que se incluyeron en el kernel 2.6.38, solo 112 (alrededor +del 1.3%) fueron elegidos directamente por Linus mismo. El proyecto del +kernel ha crecido mucho desde hace tiempo a un tamaño en el que ningún +desarrollador individual podría inspeccionar y seleccionar todos los +parches sin ayuda. La forma que los desarrolladores del kernel han +abordado este crecimiento es a través del uso de un sistema jerárquico +alrededor de una cadena de confianza. + +La base de código del kernel se descompone lógicamente en un conjunto de +subsistemas: redes, soporte de arquitectura especifica, gestión de +memoria, dispositivos de video, etc. La mayoría de los subsistemas tienen +un maintainer designado, un desarrollador que tiene la responsabilidad +general del código dentro de ese subsistema. Estos maintainers de +subsistemas son los guardianes (en cierto modo) de la parte del kernel que +gestionan; son los que (usualmente) aceptarán un parche para incluirlo en +el kernel mainline. + +Cada uno de los maintainers del subsistema administra su propia versión +del árbol de fuentes del kernel, generalmente (pero, ciertamente no +siempre) usando la herramienta de administración de código fuente de git. +Herramientas como git (y herramientas relacionadas como quilt o mercurial) +permiten a los maintainers realizar un seguimiento de una lista de +parches, incluida la información de autoría y otros metadatos. En +cualquier momento, el maintainer puede identificar qué parches de su +repositorio no se encuentran en el mainline. + +Cuando se abre la ventana de fusión, los maintainers de nivel superior +le pedirán a Linus que “extraiga” los parches que han seleccionado para +fusionar de sus repositorios. Si Linus está de acuerdo, el flujo de +parches fluirá hacia su repositorio, convirtiéndose en parte del kernel +mainline. La cantidad de atención que Linus presta a los parches +específicos recibidos en una operación de extracción varia. Está claro +que, a veces, examina bastante de cerca. Pero, como regla general, Linus +confía en que los maintainers del subsistema no envíen parches +defectuosos al upstream. + +Los maintainers de subsistemas, a su vez, pueden extraer parches de otros +maintainers. Por ejemplo, el árbol de red se construye a partir de +parches que se acumulan primero en arboles dedicados a drivers de +dispositivos de red, redes inalámbricas, etc. Esta cadena de repositorios +puede ser arbitrariamente larga, aunque rara vez supera los dos o tres +enlaces. Dado que cada maintainer de la cadena confía en los que +administran árboles de nivel inferior, este proceso se conoce como la +“cadena de confianza”. + +Claramente, en un sistema como este, lograr que los parches se integren +en el kernel depende de encontrar el maintainer adecuado. Enviar parches +directamente a Linus no es normalmente la forma correcta de hacerlo. + +Árboles siguientes (next) +------------------------- + +La cadena de árboles de subsistemas guía el flujo de parches en el +kernel, pero también plantea una pregunta interesante: ¿Qué pasa si +alguien quiere ver todos los parches que se están preparando para la +próxima ventana de fusión? Los desarrolladores estarán interesados en +saber que otros cambios están pendientes para ver si hay algún conflicto +del que preocuparse; un parche que cambia un prototipo de función del +núcleo del kernel, por ejemplo, entrará en conflicto con cualquier otro +parche que utilice la forma anterior de esa función. Los revisores y +probadores quieren tener acceso a los cambios en su forma integrada antes +de que todos esos cambios se integren en el kernel mainline. Uno podría +extraer cambios de todos los árboles de subsistemas interesantes, pero +eso sería un trabajo tedioso y propenso a errores. + +La respuesta viene en forma de árboles -next, donde los árboles de +subsistemas se recopilan para pruebas y revisiones. El más antiguo de +estos árboles, mantenido por Andrew Morton, se llama “-mm” (por gestión +de la memoria, que es como comenzó). El árbol “-mm” integra parches +de una larga lista de árboles de subsistemas; también tiene algunos +parches destinados a ayudar con la depuración. + +Más allá de eso, -mm contiene una colección significativa de parches +que han sido seleccionados directamente por Andrew. Estos parches pueden +haber sido publicados en una lista de correo o aplicarse a una parte del +kernel para la que no hay un árbol de subsistemas designado. Como +resultado, -mm funciona como una especie de árbol de subsistemas de +último recurso; si no hay otro camino obvio para un parche en el mainline, +es probable que termine en -mm. Los parches misceláneos que se acumulan +en -mm eventualmente se enviarán a un árbol de subsistema apropiado o se +enviarán directamente a Linus. En un ciclo de desarrollo típico, +aproximadamente el 5-10% de los parches que van al mainline llegan allí +a través de -mm. + +El parche -mm actual está disponible en el directorio “mmotm” (-mm +del momento) en: + + https://www.ozlabs.org/~akpm/mmotm/ + +Sin embargo, es probable que el uso del árbol MMOTM sea una experiencia +frustrante; existe una posibilidad definitiva de que ni siquiera se +compile. + +El árbol principal para la fusión de parches del siguiente ciclo es +linux-next, mantenido por Stephen Rothwell. El árbol linux-next es, por +diseño, una instantánea de cómo se espera que se vea el mainline después +de que se cierre la siguiente ventana de fusión. Los árboles linux-next +se anuncian en las listas de correo linux-kernel y linux-next cuando se +ensamblan; Se pueden descargar desde: + + https://www.kernel.org/pub/linux/kernel/next/ + +Linux-next se ha convertido en una parte integral del proceso de +desarrollo del kernel; todos los parches fusionados durante una ventana +de fusión determinada deberían haber encontrado su camino en linux-next +en algún momento antes de que se abra la ventana de fusión. + +Árboles de staging +------------------ + +El árbol de fuentes del kernel contiene el directorio drivers/staging/, +donde residen muchos subdirectorios para drivers o sistemas de archivos +que están en proceso de ser agregados al árbol del kernel. Permanecen +en drivers/staging mientras aún necesitan más trabajo; una vez +completados, se pueden mover al kernel propiamente dicho. Esta es una +forma de realizar un seguimiento de los drivers drivers que no están a la +altura de la codificación o los estándares de calidad del kernel de +Linux, pero que las personas pueden querer usarlos y realizar un +seguimiento del desarrollo. + +Greg Kroah-Hartman mantiene actualmente el árbol de staging. Los drivers +que aun necesitan trabajo se le envían, y cada driver tiene su propio +subdirectorio en drivers/staging/. Junto con los archivos de origen del +driver, también debe haber un archivo TODO en el directorio. El archivo +TODO enumera el trabajo pendiente que el driver necesita para ser aceptado +en el kernel propiamente dicho, así como una lista de personas a las que +Cc’d para cualquier parche para el driver. Las reglas actuales exigen +que los drivers que contribuyen a staging deben, como mínimo, compilarse +correctamente. + +El staging puede ser una forma relativamente fácil de conseguir nuevos +drivers en el mainline donde, con suerte, llamarán la atención de otros +desarrolladores y mejorarán rápidamente. Sin embargo, la entrada en el +staging no es el final de la historia; el código que no está viendo +progreso regular eventualmente será eliminado. Los distribuidores también +tienden a ser relativamente reacios a habilitar los drivers de staging. +Por lo tanto, el staging es, en el mejor de los casos, una parada en el +camino para hacia convertirse en un apropiado driver del mainline. + +Herramientas +------------ + +Como se puede ver en el texto anterior, el proceso de desarrollo del +kernel depende en gran medida de la capacidad de dirigir colecciones de +parches en varias direcciones. Todo ello no funcionaría tan bien como lo +hace sin herramientas apropiadamente potentes. Los tutoriales sobre cómo +usar estas herramientas están mucho más allá del alcance de este +documento, pero hay espacio para algunos consejos. + +Con mucho, el sistema de gestión de código fuente dominante utilizado +por la comunidad del kernel es git. Git es uno de los varios sistemas de +control de versiones distribuidos que se están desarrollando en la +comunidad de software libre. Está bien ajustado para el desarrollo de +kernel, ya que funciona bastante bien cuando se trata de grandes +repositorios y grandes cantidades de parches. También tiene la reputación +de ser difícil de aprender y usar, aunque ha mejorado con el tiempo. +Algún tipo de familiaridad con git es casi un requisito para los +desarrolladores del kernel; incluso si no lo usan para su propio +trabajo, necesitarán git para mantenerse al día con lo que otros +desarrolladores (y el mainline) están haciendo. + +Git ahora está empaquetado por casi todas las distribuciones de Linux. +Hay una página de inicio en: + + https://git-scm.com/ + +Esa página tiene punteros a documentación y tutoriales. + +Entre los desarrolladores de kernel que no usan git, la opción más +popular es casi con certeza Mercurial: + + https://www.selenic.com/mercurial/ + +Mercurial comparte muchas características con git, pero proporciona una +interfaz que muchos encuentran más fácil de usar. + +Otra herramienta que vale la pena conocer es Quilt: + + https://savannah.nongnu.org/projects/quilt/ + +Quilt es un sistema de gestión de parches, en lugar de un sistema de +gestión de código fuente. No rastrea el historial a lo largo del tiempo; +en cambio, está orientado al seguimiento de un conjunto especifico de +cambios en relación con una base de código en evolución. Algunos de los +principales maintainers de subsistemas utilizan Quilt para gestionar los +parches destinados a ir upstream. Para la gestión de ciertos tipos de +árboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trabajo. + +Listas de correo +---------------- + +Una gran parte del trabajo de desarrollo del kernel de Linux se realiza a +través de listas de correo. Es difícil ser un miembro plenamente funcional +de la comunidad sin unirse al menos a una lista en algún parte. Pero las +listas de correo de Linux también representan un peligro potencial para +los desarrolladores, que corren el riesgo de quedar enterrados bajo una +carga de correo electrónico, incumplir las convenciones utilizadas en las +listas de Linux, o ambas cosas. + +La mayoría de las listas de correo del kernel se ejecutan en +vger.kernel.org; la lista principal se puede encontrar en: + + http://vger.kernel.org/vger-lists.html + +Sim embargo, hay listas alojadas en otros lugares; varios de ellos se +encuentran en redhat.com/mailman/listinfo. + +La lista de correo principal para el desarrollo del kernel es, por +supuesto, linux-kernel. Esta lista es un lugar intimidante; el volumen +puede alcanzar 500 mensajes por día, la cantidad de ruido es alta, la +conversación puede ser muy técnica y los participantes no siempre se +preocupan por mostrar un alto grado de cortesía. Pero no hay otro lugar +donde la comunidad de desarrollo del kernel se reúna como un todo; los +desarrolladores que eviten esta lista se perderán información importante. + +Hay algunos consejos que pueden ayudar a sobrevivir en el kernel de Linux: + +- Haga que la lista se entregue en una carpeta separada, en lugar de su + buzón principal. Uno debe ser capaz de ignorar el flujo durante + periodos prolongados. + +- No trate de seguir cada conversación, nadie lo hace. Es importante + filtrar tanto por el tema de interés (aunque tenga en cuenta que las + conversaciones prolongadas pueden alejarse del asunto original sin + cambiar la línea de asunto del correo electrónico) por las personas + que participan. + +- No alimente a los trolls. Si alguien está tratando de provocar una + respuesta de enojo, ignórelos. + +- Al responder al correo electrónico del kernel de Linux (o al de otras + listas) conserve el encabezado Cc: para todos los involucrados. En + ausencia de una razón solida (como una solicitud explícita), nunca debe + eliminar destinarios. Asegúrese siempre de que la persona a la que está + respondiendo esté en la lista Cc:. Esta convención también hace que no + sea necesario solicitar explícitamente que se le copie en las respuestas + a sus publicaciones. + +- Busque en los archivos de la lista (y en la red en su conjunto) antes + de hacer preguntas. Algunos desarrolladores pueden impacientarse con + las personas que claramente no han hecho sus deberes. + +- Utilice respuestas intercaladas (“en línea”), lo que hace que su + respuesta sea más fácil de leer. (Es decir, evite top-posting – la + práctica de poner su respuesta encima del texto citado al que está + respondiendo.) Para obtener más información, consulte + :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_interleaved_replies>`. + +- Pregunte en la lista de correo correcta. linux-kernel puede ser el + punto de encuentro general, pero no es el mejor lugar para encontrar + desarrolladores de todos los subsistemas. + +El último punto, encontrar la lista de correo correcta, es una fuente +común de errores para desarrolladores principiantes. Alguien que haga +una pregunta relacionada con las redes en linux-kernel seguramente +recibirá una surgencia educada para preguntar en la lista de netdev en su +lugar, ya que esa es la lista frecuentada por la mayoría de los +desarrolladores de redes. Existen otras listas para los subsistemas SCSI, +video4linux, IDE, sistema de archivos, etc. El mejor lugar para buscar +listas de correo es en el archivo MAINTAINERS incluido con el código +fuente del kernel. + +Comenzar con el desarrollo del kernel +------------------------------------- + +Las preguntas sobre como comenzar con el proceso de desarrollo del kernel +son comunes, tanto de individuos como de empresas. Igualmente comunes son +los pasos en falso que hacen que el comienzo de la relación sea más +difícil de lo que tiene que ser. + +Las empresas a menudo buscan contratar desarrolladores conocidos para +iniciar un grupo de desarrollo. De hecho, esta puede ser una técnica +efectiva. Pero también tiende a ser caro y no hace mucho para crecer el +grupo de desarrolladores de kernel experimentados. Es posible poner al +día a los desarrolladores internos en el desarrollo de kernel de Linux, +dada la inversión de algún tiempo. Tomarse este tiempo puede dotar a un +empleador de un grupo de desarrolladores que comprendan tanto el kernel +como la empresa, y que también puedan ayudar a educar a otros. A medio +plazo, este es a menudo el enfoque más rentable. + +Los desarrolladores individuales, a menudo, comprensiblemente, no tienen +un lugar para empezar. Comenzar con un proyecto grande puede ser +intimidante; a menudo uno quiere probar las aguas con algo más pequeño +primero. Este es el punto en el que algunos desarrolladores se lanzan a +la creación de parches para corregir errores ortográficos o problemas +menores de estilo de codificación. Desafortunadamente, dicho parches +crean un nivel de ruido que distrae a la comunidad de desarrollo en su +conjunto, por lo que, cada vez más, se los mira con desprecio. Los nuevos +desarrolladores que deseen presentarse a la comunidad no recibirán la +recepción que desean por estos medios. + +Andrew Morton da este consejo (traducido) para los aspirantes a +desarrolladores de kernel. + +:: + + El proyecto #1 para los principiantes en el kernel seguramente debería + ser “asegúrese de que el kernel funcione perfectamente en todo momento + en todas las máquinas que pueda conseguir”. Por lo general, la forma + de hacer esto es trabajar con otros para arreglar las cosas (¡esto + puede requerir persistencia!), pero eso está bien, es parte del + desarrollo del kernel. + +(https://lwn.net/Articles/283982/) + +En ausencia de problemas obvios que solucionar, se aconseja a los +desarrolladores que consulten las listas actuales de regresiones y errores +abiertos en general. Nunca faltan problemas que necesitan solución; al +abordar estos problemas, los desarrolladores ganarán experiencia con el +proceso mientras, al mismo tiempo, se ganarán el respeto del resto de la +comunidad de desarrollo. diff --git a/Documentation/translations/sp_SP/process/3.Early-stage.rst b/Documentation/translations/sp_SP/process/3.Early-stage.rst new file mode 100644 index 000000000000..71cfb3fb0fda --- /dev/null +++ b/Documentation/translations/sp_SP/process/3.Early-stage.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/3.Early-stage.rst + +.. _sp_development_early_stage: + +Planificación en etapa inicial +============================== + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/4.Coding.rst b/Documentation/translations/sp_SP/process/4.Coding.rst new file mode 100644 index 000000000000..d9436e039b4b --- /dev/null +++ b/Documentation/translations/sp_SP/process/4.Coding.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/4.Coding.rst + +.. _sp_development_coding: + +Conseguir el código correcto +============================ + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/5.Posting.rst b/Documentation/translations/sp_SP/process/5.Posting.rst new file mode 100644 index 000000000000..50a3bc5998a8 --- /dev/null +++ b/Documentation/translations/sp_SP/process/5.Posting.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/5.Posting.rst + +.. _sp_development_posting: + +Publicar parches +================ + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/6.Followthrough.rst b/Documentation/translations/sp_SP/process/6.Followthrough.rst new file mode 100644 index 000000000000..f0acf9082bb3 --- /dev/null +++ b/Documentation/translations/sp_SP/process/6.Followthrough.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/6.Followthrough.rst + +.. _sp_development_followthrough: + +Seguimiento +=========== + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst b/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst new file mode 100644 index 000000000000..553759857339 --- /dev/null +++ b/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/7.AdvancedTopics.rst + +.. _sp_development_advancedtopics: + +Temas avanzados +=============== + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/8.Conclusion.rst b/Documentation/translations/sp_SP/process/8.Conclusion.rst new file mode 100644 index 000000000000..dd181cb8ec9a --- /dev/null +++ b/Documentation/translations/sp_SP/process/8.Conclusion.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/8.Conclusion.rst + +.. _sp_development_conclusion: + +Para más información +==================== + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/code-of-conduct.rst b/Documentation/translations/sp_SP/process/code-of-conduct.rst index adc6c770cc37..a6c08613aefc 100644 --- a/Documentation/translations/sp_SP/process/code-of-conduct.rst +++ b/Documentation/translations/sp_SP/process/code-of-conduct.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/code-of-conduct.rst <code_of_conduct>` -:Translator: Contributor Covenant and Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Contributor Covenant and Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_code_of_conduct: diff --git a/Documentation/translations/sp_SP/process/coding-style.rst b/Documentation/translations/sp_SP/process/coding-style.rst index a37274764371..b5a84df44cea 100644 --- a/Documentation/translations/sp_SP/process/coding-style.rst +++ b/Documentation/translations/sp_SP/process/coding-style.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/coding-style.rst <submittingpatches>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_codingstyle: diff --git a/Documentation/translations/sp_SP/process/development-process.rst b/Documentation/translations/sp_SP/process/development-process.rst new file mode 100644 index 000000000000..40d74086f22e --- /dev/null +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -0,0 +1,27 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/development-process.rst +:Translator: Avadhut Naik <avadhut.naik@amd.com> + +.. _sp_development_process_main: + +Guía del proceso de desarrollo del kernel +========================================= + +El propósito de este documento es ayudar a los desarrolladores (y sus +gerentes) a trabajar con la comunidad de desarrollo con un mínimo de +frustración. Es un intento de documentar cómo funciona esta comunidad +de una manera accesible para aquellos que no están familiarizados +íntimamente con el desarrollo del kernel de Linux (o, de hecho, el +desarrollo de software libre en general). Si bien hay algo de material +técnico aquí, este es en gran medida una discusión orientada al proceso +que no requiere un conocimiento profundo de la programación del kernel +para entenderla. + +.. toctree:: + :caption: Contenido + :numbered: + :maxdepth: 2 + + 1.Intro + 2.Process diff --git a/Documentation/translations/sp_SP/process/email-clients.rst b/Documentation/translations/sp_SP/process/email-clients.rst index fdf1e51b84e4..55d5803daf41 100644 --- a/Documentation/translations/sp_SP/process/email-clients.rst +++ b/Documentation/translations/sp_SP/process/email-clients.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/email-clients.rst <email_clients>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_email_clients: diff --git a/Documentation/translations/sp_SP/process/howto.rst b/Documentation/translations/sp_SP/process/howto.rst index dd793c0f8574..72ea855ac9dc 100644 --- a/Documentation/translations/sp_SP/process/howto.rst +++ b/Documentation/translations/sp_SP/process/howto.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/howto.rst <process_howto>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_process_howto: diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst index 2239373b3999..4892159310ff 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -28,3 +28,4 @@ management-style submit-checklist howto + development-process diff --git a/Documentation/translations/sp_SP/process/kernel-docs.rst b/Documentation/translations/sp_SP/process/kernel-docs.rst index 2f9b3df8f8fa..a62c6854f59b 100644 --- a/Documentation/translations/sp_SP/process/kernel-docs.rst +++ b/Documentation/translations/sp_SP/process/kernel-docs.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/kernel-docs.rst <kernel_docs>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_kernel_docs: diff --git a/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst b/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst index d66902694089..d47a1c154610 100644 --- a/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst +++ b/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_process_statement_kernel: diff --git a/Documentation/translations/sp_SP/process/magic-number.rst b/Documentation/translations/sp_SP/process/magic-number.rst index 7c7dfb4ba80b..32a99aac2f6c 100644 --- a/Documentation/translations/sp_SP/process/magic-number.rst +++ b/Documentation/translations/sp_SP/process/magic-number.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_magicnumbers: diff --git a/Documentation/translations/sp_SP/process/programming-language.rst b/Documentation/translations/sp_SP/process/programming-language.rst index 301f525372d8..ba2164057f45 100644 --- a/Documentation/translations/sp_SP/process/programming-language.rst +++ b/Documentation/translations/sp_SP/process/programming-language.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/programming-language.rst <programming_language>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_programming_language: diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rst b/Documentation/translations/sp_SP/process/submitting-patches.rst index c2757d9ab216..328ec80bd61d 100644 --- a/Documentation/translations/sp_SP/process/submitting-patches.rst +++ b/Documentation/translations/sp_SP/process/submitting-patches.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_submittingpatches: @@ -356,6 +356,34 @@ Consulte Documentation/process/email-clients.rst para obtener recomendaciones sobre clientes de correo electrónico y normas de etiqueta en la lista de correo. +.. _sp_interleaved_replies: + +Uso de respuestas intercaladas recortadas en las discusiones por correo electrónico +----------------------------------------------------------------------------------- + +Se desaconseja encarecidamente la publicación en la parte superior de las +discusiones sobre el desarrollo del kernel de Linux. Las respuestas +intercaladas (o "en línea") hacen que las conversaciones sean mucho más +fáciles de seguir. Para obtener más detalles, consulte: +https://en.wikipedia.org/wiki/Posting_style#Interleaved_style + +Como se cita frecuentemente en la lista de correo:: + + A: http://en.wikipedia.org/wiki/Top_post + Q: ¿Dónde puedo encontrar información sobre esto que se llama top-posting? + A: Porque desordena el orden en el que la gente normalmente lee el texto. + Q: ¿Por qué es tan malo el top-posting? + A: Top-posting. + Q: ¿Qué es lo más molesto del correo electrónico? + +Del mismo modo, por favor, recorte todas las citas innecesarias que no +sean relevantes para su respuesta. Esto hace que las respuestas sean más +fáciles de encontrar y ahorra tiempo y espacio. Para obtener más +información, consulte: http://daringfireball.net/2007/07/on_top :: + + A: No. + Q: ¿Debo incluir citas después de mi respuesta? + .. _sp_resend_reminders: No se desanime o impaciente diff --git a/Documentation/translations/zh_CN/core-api/workqueue.rst b/Documentation/translations/zh_CN/core-api/workqueue.rst index 7fac6f75d078..fe0ff5a127f3 100644 --- a/Documentation/translations/zh_CN/core-api/workqueue.rst +++ b/Documentation/translations/zh_CN/core-api/workqueue.rst @@ -7,12 +7,13 @@ 司延腾 Yanteng Si <siyanteng@loongson.cn> 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> + 陈兴友 Xingyou Chen <rockrush@rockwork.org> .. _cn_workqueue.rst: -========================= -并发管理的工作队列 (cmwq) -========================= +======== +工作队列 +======== :日期: September, 2010 :作者: Tejun Heo <tj@kernel.org> @@ -22,7 +23,7 @@ 简介 ==== -在很多情况下，需要一个异步进程的执行环境，工作队列（wq）API是这种情况下 +在很多情况下，需要一个异步的程序执行环境，工作队列（wq）API是这种情况下 最常用的机制。 当需要这样一个异步执行上下文时，一个描述将要执行的函数的工作项（work， @@ -34,8 +35,8 @@ 队列时，工作者又开始执行。 -为什么要cmwq? -============= +为什么要有并发管理工作队列? +=========================== 在最初的wq实现中，多线程（MT）wq在每个CPU上有一个工作者线程，而单线程 （ST）wq在全系统有一个工作者线程。一个MT wq需要保持与CPU数量相同的工 @@ -73,9 +74,11 @@ 向该函数的工作项，并在工作队列中排队等待该工作项。（就是挂到workqueue 队列里面去） -特定目的线程，称为工作线程（工作者），一个接一个地执行队列中的功能。 -如果没有工作项排队，工作者线程就会闲置。这些工作者线程被管理在所谓 -的工作者池中。 +工作项可以在线程或BH(软中断)上下文中执行。 + +对于由线程执行的工作队列，被称为（内核）工作者（[k]worker）的特殊 +线程会依次执行其中的函数。如果没有工作项排队，工作者线程就会闲置。 +这些工作者线程被管理在所谓的工作者池中。 cmwq设计区分了面向用户的工作队列，子系统和驱动程序在上面排队工作， 以及管理工作者池和处理排队工作项的后端机制。 @@ -84,6 +87,10 @@ cmwq设计区分了面向用户的工作队列，子系统和驱动程序在上 优先级的工作项，还有一些额外的工作者池，用于服务未绑定工作队列的工 作项目——这些后备池的数量是动态的。 +BH工作队列使用相同的结构。然而，由于同一时间只可能有一个执行上下文， +不需要担心并发问题。每个CPU上的BH工作者池只包含一个用于表示BH执行 +上下文的虚拟工作者。BH工作队列可以被看作软中断的便捷接口。 + 当他们认为合适的时候，子系统和驱动程序可以通过特殊的 ``workqueue API`` 函数创建和排队工作项。他们可以通过在工作队列上 设置标志来影响工作项执行方式的某些方面，他们把工作项放在那里。这些 @@ -95,9 +102,9 @@ cmwq设计区分了面向用户的工作队列，子系统和驱动程序在上 否则一个绑定的工作队列的工作项将被排在与发起线程运行的CPU相关的普 通或高级工作工作者池的工作项列表中。 -对于任何工作者池的实施，管理并发水平（有多少执行上下文处于活动状 -态）是一个重要问题。最低水平是为了节省资源，而饱和水平是指系统被 -充分使用。 +对于任何线程池的实施，管理并发水平（有多少执行上下文处于活动状 +态）是一个重要问题。cmwq试图将并发保持在一个尽可能低且充足的 +水平。最低水平是为了节省资源，而充足是为了使系统能被充分使用。 每个与实际CPU绑定的worker-pool通过钩住调度器来实现并发管理。每当 一个活动的工作者被唤醒或睡眠时，工作者池就会得到通知，并跟踪当前可 @@ -140,6 +147,17 @@ workqueue将自动创建与属性相匹配的后备工作者池。调节并发 ``flags`` --------- +``WQ_BH`` + BH工作队列可以被看作软中断的便捷接口。它总是每个CPU一份， + 其中的各个工作项也会按在队列中的顺序，被所属CPU在软中断 + 上下文中执行。 + + BH工作队列的 ``max_active`` 值必须为0，且只能单独或和 + ``WQ_HIGHPRI`` 标志组合使用。 + + BH工作项不可以睡眠。像延迟排队、冲洗、取消等所有其他特性 + 都是支持的。 + ``WQ_UNBOUND`` 排队到非绑定wq的工作项由特殊的工作者池提供服务，这些工作者不 绑定在任何特定的CPU上。这使得wq表现得像一个简单的执行环境提 @@ -184,25 +202,21 @@ workqueue将自动创建与属性相匹配的后备工作者池。调节并发 -------------- ``@max_active`` 决定了每个CPU可以分配给wq的工作项的最大执行上 -下文数量。例如，如果 ``@max_active为16`` ，每个CPU最多可以同 -时执行16个wq的工作项。 +下文数量。例如，如果 ``@max_active`` 为16 ，每个CPU最多可以同 +时执行16个wq的工作项。它总是每CPU属性，即便对于未绑定 wq。 -目前，对于一个绑定的wq， ``@max_active`` 的最大限制是512，当指 -定为0时使用的默认值是256。对于非绑定的wq，其限制是512和 -4 * ``num_possible_cpus()`` 中的较高值。这些值被选得足够高，所 -以它们不是限制性因素，同时会在失控情况下提供保护。 +``@max_active`` 的最大限制是512，当指定为0时使用的默认值是256。 +这些值被选得足够高，所以它们不是限制性因素，同时会在失控情况下提供 +保护。 一个wq的活动工作项的数量通常由wq的用户来调节，更具体地说，是由用 户在同一时间可以排列多少个工作项来调节。除非有特定的需求来控制活动 工作项的数量，否则建议指定 为"0"。 -一些用户依赖于ST wq的严格执行顺序。 ``@max_active`` 为1和 ``WQ_UNBOUND`` -的组合用来实现这种行为。这种wq上的工作项目总是被排到未绑定的工作池 -中，并且在任何时候都只有一个工作项目处于活动状态，从而实现与ST wq相 -同的排序属性。 - -在目前的实现中，上述配置只保证了特定NUMA节点内的ST行为。相反， -``alloc_ordered_workqueue()`` 应该被用来实现全系统的ST行为。 +一些用户依赖于任意时刻最多只有一个工作项被执行，且各工作项被按队列中 +顺序处理带来的严格执行顺序。``@max_active`` 为1和 ``WQ_UNBOUND`` +的组合曾被用来实现这种行为，现在不用了。请使用 +``alloc_ordered_workqueue()`` 。 执行场景示例 @@ -285,7 +299,7 @@ And with cmwq with ``@max_active`` >= 3, :: * 除非有特殊需要，建议使用0作为@max_active。在大多数使用情 况下，并发水平通常保持在默认限制之下。 -* 一个wq作为前进进度保证（WQ_MEM_RECLAIM，冲洗（flush）和工 +* 一个wq作为前进进度保证，``WQ_MEM_RECLAIM`` ，冲洗（flush）和工 作项属性的域。不涉及内存回收的工作项，不需要作为工作项组的一 部分被刷新，也不需要任何特殊属性，可以使用系统中的一个wq。使 用专用wq和系统wq在执行特性上没有区别。 @@ -294,6 +308,337 @@ And with cmwq with ``@max_active`` >= 3, :: 益的，因为wq操作和工作项执行中的定位水平提高了。 +亲和性作用域 +============ + +一个非绑定工作队列根据其亲和性作用域来对CPU进行分组以提高缓存 +局部性。比如如果一个工作队列使用默认的“cache”亲和性作用域， +它将根据最后一级缓存的边界来分组处理器。这个工作队列上的工作项 +将被分配给一个与发起CPU共用最后级缓存的处理器上的工作者。根据 +``affinity_strict`` 的设置，工作者在启动后可能被允许移出 +所在作用域，也可能不被允许。 + +工作队列目前支持以下亲和性作用域。 + +``default`` + 使用模块参数 ``workqueue.default_affinity_scope`` 指定 + 的作用域，该参数总是会被设为以下作用域中的一个。 + +``cpu`` + CPU不被分组。一个CPU上发起的工作项会被同一CPU上的工作者执行。 + 这使非绑定工作队列表现得像是不含并发管理的每CPU工作队列。 + +``smt`` + CPU被按SMT边界分组。这通常意味着每个物理CPU核上的各逻辑CPU会 + 被分进同一组。 + +``cache`` + CPU被按缓存边界分组。采用哪个缓存边界由架构代码决定。很多情况 + 下会使用L3。这是默认的亲和性作用域。 + +``numa`` + CPU被按NUMA边界分组。 + +``system`` + 所有CPU被放在同一组。工作队列不尝试在临近发起CPU的CPU上运行 + 工作项。 + +默认的亲和性作用域可以被模块参数 ``workqueue.default_affinity_scope`` +修改，特定工作队列的亲和性作用域可以通过 ``apply_workqueue_attrs()`` +被更改。 + +如果设置了 ``WQ_SYSFS`` ，工作队列会在它的 ``/sys/devices/virtual/workqueue/WQ_NAME/`` +目录中有以下亲和性作用域相关的接口文件。 + +``affinity_scope`` + 读操作以查看当前的亲和性作用域。写操作用于更改设置。 + + 当前作用域是默认值时，当前生效的作用域也可以被从这个文件中 + 读到（小括号内），例如 ``default (cache)`` 。 + +``affinity_strict`` + 默认值0表明亲和性作用域不是严格的。当一个工作项开始执行时， + 工作队列尽量尝试使工作者处于亲和性作用域内，称为遣返。启动后， + 调度器可以自由地将工作者调度到系统中任意它认为合适的地方去。 + 这使得在保留使用其他CPU（如果必需且有可用）能力的同时， + 还能从作用域局部性上获益。 + + 如果设置为1，作用域内的所有工作者将被保证总是处于作用域内。 + 这在跨亲和性作用域会导致如功耗、负载隔离等方面的潜在影响时 + 会有用。严格的NUMA作用域也可用于和旧版内核中工作队列的行为 + 保持一致。 + + +亲和性作用域与性能 +================== + +如果非绑定工作队列的行为对绝大多数使用场景来说都是最优的， +不需要更多调节，就完美了。很不幸，在当前内核中，重度使用 +工作队列时，需要在局部性和利用率间显式地作一个明显的权衡。 + +更高的局部性带来更高效率，也就是相同数量的CPU周期内可以做 +更多工作。然而，如果发起者没能将工作项充分地分散在亲和性 +作用域间，更高的局部性也可能带来更低的整体系统利用率。以下 +dm-crypt 的性能测试清楚地阐明了这一取舍。 + +测试运行在一个12核24线程、4个L3缓存的处理器（AMD Ryzen +9 3900x）上。为保持一致性，关闭CPU超频。 ``/dev/dm-0`` +是NVME SSD（三星 990 PRO）上创建，用 ``cryptsetup`` +以默认配置打开的一个 dm-crypt 设备。 + + +场景 1: 机器上遍布着有充足的发起者和工作量 +------------------------------------------ + +使用命令：:: + + $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k --ioengine=libaio \ + --iodepth=64 --runtime=60 --numjobs=24 --time_based --group_reporting \ + --name=iops-test-job --verify=sha512 + +这里有24个发起者，每个同时发起64个IO。 ``--verify=sha512`` +使得 ``fio`` 每次生成和读回内容受发起者和 ``kcryptd`` +间的执行局部性影响。下面是基于不同 ``kcryptd`` 的亲和性 +作用域设置，各经过五次测试得到的读取带宽和CPU利用率数据。 + +.. list-table:: + :widths: 16 20 20 + :header-rows: 1 + + * - 亲和性 + - 带宽 (MiBps) + - CPU利用率（%） + + * - system + - 1159.40 ±1.34 + - 99.31 ±0.02 + + * - cache + - 1166.40 ±0.89 + - 99.34 ±0.01 + + * - cache (strict) + - 1166.00 ±0.71 + - 99.35 ±0.01 + +在系统中分布着足够多发起者的情况下，不论严格与否，“cache” +没有表现得更差。三种配置均使整个机器达到饱和，但由于提高了 +局部性，缓存相关的两种有0.6%的（带宽）提升。 + + +场景 2: 更少发起者，足以达到饱和的工作量 +---------------------------------------- + +使用命令：:: + + $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \ + --ioengine=libaio --iodepth=64 --runtime=60 --numjobs=8 \ + --time_based --group_reporting --name=iops-test-job --verify=sha512 + +与上一个场景唯一的区别是 ``--numjobs=8``。 发起者数量 +减少为三分之一，但仍然有足以使系统达到饱和的工作总量。 + +.. list-table:: + :widths: 16 20 20 + :header-rows: 1 + + * - 亲和性 + - 带宽 (MiBps) + - CPU利用率（%） + + * - system + - 1155.40 ±0.89 + - 97.41 ±0.05 + + * - cache + - 1154.40 ±1.14 + - 96.15 ±0.09 + + * - cache (strict) + - 1112.00 ±4.64 + - 93.26 ±0.35 + +这里有超过使系统达到饱和所需的工作量。“system”和“cache” +都接近但并未使机器完全饱和。“cache”消耗更少的CPU但更高的 +效率使其得到和“system”相同的带宽。 + +八个发起者盘桓在四个L3缓存作用域间仍然允许“cache (strict)” +几乎使机器饱和，但缺少对工作的保持（不移到空闲处理器上） +开始带来3.7%的带宽损失。 + + +场景 3: 更少发起者，不充足的工作量 +---------------------------------- + +使用命令：:: + + $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \ + --ioengine=libaio --iodepth=64 --runtime=60 --numjobs=4 \ + --time_based --group_reporting --name=iops-test-job --verify=sha512 + +再次，唯一的区别是 ``--numjobs=4``。由于发起者减少到四个， +现在没有足以使系统饱和的工作量，带宽变得依赖于完成时延。 + +.. list-table:: + :widths: 16 20 20 + :header-rows: 1 + + * - 亲和性 + - 带宽 (MiBps) + - CPU利用率（%） + + * - system + - 993.60 ±1.82 + - 75.49 ±0.06 + + * - cache + - 973.40 ±1.52 + - 74.90 ±0.07 + + * - cache (strict) + - 828.20 ±4.49 + - 66.84 ±0.29 + +现在，局部性和利用率间的权衡更清晰了。“cache”展示出相比 +“system”2%的带宽损失，而“cache (strict)”跌到20%。 + + +结论和建议 +---------- + +在以上试验中，虽然一致并且也明显，但“cache”亲和性作用域 +相比“system”的性能优势并不大。然而，这影响是依赖于作用域 +间距离的，在更复杂的处理器拓扑下可能有更明显的影响。 + +虽然这些情形下缺少工作保持是有坏处的，但比“cache (strict)” +好多了，而且最大化工作队列利用率的需求也并不常见。因此， +“cache”是非绑定池的默认亲和性作用域。 + +* 由于不存在一个适用于大多数场景的选择，对于可能需要消耗 + 大量CPU的工作队列，建议通过 ``apply_workqueue_attrs()`` + 进行（专门）配置，并考虑是否启用 ``WQ_SYSFS``。 + +* 设置了严格“cpu”亲和性作用域的非绑定工作队列，它的行为与 + ``WQ_CPU_INTENSIVE`` 每CPU工作队列一样。后者没有真正 + 优势，而前者提供了大幅度的灵活性。 + +* 亲和性作用域是从Linux v6.5起引入的。为了模拟旧版行为， + 可以使用严格的“numa”亲和性作用域。 + +* 不严格的亲和性作用域中，缺少工作保持大概缘于调度器。内核 + 为什么没能维护好大多数场景下的工作保持，把事情作对，还没有 + 理论上的解释。因此，未来调度器的改进可能会使我们不再需要 + 这些调节项。 + + +检查配置 +======== + +使用 tools/workqueue/wq_dump.py（drgn脚本） 来检查未 +绑定CPU的亲和性配置，工作者池，以及工作队列如何映射到池上: :: + + $ tools/workqueue/wq_dump.py + Affinity Scopes + =============== + wq_unbound_cpumask=0000000f + + CPU + nr_pods 4 + pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008 + pod_node [0]=0 [1]=0 [2]=1 [3]=1 + cpu_pod [0]=0 [1]=1 [2]=2 [3]=3 + + SMT + nr_pods 4 + pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008 + pod_node [0]=0 [1]=0 [2]=1 [3]=1 + cpu_pod [0]=0 [1]=1 [2]=2 [3]=3 + + CACHE (default) + nr_pods 2 + pod_cpus [0]=00000003 [1]=0000000c + pod_node [0]=0 [1]=1 + cpu_pod [0]=0 [1]=0 [2]=1 [3]=1 + + NUMA + nr_pods 2 + pod_cpus [0]=00000003 [1]=0000000c + pod_node [0]=0 [1]=1 + cpu_pod [0]=0 [1]=0 [2]=1 [3]=1 + + SYSTEM + nr_pods 1 + pod_cpus [0]=0000000f + pod_node [0]=-1 + cpu_pod [0]=0 [1]=0 [2]=0 [3]=0 + + Worker Pools + ============ + pool[00] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 0 + pool[01] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 0 + pool[02] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 1 + pool[03] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 1 + pool[04] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 2 + pool[05] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 2 + pool[06] ref= 1 nice= 0 idle/workers= 3/ 3 cpu= 3 + pool[07] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 3 + pool[08] ref=42 nice= 0 idle/workers= 6/ 6 cpus=0000000f + pool[09] ref=28 nice= 0 idle/workers= 3/ 3 cpus=00000003 + pool[10] ref=28 nice= 0 idle/workers= 17/ 17 cpus=0000000c + pool[11] ref= 1 nice=-20 idle/workers= 1/ 1 cpus=0000000f + pool[12] ref= 2 nice=-20 idle/workers= 1/ 1 cpus=00000003 + pool[13] ref= 2 nice=-20 idle/workers= 1/ 1 cpus=0000000c + + Workqueue CPU -> pool + ===================== + [ workqueue \ CPU 0 1 2 3 dfl] + events percpu 0 2 4 6 + events_highpri percpu 1 3 5 7 + events_long percpu 0 2 4 6 + events_unbound unbound 9 9 10 10 8 + events_freezable percpu 0 2 4 6 + events_power_efficient percpu 0 2 4 6 + events_freezable_power_ percpu 0 2 4 6 + rcu_gp percpu 0 2 4 6 + rcu_par_gp percpu 0 2 4 6 + slub_flushwq percpu 0 2 4 6 + netns ordered 8 8 8 8 8 + ... + +参见命令的帮助消息以获取更多信息。 + + +监视 +==== + +使用 tools/workqueue/wq_monitor.py 来监视工作队列的运行： :: + + $ tools/workqueue/wq_monitor.py events + total infl CPUtime CPUhog CMW/RPR mayday rescued + events 18545 0 6.1 0 5 - - + events_highpri 8 0 0.0 0 0 - - + events_long 3 0 0.0 0 0 - - + events_unbound 38306 0 0.1 - 7 - - + events_freezable 0 0 0.0 0 0 - - + events_power_efficient 29598 0 0.2 0 0 - - + events_freezable_power_ 10 0 0.0 0 0 - - + sock_diag_events 0 0 0.0 0 0 - - + + total infl CPUtime CPUhog CMW/RPR mayday rescued + events 18548 0 6.1 0 5 - - + events_highpri 8 0 0.0 0 0 - - + events_long 3 0 0.0 0 0 - - + events_unbound 38322 0 0.1 - 7 - - + events_freezable 0 0 0.0 0 0 - - + events_power_efficient 29603 0 0.2 0 0 - - + events_freezable_power_ 10 0 0.0 0 0 - - + sock_diag_events 0 0 0.0 0 0 - - + + ... + +参见命令的帮助消息以获取更多信息。 + + 调试 ==== @@ -330,7 +675,6 @@ And with cmwq with ``@max_active`` >= 3, :: 工作队列保证，如果在工作项排队后满足以下条件，则工作项不能重入： - 1. 工作函数没有被改变。 2. 没有人将该工作项排到另一个工作队列中。 3. 该工作项尚未被重新启动。 diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst index c2db3e566b1b..fa900f5beb68 100644 --- a/Documentation/translations/zh_CN/dev-tools/index.rst +++ b/Documentation/translations/zh_CN/dev-tools/index.rst @@ -22,14 +22,14 @@ Documentation/translations/zh_CN/dev-tools/testing-overview.rst sparse gcov kasan + kcov + ubsan + kmemleak gdb-kernel-debugging Todolist: - coccinelle - - kcov - - ubsan - - kmemleak - kcsan - kfence - kgdb diff --git a/Documentation/translations/zh_CN/dev-tools/kcov.rst b/Documentation/translations/zh_CN/dev-tools/kcov.rst new file mode 100644 index 000000000000..629154df7121 --- /dev/null +++ b/Documentation/translations/zh_CN/dev-tools/kcov.rst @@ -0,0 +1,359 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/dev-tools/kcov.rst +:Translator: 刘浩阳 Haoyang Liu <tttturtleruss@hust.edu.cn> + +KCOV: 用于模糊测试的代码覆盖率 +============================== + +KCOV 以一种适用于覆盖率引导的模糊测试的形式收集和暴露内核代码覆盖率信息。 +一个正在运行的内核的覆盖率数据可以通过 ``kcov`` 调试文件导出。覆盖率的收集是基 +于任务启用的，因此 KCOV 可以精确捕获单个系统调用的覆盖率。 + +要注意的是 KCOV 不是为了收集尽可能多的覆盖率数据。而是为了收集相对稳定的覆盖率 +，这是系统调用输入的函数。为了完成这个目标，它不收集软硬中断的覆盖率（除非移除 +覆盖率收集被启用，见下文）以及内核中固有的不确定部分的覆盖率（如调度器，锁定） + +除了收集代码覆盖率，KCOV 还收集操作数比较的覆盖率。见 "操作数比较收集" 一节 +查看详细信息。 + +除了从系统调用处理器收集覆盖率数据，KCOV 还从后台内核或软中断任务中执行的内核 +被标注的部分收集覆盖率。见 "远程覆盖率收集" 一节查看详细信息。 + +先决条件 +-------- + +KCOV 依赖编译器插桩，要求 GCC 6.1.0 及更高版本或者内核支持的任意版本的 Clang。 + +收集操作数比较的覆盖率需要 GCC 8+ 或者 Clang。 + +为了启用 KCOV，需要使用如下参数配置内核:: + + CONFIG_KCOV=y + +为了启用操作数比较覆盖率的收集，使用如下参数:: + + CONFIG_KCOV_ENABLE_COMPARISONS=y + +覆盖率数据只会在调试文件系统被挂载后才可以获取:: + + mount -t debugfs none /sys/kernel/debug + +覆盖率收集 +---------- + +下面的程序演示了如何使用 KCOV 在一个测试程序中收集单个系统调用的覆盖率： + +.. code-block:: c + + #include <stdio.h> + #include <stddef.h> + #include <stdint.h> + #include <stdlib.h> + #include <sys/types.h> + #include <sys/stat.h> + #include <sys/ioctl.h> + #include <sys/mman.h> + #include <unistd.h> + #include <fcntl.h> + #include <linux/types.h> + + #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) + #define KCOV_ENABLE _IO('c', 100) + #define KCOV_DISABLE _IO('c', 101) + #define COVER_SIZE (64<<10) + + #define KCOV_TRACE_PC 0 + #define KCOV_TRACE_CMP 1 + + int main(int argc, char **argv) + { + int fd; + unsigned long *cover, n, i; + + /* 单个文件描述符允许 + * 在单线程上收集覆盖率。 + */ + fd = open("/sys/kernel/debug/kcov", O_RDWR); + if (fd == -1) + perror("open"), exit(1); + /* 设置跟踪模式和跟踪大小。 */ + if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE)) + perror("ioctl"), exit(1); + /* 映射内核空间和用户空间共享的缓冲区。 */ + cover = (unsigned long*)mmap(NULL, COVER_SIZE * sizeof(unsigned long), + PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); + if ((void*)cover == MAP_FAILED) + perror("mmap"), exit(1); + /* 在当前线程中启用覆盖率收集。 */ + if (ioctl(fd, KCOV_ENABLE, KCOV_TRACE_PC)) + perror("ioctl"), exit(1); + /* 在调用 ioctl() 之后重置覆盖率。 */ + __atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED); + /* 调用目标系统调用。 */ + read(-1, NULL, 0); + /* 读取收集到的 PC 的数目。 */ + n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED); + for (i = 0; i < n; i++) + printf("0x%lx\n", cover[i + 1]); + /* 在当前线程上禁用覆盖率收集。在这之后 + * 可以在其他线程上收集覆盖率 + */ + if (ioctl(fd, KCOV_DISABLE, 0)) + perror("ioctl"), exit(1); + /* 释放资源 */ + if (munmap(cover, COVER_SIZE * sizeof(unsigned long))) + perror("munmap"), exit(1); + if (close(fd)) + perror("close"), exit(1); + return 0; + } + +在使用 ``addr2line`` 传输后，程序输出应该如下所示:: + + SyS_read + fs/read_write.c:562 + __fdget_pos + fs/file.c:774 + __fget_light + fs/file.c:746 + __fget_light + fs/file.c:750 + __fget_light + fs/file.c:760 + __fdget_pos + fs/file.c:784 + SyS_read + fs/read_write.c:562 + +如果一个程序需要从多个线程收集覆盖率（独立地）。那么每个线程都需要单独打开 +``/sys/kernel/debug/kcov``。 + +接口的细粒度允许高效的创建测试进程。即，一个父进程打开了 +``/sys/kernel/debug/kcov``，启用了追踪模式，映射了覆盖率缓冲区，然后在一个循 +环中创建了子进程。这个子进程只需要启用覆盖率收集即可（当一个线程退出时将自动禁 +用覆盖率收集）。 + +操作数比较收集 +-------------- + +操作数比较收集和覆盖率收集类似： + +.. code-block:: c + + /* 包含和上文一样的头文件和宏定义。 */ + + /* 每次记录的 64 位字的数量。 */ + #define KCOV_WORDS_PER_CMP 4 + + /* + * 收集的比较种类的格式。 + * + * 0 比特表示是否是一个编译时常量。 + * 1 & 2 比特包含参数大小的 log2 值，最大 8 字节。 + */ + + #define KCOV_CMP_CONST (1 << 0) + #define KCOV_CMP_SIZE(n) ((n) << 1) + #define KCOV_CMP_MASK KCOV_CMP_SIZE(3) + + int main(int argc, char **argv) + { + int fd; + uint64_t *cover, type, arg1, arg2, is_const, size; + unsigned long n, i; + + fd = open("/sys/kernel/debug/kcov", O_RDWR); + if (fd == -1) + perror("open"), exit(1); + if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE)) + perror("ioctl"), exit(1); + /* + * 注意缓冲区指针的类型是 uint64_t*，因为所有的 + * 比较操作数都被提升为 uint64_t 类型。 + */ + cover = (uint64_t *)mmap(NULL, COVER_SIZE * sizeof(unsigned long), + PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); + if ((void*)cover == MAP_FAILED) + perror("mmap"), exit(1); + /* 注意这里是 KCOV_TRACE_CMP 而不是 KCOV_TRACE_PC。 */ + if (ioctl(fd, KCOV_ENABLE, KCOV_TRACE_CMP)) + perror("ioctl"), exit(1); + __atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED); + read(-1, NULL, 0); + /* 读取收集到的比较操作数的数量。 */ + n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED); + for (i = 0; i < n; i++) { + uint64_t ip; + + type = cover[i * KCOV_WORDS_PER_CMP + 1]; + /* arg1 和 arg2 - 比较的两个操作数。 */ + arg1 = cover[i * KCOV_WORDS_PER_CMP + 2]; + arg2 = cover[i * KCOV_WORDS_PER_CMP + 3]; + /* ip - 调用者的地址。 */ + ip = cover[i * KCOV_WORDS_PER_CMP + 4]; + /* 操作数的大小。 */ + size = 1 << ((type & KCOV_CMP_MASK) >> 1); + /* is_const - 当操作数是一个编译时常量时为真。*/ + is_const = type & KCOV_CMP_CONST; + printf("ip: 0x%lx type: 0x%lx, arg1: 0x%lx, arg2: 0x%lx, " + "size: %lu, %s\n", + ip, type, arg1, arg2, size, + is_const ? "const" : "non-const"); + } + if (ioctl(fd, KCOV_DISABLE, 0)) + perror("ioctl"), exit(1); + /* 释放资源。 */ + if (munmap(cover, COVER_SIZE * sizeof(unsigned long))) + perror("munmap"), exit(1); + if (close(fd)) + perror("close"), exit(1); + return 0; + } + +注意 KCOV 的模式（代码覆盖率收集或操作数比较收集）是互斥的。 + +远程覆盖率收集 +-------------- + +除了从用户空间进程发布的系统调用句柄收集覆盖率数据以外，KCOV 也可以从部分在其 +他上下文中执行的内核中收集覆盖率 - 称为“远程”覆盖率。 + +使用 KCOV 收集远程覆盖率要求： + +1. 修改内核源码并使用 ``kcov_remote_start`` 和 ``kcov_remote_stop`` 来标注要收集 + 覆盖率的代码片段。 + +2. 在用户空间的收集覆盖率的进程应使用 ``KCOV_REMOTE_ENABLE`` 而不是 ``KCOV_ENABLE``。 + +``kcov_remote_start`` 和 ``kcov_remote_stop`` 的标注以及 ``KCOV_REMOTE_ENABLE`` +ioctl 都接受可以识别特定覆盖率收集片段的句柄。句柄的使用方式取决于匹配代码片段执 +行的上下文。 + +KCOV 支持在如下上下文中收集远程覆盖率： + +1. 全局内核后台任务。这些任务是内核启动时创建的数量有限的实例（如，每一个 + USB HCD 产生一个 USB ``hub_event`` 工作器）。 + +2. 局部内核后台任务。这些任务通常是由于用户空间进程与某些内核接口进行交互时产 + 生的，并且通常在进程退出时会被停止（如，vhost 工作器）。 + +3. 软中断。 + +对于 #1 和 #3，必须选择一个独特的全局句柄并将其传递给对应的 +``kcov_remote_start`` 调用。一个用户空间进程必须将该句柄存储在 +``kcov_remote_arg`` 结构体的 ``handle`` 数组字段中并将其传递给 +``KCOV_REMOTE_ENABLE``。这会将使用的 KCOV 设备附加到由此句柄引用的代码片段。多个全局 +句柄标识的不同代码片段可以一次性传递。 + +对于 #2，用户空间进程必须通过 ``kcov_remote_arg`` 结构体的 ``common_handle`` 字段 +传递一个非零句柄。这个通用句柄将会被保存在当前 ``task_struct`` 结构体的 +``kcov_handle`` 字段中并且需要通过自定义内核代码的修改来传递给新创建的本地任务 +。这些任务需要在 ``kcov_remote_start`` 和 ``kcov_remote_stop`` 标注中依次使用传递过来的 +句柄。 + +KCOV 对全局句柄和通用句柄均遵循一个预定义的格式。每一个句柄都是一个 ``u64`` 整形 +。当前，只有最高位和低四位字节被使用。第 4-7 字节是保留位并且值必须为 0。 + +对于全局句柄，最高位的字节表示该句柄属于的子系统的标识。比如，KCOV 使用 ``1`` +表示 USB 子系统类型。全局句柄的低 4 字节表示子系统中任务实例的标识。比如，每一 +个 ``hub_event`` 工作器使用 USB 总线号作为任务实例的标识。 + +对于通用句柄，使用一个保留值 ``0`` 作为子系统标识，因为这些句柄不属于一个特定 +的子系统。通用句柄的低 4 字节用于识别有用户进程生成的所有本地句柄的集合实例， +该进程将通用句柄传递给 ``KCOV_REMOTE_ENABLE``。 + +实际上，如果只从系统中的单个用户空间进程收集覆盖率，那么可以使用任意值作为通用 +句柄的实例标识。然而，如果通用句柄被多个用户空间进程使用，每个进程必须使用唯一 +的实例标识。一个选择是使用进程标识作为通用句柄实例的标识。 + +下面的程序演示了如何使用 KCOV 从一个由进程产生的本地任务和处理 USB 总线的全局 +任务 #1 收集覆盖率： + +.. code-block:: c + + /* 包含和上文一样的头文件和宏定义。 */ + + struct kcov_remote_arg { + __u32 trace_mode; + __u32 area_size; + __u32 num_handles; + __aligned_u64 common_handle; + __aligned_u64 handles[0]; + }; + + #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) + #define KCOV_DISABLE _IO('c', 101) + #define KCOV_REMOTE_ENABLE _IOW('c', 102, struct kcov_remote_arg) + + #define COVER_SIZE (64 << 10) + + #define KCOV_TRACE_PC 0 + + #define KCOV_SUBSYSTEM_COMMON (0x00ull << 56) + #define KCOV_SUBSYSTEM_USB (0x01ull << 56) + + #define KCOV_SUBSYSTEM_MASK (0xffull << 56) + #define KCOV_INSTANCE_MASK (0xffffffffull) + + static inline __u64 kcov_remote_handle(__u64 subsys, __u64 inst) + { + if (subsys & ~KCOV_SUBSYSTEM_MASK || inst & ~KCOV_INSTANCE_MASK) + return 0; + return subsys | inst; + } + + #define KCOV_COMMON_ID 0x42 + #define KCOV_USB_BUS_NUM 1 + + int main(int argc, char **argv) + { + int fd; + unsigned long *cover, n, i; + struct kcov_remote_arg *arg; + + fd = open("/sys/kernel/debug/kcov", O_RDWR); + if (fd == -1) + perror("open"), exit(1); + if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE)) + perror("ioctl"), exit(1); + cover = (unsigned long*)mmap(NULL, COVER_SIZE * sizeof(unsigned long), + PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); + if ((void*)cover == MAP_FAILED) + perror("mmap"), exit(1); + + /* 通过通用句柄和 USB 总线 #1 启用代码覆盖率收集。 */ + arg = calloc(1, sizeof(*arg) + sizeof(uint64_t)); + if (!arg) + perror("calloc"), exit(1); + arg->trace_mode = KCOV_TRACE_PC; + arg->area_size = COVER_SIZE; + arg->num_handles = 1; + arg->common_handle = kcov_remote_handle(KCOV_SUBSYSTEM_COMMON, + KCOV_COMMON_ID); + arg->handles[0] = kcov_remote_handle(KCOV_SUBSYSTEM_USB, + KCOV_USB_BUS_NUM); + if (ioctl(fd, KCOV_REMOTE_ENABLE, arg)) + perror("ioctl"), free(arg), exit(1); + free(arg); + + /* + * 在这里用户需要触发执行一个内核代码段 + * 该代码段要么使用通用句柄标识 + * 要么触发了一些 USB 总线 #1 上的一些活动。 + */ + sleep(2); + + n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED); + for (i = 0; i < n; i++) + printf("0x%lx\n", cover[i + 1]); + if (ioctl(fd, KCOV_DISABLE, 0)) + perror("ioctl"), exit(1); + if (munmap(cover, COVER_SIZE * sizeof(unsigned long))) + perror("munmap"), exit(1); + if (close(fd)) + perror("close"), exit(1); + return 0; + } diff --git a/Documentation/translations/zh_CN/dev-tools/kmemleak.rst b/Documentation/translations/zh_CN/dev-tools/kmemleak.rst new file mode 100644 index 000000000000..d248c8428095 --- /dev/null +++ b/Documentation/translations/zh_CN/dev-tools/kmemleak.rst @@ -0,0 +1,229 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/dev-tools/kmemleak.rst +:Translator: 刘浩阳 Haoyang Liu <tttturtleruss@hust.edu.cn> + +内核内存泄露检测器 +================== + +Kmemleak 提供了一个类似 `可追踪的垃圾收集器 <https://en.wikipedia.org/wiki/Tra +cing_garbage_collection>`_ 的方法来检测可能的内核内存泄漏，不同的是孤立对象不会 +被释放，而是仅通过 /sys/kernel/debug/kmemleak 报告。Valgrind 工具 +（``memcheck --leak-check``）使用了一种相似的方法来检测用户空间应用中的内存泄 +露。 + +用法 +---- + +"Kernel hacking" 中的 CONFIG_DEBUG_KMEMLEAK 必须被启用。一个内核线程每10分钟 +（默认情况下）扫描一次内存，并且打印出新发现的未被引用的对象个数。 +如果 ``debugfs`` 没有挂载，则执行:: + + # mount -t debugfs nodev /sys/kernel/debug/ + +显示所有扫描出的可能的内存泄漏的细节信息:: + + # cat /sys/kernel/debug/kmemleak + +启动一次中等程度的内存扫描:: + + # echo scan > /sys/kernel/debug/kmemleak + +清空当前所有可能的内存泄露列表:: + + # echo clear > /sys/kernel/debug/kmemleak + +当再次读取 ``/sys/kernel/debug/kmemleak`` 文件时，将会输出自上次扫描以来检测到的 +新的内存泄露。 + +注意，孤立目标是通过被分配时间来排序的，列表开始的对象可能会导致后续的对象都被 +识别为孤立对象。 + +可以通过写入 ``/sys/kernel/debug/kmemleak`` 文件在运行时修改内存扫描参数。下面是 +支持的参数： + + +* off + 禁用 kmemleak（不可逆） +* stack=on + 开启任务栈扫描（默认） +* stack=off + 禁用任务栈扫描 +* scan=on + 开启自动内存扫描线程（默认） +* scan=off + 关闭自动内存扫描线程 +* scan=<secs>; + 设定自动内存扫描间隔，以秒为单位（默认值为 600，设置为 0 表示停 + 止自动扫描） +* scan + 触发一次内存扫描 +* clear + 通过标记所有当前已报告的未被引用对象为灰，从而清空当前可能的内存泄露列 + 表；如果 kmemleak 被禁用，则释放所有 kmemleak 对象，。 +* dump=<addr> + 输出存储在 <addr> 中的对象信息 + +可以通过在内核命令行中传递 ``kmemleak=off`` 参数从而在启动时禁用 Kmemleak。 + +在 kmemleak 初始化之前就可能会有内存分配或释放，这些操作被存储在一个早期日志缓 +冲区中。缓冲区的大小通过 CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE 选项配置。 + +如果 CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF 被启用，则 kmemleak 默认被禁用。在内核命 +令行中传递 ``kmemleak=on`` 参数来开启这个功能。 + +如果出现 "Error while writing to stdout" 或 "write_loop: Invalid argument" 这样 +的错误，请确认 kmemleak 被正确启用。 + +基础算法 +-------- + +通过 :c:func:`kmalloc`, :c:func:`vmalloc`, :c:func:`kmem_cache_alloc` 以及同类 +函数均被跟踪，指针，包括一些额外的信息如大小和栈追踪等，都被存储在红黑树中。 +对应的释放函数调用也被追踪，并从 kmemleak 数据结构中移除相应指针。 + +对于一个已分配的内存块，如果通过扫描内存（包括保存寄存器）没有发现任何指针指向 +它的起始地址或者其中的任何位置，则认为这块内存是孤立的。这意味着内核无法将该内 +存块的地址传递给一个释放内存函数，这块内存便被认为泄露了。 + +扫描算法步骤： + + 1. 标记所有对象为白色（最后剩下的白色对象被认为是孤立的） + 2. 从数据节和栈开始扫描内存，检测每个值是否是红黑树中存储的地址。如果一个指向 + 白色对象的指针被检测到，则将该对象标记为灰色。 + 3. 扫描灰色对象引用的其他对象（有些白色对象可能会变为灰色并被添加到灰名单末尾 + ）直到灰名单为空。 + 4. 剩余的白色对象就被认为是孤立的并通过 /sys/kernel/debug/kmemleak 报告。 + +有些指向已分配的内存块的指针存储在内核内部的数据结构中，它们不能被检测为孤立。 +为了避免这种情况，kmemleak 也存储了指向需要被查找的内存块范围内的任意地址的地址 +数量，如此一来这些内存便不会被认为泄露。一个例子是 __vmalloc()。 + +用 kmemleak 测试特定部分 +------------------------ + +在初始化启动阶段 /sys/kernel/debug/kmemleak 的输出可能会很多，这也可能是你在开发 +时编写的漏洞百出的代码导致的。为了解决这种情况你可以使用 'clear' 命令来清除 +/sys/kernel/debug/kmemleak 输出的所有的未引用对象。在执行 'clear' 后执行 'scan' +可以发现新的未引用对象，这将会有利你测试代码的特定部分。 + +为了用一个空的 kmemleak 测试一个特定部分，执行:: + + # echo clear > /sys/kernel/debug/kmemleak + ... 测试你的内核或者模块 ... + # echo scan > /sys/kernel/debug/kmemleak + +然后像平常一样获得报告:: + + # cat /sys/kernel/debug/kmemleak + +释放 kmemleak 内核对象 +---------------------- + +为了允许访问先前发现的内存泄露，当用户禁用或发生致命错误导致 kmemleak +被禁用时，内核中的 kmemleak 对象不会被释放。这些对象可能会占用很大 +一部分物理内存。 + +在这种情况下，你可以用如下命令回收这些内存:: + + # echo clear > /sys/kernel/debug/kmemleak + +Kmemleak API +------------ + +在 include/linux/kmemleak.h 头文件中查看函数原型： + +- ``kmemleak_init`` - 初始化 kmemleak +- ``kmemleak_alloc`` - 通知一个内存块的分配 +- ``kmemleak_alloc_percpu`` - 通知一个 percpu 类型的内存分配 +- ``kmemleak_vmalloc`` - 通知一个使用 vmalloc() 的内存分配 +- ``kmemleak_free`` - 通知一个内存块的释放 +- ``kmemleak_free_part`` - 通知一个部分的内存释放 +- ``kmemleak_free_percpu`` - 通知一个 percpu 类型的内存释放 +- ``kmemleak_update_trace`` - 更新分配对象过程的栈追踪 +- ``kmemleak_not_leak`` - 标记一个对象内存为未泄露的 +- ``kmemleak_ignore`` - 不要扫描或报告某个对象未泄露的 +- ``kmemleak_scan_area`` - 在内存块中添加扫描区域 +- ``kmemleak_no_scan`` - 不扫描某个内存块 +- ``kmemleak_erase`` - 在指针变量中移除某个旧的值 +- ``kmemleak_alloc_recursive`` - 和 kmemleak_alloc 效果相同但会检查是否有递归的 + 内存分配 +- ``kmemleak_free_recursive`` - 和 kmemleak_free 效果相同但会检查是否有递归的 + 内存释放 + +下列函数使用一个物理地址作为对象指针并且只在地址有一个 lowmem 映射时做出相应的 +行为： + +- ``kmemleak_alloc_phys`` +- ``kmemleak_free_part_phys`` +- ``kmemleak_ignore_phys`` + +解决假阳性/假阴性 +----------------- + +假阴性是指由于在内存扫描中有值指向该对象导致 kmemleak 没有报告的实际存在的内存 +泄露（孤立对象）。为了减少假阴性的出现次数，kmemleak 提供了 kmemleak_ignore， +kmemleak_scan_area，kmemleak_no_scan 和 kmemleak_erase 函数（见上）。 +任务栈也会增加假阴性的数量并且默认不开启对它们的扫描。 + +假阳性是对象被误报为内存泄露（孤立对象）。对于已知未泄露的对象，kmemleak +提供了 kmemleak_not_leak 函数。同时 kmemleak_ignore 可以用于标记已知不包含任何 +其他指针的内存块，标记后该内存块不会再被扫描。 + +一些被报告的泄露仅仅是暂时的，尤其是在 SMP（对称多处理）系统中，因为其指针 +暂存在 CPU 寄存器或栈中。Kmemleak 定义了 MSECS_MIN_AGE（默认值为 1000） +来表示一个被报告为内存泄露的对象的最小存活时间。 + +限制和缺点 +---------- + +主要的缺点是内存分配和释放的性能下降。为了避免其他的损失，只有当 +/sys/kernel/debug/kmemleak 文件被读取时才会进行内存扫描。无论如何，这个工具是出于 +调试的目标，性能表现可能不是最重要的。 + +为了保持算法简单，kmemleak 寻找指向某个内存块范围中的任何值。这可能会引发假阴性 +现象的出现。但是，最后一个真正的内存泄露也会变得明显。 + +非指针值的数据是假阴性的另一个来源。在将来的版本中，kmemleak 仅仅会扫 +描已分配结构体中的指针成员。这个特性会解决上述很多的假阴性情况。 + +Kmemleak 会报告假阳性。这可能发生在某些被分配的内存块不需要被释放的情况下 +（某些 init_call 函数中），指针的计算是通过其他方法而不是常规的 container_of 宏 +或是指针被存储在 kmemleak 没有扫描的地方。 + +页分配和 ioremap 不会被追踪。 + +使用 kmemleak-test 测试 +----------------------- + +为了检测是否成功启用了 kmemleak，你可以使用一个故意制造内存泄露的模块 +kmemleak-test。设置 CONFIG_SAMPLE_KMEMLEAK 为模块（不能作为内建模块使用） +并且启动启用了 kmemleak 的内核。加载模块并执行一次扫描:: + + # modprobe kmemleak-test + # echo scan > /sys/kernel/debug/kmemleak + +注意你可能无法立刻或在第一次扫描后得到结果。当 kmemleak 得到结果，将会输出日 +志 ``kmemleak: <count of leaks> new suspected memory leaks`` 。然后通过读取文件 +获取信息:: + + # cat /sys/kernel/debug/kmemleak + unreferenced object 0xffff89862ca702e8 (size 32): + comm "modprobe", pid 2088, jiffies 4294680594 (age 375.486s) + hex dump (first 32 bytes): + 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk + 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk. + backtrace: + [<00000000e0a73ec7>] 0xffffffffc01d2036 + [<000000000c5d2a46>] do_one_initcall+0x41/0x1df + [<0000000046db7e0a>] do_init_module+0x55/0x200 + [<00000000542b9814>] load_module+0x203c/0x2480 + [<00000000c2850256>] __do_sys_finit_module+0xba/0xe0 + [<000000006564e7ef>] do_syscall_64+0x43/0x110 + [<000000007c873fa6>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 + ... + +用 ``rmmod kmemleak_test`` 移除模块时也会触发 +kmemleak 的结果输出。 diff --git a/Documentation/translations/zh_CN/dev-tools/ubsan.rst b/Documentation/translations/zh_CN/dev-tools/ubsan.rst new file mode 100644 index 000000000000..2487696b3772 --- /dev/null +++ b/Documentation/translations/zh_CN/dev-tools/ubsan.rst @@ -0,0 +1,91 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/dev-tools/ubsan.rst +:Translator: Dongliang Mu <dzm91@hust.edu.cn> + +未定义行为消毒剂 - UBSAN +==================================== + +UBSAN是一种动态未定义行为检查工具。 + +UBSAN使用编译时插桩捕捉未定义行为。编译器在可能导致未定义行为的操作前插入特定 +检测代码。如果检查失败，即检测到未定义行为，__ubsan_handle_* 函数将被调用打印 +错误信息。 + +GCC自4.9.x [1_] （详见 ``-fsanitize=undefined`` 选项及其子选项）版本后引入这 +一特性。GCC 5.x 版本实现了更多检查器 [2_]。 + +报告样例 +-------------- + +:: + + ================================================================================ + UBSAN: Undefined behaviour in ../include/linux/bitops.h:110:33 + shift exponent 32 is to large for 32-bit type 'unsigned int' + CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-rc1+ #26 + 0000000000000000 ffffffff82403cc8 ffffffff815e6cd6 0000000000000001 + ffffffff82403cf8 ffffffff82403ce0 ffffffff8163a5ed 0000000000000020 + ffffffff82403d78 ffffffff8163ac2b ffffffff815f0001 0000000000000002 + Call Trace: + [<ffffffff815e6cd6>] dump_stack+0x45/0x5f + [<ffffffff8163a5ed>] ubsan_epilogue+0xd/0x40 + [<ffffffff8163ac2b>] __ubsan_handle_shift_out_of_bounds+0xeb/0x130 + [<ffffffff815f0001>] ? radix_tree_gang_lookup_slot+0x51/0x150 + [<ffffffff8173c586>] _mix_pool_bytes+0x1e6/0x480 + [<ffffffff83105653>] ? dmi_walk_early+0x48/0x5c + [<ffffffff8173c881>] add_device_randomness+0x61/0x130 + [<ffffffff83105b35>] ? dmi_save_one_device+0xaa/0xaa + [<ffffffff83105653>] dmi_walk_early+0x48/0x5c + [<ffffffff831066ae>] dmi_scan_machine+0x278/0x4b4 + [<ffffffff8111d58a>] ? vprintk_default+0x1a/0x20 + [<ffffffff830ad120>] ? early_idt_handler_array+0x120/0x120 + [<ffffffff830b2240>] setup_arch+0x405/0xc2c + [<ffffffff830ad120>] ? early_idt_handler_array+0x120/0x120 + [<ffffffff830ae053>] start_kernel+0x83/0x49a + [<ffffffff830ad120>] ? early_idt_handler_array+0x120/0x120 + [<ffffffff830ad386>] x86_64_start_reservations+0x2a/0x2c + [<ffffffff830ad4f3>] x86_64_start_kernel+0x16b/0x17a + ================================================================================ + +用法 +----- + +使用如下内核配置启用UBSAN:: + + CONFIG_UBSAN=y + +使用如下内核配置检查整个内核:: + + CONFIG_UBSAN_SANITIZE_ALL=y + +为了在特定文件或目录启动代码插桩，需要在相应的内核Makefile中添加一行类似内容: + +- 单文件（如main.o）:: + + UBSAN_SANITIZE_main.o := y + +- 一个目录中的所有文件:: + + UBSAN_SANITIZE := y + +即使设置了``CONFIG_UBSAN_SANITIZE_ALL=y``，为了避免文件被插桩，可使用:: + + UBSAN_SANITIZE_main.o := n + +与:: + + UBSAN_SANITIZE := n + +未对齐的内存访问检测可通过开启独立选项 - CONFIG_UBSAN_ALIGNMENT 检测。 +该选项在支持未对齐访问的架构上(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y) +默认为关闭。该选项仍可通过内核配置启用，但它将产生大量的UBSAN报告。 + +参考文献 +---------- + +.. _1: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html +.. _2: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html +.. _3: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html diff --git a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst index aeccff777170..0faf042001d2 100644 --- a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst +++ b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst @@ -208,8 +208,6 @@ GPIO 值的命令需要等待其信息排到队首才发送命令，再获得其 gpio_request() ## gpio_request_one() - ## gpio_request_array() - ## gpio_free_array() gpio_free() @@ -272,14 +270,6 @@ gpio_request()前将这类细节配置好，例如使用引脚控制子系统的 */ int gpio_request_one(unsigned gpio, unsigned long flags, const char *label); - /* 在单个函数中申请多个 GPIO - */ - int gpio_request_array(struct gpio *array, size_t num); - - /* 在单个函数中释放多个 GPIO - */ - void gpio_free_array(struct gpio *array, size_t num); - 这里 'flags' 当前定义可指定以下属性: * GPIOF_DIR_IN - 配置方向为输入 @@ -317,12 +307,6 @@ gpio_request()前将这类细节配置好，例如使用引脚控制子系统的 if (err) ... - err = gpio_request_array(leds_gpios, ARRAY_SIZE(leds_gpios)); - if (err) - ... - - gpio_free_array(leds_gpios, ARRAY_SIZE(leds_gpios)); - GPIO 映射到 IRQ ---------------- diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 6ccec9657cc6..20b9d4270d1f 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -24,8 +24,8 @@ 上的linux-doc邮件列表。 顺便说下，中文文档也需要遵守内核编码风格，风格中中文和英文的主要不同就是中文 -的字符标点占用两个英文字符宽度， 所以，当英文要求不要超过每行100个字符时， -中文就不要超过50个字符。另外，也要注意'-'，'=' 等符号与相关标题的对齐。在将 +的字符标点占用两个英文字符宽度，所以，当英文要求不要超过每行100个字符时， +中文就不要超过50个字符。另外，也要注意'-'，'='等符号与相关标题的对齐。在将 补丁提交到社区之前，一定要进行必要的 ``checkpatch.pl`` 检查和编译测试。 与Linux 内核社区一起工作 diff --git a/Documentation/translations/zh_CN/mm/page_frags.rst b/Documentation/translations/zh_CN/mm/page_frags.rst index 20bd3fafdc8c..a5b22486a913 100644 --- a/Documentation/translations/zh_CN/mm/page_frags.rst +++ b/Documentation/translations/zh_CN/mm/page_frags.rst @@ -25,7 +25,7 @@ sk_buff->head使用，或者用于skb_shared_info的 “frags” 部分。 网络堆栈在每个CPU使用两个独立的缓存来处理碎片分配。netdev_alloc_cache被使用 netdev_alloc_frag和__netdev_alloc_skb调用的调用者使用。napi_alloc_cache -被调用__napi_alloc_frag和__napi_alloc_skb的调用者使用。这两个调用的主要区别是 +被调用__napi_alloc_frag和napi_alloc_skb的调用者使用。这两个调用的主要区别是 它们可能被调用的环境。“netdev” 前缀的函数可以在任何上下文中使用，因为这些函数 将禁用中断，而 ”napi“ 前缀的函数只可以在softirq上下文中使用。 diff --git a/Documentation/translations/zh_CN/process/cve.rst b/Documentation/translations/zh_CN/process/cve.rst new file mode 100644 index 000000000000..e39b796efcec --- /dev/null +++ b/Documentation/translations/zh_CN/process/cve.rst @@ -0,0 +1,89 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/process/cve.rst +:Translator: Dongliang Mu <dzm91@hust.edu.cn> + +==== +CVEs +==== + +Common Vulnerabilities and Exposure (CVE®) 编号是一种明确的方式来 +识别、定义和登记公开披露的安全漏洞。随着时间的推移，它们在内核项目中的实用性 +已经下降，CVE编号经常以不适当的方式和不适当的原因被分配。因此，内核开发社区 +倾向于避免使用它们。然而，分配CVE与其他形式的安全标识符的持续压力，以及内核 +社区之外的个人和公司的持续滥用，已经清楚地表明内核社区应该控制这些CVE分配。 + +Linux内核开发团队确实有能力为潜在的Linux内核安全问题分配CVE。CVE的分配 +独立于 :doc:`安全漏洞报送流程</process/security-bugs>`。 + +所有分配给Linux内核的CVE列表都可以在linux-cve邮件列表的存档中找到，如 +https://lore.kernel.org/linux-cve-announce/ 所示。如果想获得已分配 +CVE的通知，请“订阅”该邮件列表。要获得分配的CVE通知，请订阅该邮件列表： +`订阅 <https://subspace.kernel.org/subscribing.html>`_。 + +过程 +======= + +作为正常稳定发布过程的一部分，可能存在安全问题的内核更改由负责CVE编号分配 +的开发人员识别，并自动为其分配CVE编号。这些CVE分配会作为经常性的通告经常 +发布在linux-cve-announce邮件列表上。 + +注意，由于Linux内核在系统中的特殊地位，几乎任何漏洞都可能被利用来危害内核 +的安全性，但是当漏洞被修复后，利用的可能性通常不明显。因此，CVE分配团队过于 +谨慎，并将CVE编号分配给他们识别的任何漏洞修复。这就解释了为什么Linux内核 +团队会发布大量的CVE。 + +如果CVE分配团队错过了任何用户认为应该分配CVE的特定修复，请发送电子邮件到 +<cve@kernel.org>，那里的团队将与您一起工作。请注意，任何潜在的安全问题 +不应被发送到此邮箱，它仅用于为已发布的内核树中的漏洞修复分配CVE。如果你觉得 +自己发现了一个未修复的安全问题，请按照 :doc:`安全漏洞报送流程 +</process/security-bugs>` 发送到Linux内核社区。 + +Linux内核不会给未修复的安全问题自动分配CVE；只有在安全修复可用且应用于 +稳定内核树后，CVE分配才会自动发生，并且它将通过安全修复的Git提交编号进行 +跟踪。如果有人希望在提交安全修复之前分配CVE，请联系内核CVE分配团队，从 +他们的一批保留编号中获得相应的CVE编号。 + +对于目前没有得到稳定与长期维护内核团队积极支持的内核版本中发现的任何问题， +都不会分配CVEs。当前支持的内核分支列表可以在 https://kernel.org/releases.html +上找到。 + +被分配CVE的争论 +========================= + +对于为特定内核修改分配的CVE，其争论或修改的权限仅属于受影响子系统的维护者。 +这一原则确保了漏洞报告的高度准确性和可问责性。只有那些具有深厚专业知识和 +对子系统深入了解的维护人员，才能有效评估内核漏洞的有效性和范围，并确定其适当的 +CVE指定策略。在此指定权限之外，任何争论或修改CVE的尝试都可能导致混乱、 +不准确的报告，并最终危及系统。 + +无效的CVE +============ + +如果发现的安全问题存在于仅由某Linux发行版支持的Linux内核中，即安全问题是 +由于Linux发行版所做的更改导致，或者Linux的发行版内核版本不再是Linux内核 +社区支持的内核版本，那么Linux内核CVE团队将不能分配CVE，必须从Linux +发行版本身请求。 + +内核CVE分配团队以外的任何团队对Linux内核支持版本分配的CVE都不应被 +视为有效CVE。请通知内核CVE分配团队，以便他们可以通过CNA修复措施使 +这些条目失效。 + +特定CVE的适用性 +============================== + +由于Linux内核可以以许多不同方式使用，外部用户可以通过许多不同方式访问它，或者 +根本没有访问，因此任何特定CVE的适用性取决于Linux用户，而不是内核CVE分配团队。 +请不要与我们联系来尝试确定任何特定CVE的适用性。 + +此外，由于源代码树非常大，而任何一个系统都只使用源代码树的一小部分，因此任何 +Linux用户都应该意识到，大量分配的CVEs与他们的系统无关。 + +简而言之，我们不知道您的用例，也不知道您使用的是内核的哪个部分，因此我们无法 +确定特定的CVE是否与您的系统相关。 + +与往常一样，最好采用所有发布的内核更改，因为它们是由许多社区成员在一个统一的 +整体中一起进行测试的，而不是作为个别的精选更改。还要注意，对于许多安全问题来 +说，整体问题的解决方案并不是在单个更改中找到的，而是在彼此之上的许多修复的总 +和。理想情况下，CVE将被分配给所有问题的所有修复，但有时我们将无法注意到一些 +修复，因此某些修复可能在没有CVE的情况下被采取。 diff --git a/Documentation/translations/zh_CN/process/index.rst b/Documentation/translations/zh_CN/process/index.rst index 3ca02d281be0..5c6c8ccdd50d 100644 --- a/Documentation/translations/zh_CN/process/index.rst +++ b/Documentation/translations/zh_CN/process/index.rst @@ -48,6 +48,7 @@ TODOLIST: :maxdepth: 1 embargoed-hardware-issues + cve TODOLIST: diff --git a/Documentation/translations/zh_CN/process/submitting-patches.rst b/Documentation/translations/zh_CN/process/submitting-patches.rst index f8978f02057c..7864107e60a8 100644 --- a/Documentation/translations/zh_CN/process/submitting-patches.rst +++ b/Documentation/translations/zh_CN/process/submitting-patches.rst @@ -333,10 +333,10 @@ Linus 和其他的内核开发者需要阅读和评论你提交的改动。对 未参与其开发。签署链应当反映补丁传播到维护者并最终传播到Linus所经过的 **真实** 路径，首个签署指明单个作者的主要作者身份。 -何时使用Acked-by:，CC:，和Co-Developed by: +何时使用Acked-by:，Cc:，和Co-developed-by: ------------------------------------------ -Singed-off-by: 标签表示签名者参与了补丁的开发，或者他/她在补丁的传递路径中。 +Signed-off-by: 标签表示签名者参与了补丁的开发，或者他/她在补丁的传递路径中。 如果一个人没有直接参与补丁的准备或处理，但希望表示并记录他们对补丁的批准/赞成， 那么他们可以要求在补丁的变更日志中添加一个Acked-by:。 @@ -358,8 +358,8 @@ Acked-by：不一定表示对整个补丁的确认。例如，如果一个补丁 Co-developed-by: 声明补丁是由多个开发人员共同创建的；当几个人在一个补丁上工 作时，它用于给出共同作者（除了From:所给出的作者之外）。因为Co-developed-by: 表示作者身份，所以每个Co-developed-by:必须紧跟在相关合作作者的签署之后。标准 -签署程序要求Singed-off-by:标签的顺序应尽可能反映补丁的时间历史，无论作者是通 -过From:还是Co-developed-by:表明。值得注意的是，最后一个Singed-off-by:必须是 +签署程序要求Signed-off-by:标签的顺序应尽可能反映补丁的时间历史，无论作者是通 +过From:还是Co-developed-by:表明。值得注意的是，最后一个Signed-off-by:必须是 提交补丁的开发人员。 注意，如果From:作者也是电子邮件标题的From:行中列出的人，则From:标签是可选的。 diff --git a/Documentation/translations/zh_CN/rust/arch-support.rst b/Documentation/translations/zh_CN/rust/arch-support.rst index afbd02afec45..abd708d48f82 100644 --- a/Documentation/translations/zh_CN/rust/arch-support.rst +++ b/Documentation/translations/zh_CN/rust/arch-support.rst @@ -16,8 +16,12 @@ 下面是目前可以工作的架构的一般总结。支持程度与 ``MAINTAINERS`` 文件中的``S`` 值相对应: -============ ================ ============================================== -架构 支持水平 限制因素 -============ ================ ============================================== -``x86`` Maintained 只有 ``x86_64`` -============ ================ ============================================== +============= ================ ============================================== +架构 支持水平 限制因素 +============= ================ ============================================== +``arm64`` Maintained 只有小端序 +``loongarch`` Maintained \- +``riscv`` Maintained 只有 ``riscv64`` +``um`` Maintained 只有 ``x86_64`` +``x86`` Maintained 只有 ``x86_64`` +============= ================ ============================================== diff --git a/Documentation/translations/zh_CN/rust/coding-guidelines.rst b/Documentation/translations/zh_CN/rust/coding-guidelines.rst index 6c0bdbbc5a2a..419143b938ed 100644 --- a/Documentation/translations/zh_CN/rust/coding-guidelines.rst +++ b/Documentation/translations/zh_CN/rust/coding-guidelines.rst @@ -157,6 +157,18 @@ https://commonmark.org/help/ https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html +此外，内核支持通过在链接目标前添加 ``srctree/`` 来创建相对于源代码树的链接。例如: + +.. code-block:: rust + + //! C header: [`include/linux/printk.h`](srctree/include/linux/printk.h) + +或者: + +.. code-block:: rust + + /// [`struct mutex`]: srctree/include/linux/mutex.h + 命名 ---- diff --git a/Documentation/translations/zh_CN/rust/general-information.rst b/Documentation/translations/zh_CN/rust/general-information.rst index 6b91dfe1834a..251f6ee2bb44 100644 --- a/Documentation/translations/zh_CN/rust/general-information.rst +++ b/Documentation/translations/zh_CN/rust/general-information.rst @@ -32,7 +32,7 @@ Rust内核代码使用其内置的文档生成器 ``rustdoc`` 进行记录。 要在你的网络浏览器中本地阅读该文档，请运行如:: - xdg-open rust/doc/kernel/index.html + xdg-open Documentation/output/rust/rustdoc/kernel/index.html 要了解如何编写文档，请看 coding-guidelines.rst 。 diff --git a/Documentation/translations/zh_CN/rust/quick-start.rst b/Documentation/translations/zh_CN/rust/quick-start.rst index a4b8e8a50a89..8616556ae4d7 100644 --- a/Documentation/translations/zh_CN/rust/quick-start.rst +++ b/Documentation/translations/zh_CN/rust/quick-start.rst @@ -37,13 +37,18 @@ rustc 需要一个特定版本的Rust编译器。较新的版本可能会也可能不会工作，因为就目前而言，内核依赖 于一些不稳定的Rust特性。 -如果使用的是 ``rustup`` ，请进入检出的源代码目录并运行:: +如果使用的是 ``rustup`` ，请进入内核编译目录（或者用 ``--path=<build-dir>`` 参数 +来 ``设置`` sub-command)并运行:: rustup override set $(scripts/min-tool-version.sh rustc) -或者从以下网址获取一个独立的安装程序或安装 ``rustup`` ： ++这将配置你的工作目录使用正确版本的 ``rustc``，而不影响你的默认工具链。 - https://www.rust-lang.org +请注意覆盖应用当前的工作目录（和它的子目录）。 + +如果你使用 ``rustup``， 可以从下面的链接拉取一个单独的安装程序: + + https://forge.rust-lang.org/infra/other-installation-methods.html#standalone Rust标准库源代码 @@ -57,21 +62,23 @@ Rust标准库的源代码是必需的，因为构建系统会交叉编译 ``core 这些组件是按工具链安装的，因此以后升级Rust编译器版本需要重新添加组件。 -否则，如果使用独立的安装程序，可以将Rust仓库克隆到工具链的安装文件夹中:: +否则，如果使用独立的安装程序，可以将Rust源码树下载到安装工具链的文件夹中:: - git clone --recurse-submodules \ - --branch $(scripts/min-tool-version.sh rustc) \ - https://github.com/rust-lang/rust \ - $(rustc --print sysroot)/lib/rustlib/src/rust + curl -L "https://static.rust-lang.org/dist/rust-src-$(scripts/min-tool-version.sh rustc).tar.gz" | + tar -xzf - -C "$(rustc --print sysroot)/lib" \ + "rust-src-$(scripts/min-tool-version.sh rustc)/rust-src/lib/" \ + --strip-components=3 -在这种情况下，以后升级Rust编译器版本需要手动更新这个克隆的仓库。 +在这种情况下，以后升级Rust编译器版本需要手动更新这个源代码树（这可以通过移除 +``$(rustc --print sysroot)/lib/rustlib/src/rust`` ，然后重新执行上 +面的命令做到）。 libclang ******** ``bindgen`` 使用 ``libclang`` （LLVM的一部分）来理解内核中的C代码，这意味着需要安 -装LLVM；同在开启 ``CC=clang`` 或 ``LLVM=1`` 时编译内核一样。 +装LLVM；同在开启``LLVM=1`` 时编译内核一样。 Linux发行版中可能会有合适的包，所以最好先检查一下。 @@ -94,7 +101,20 @@ bindgen 通过以下方式安装它（注意，这将从源码下载并构建该工具）:: - cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen + cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen-cli + +``bindgen`` 需要找到合适的 ``libclang`` 才能工作。如果没有找到（或者找到的 +``libclang`` 与应该使用的 ``libclang`` 不同），则可以使用 ``clang-sys`` +理解的环境变量（Rust绑定创建的 ``bindgen`` 用来访问 ``libclang``）: + + +* ``LLVM_CONFIG_PATH`` 可以指向一个 ``llvm-config`` 可执行文件。 + +* 或者 ``LIBCLANG_PATH`` 可以指向 ``libclang`` 共享库或包含它的目录。 + +* 或者 ``CLANG_PATH`` 可以指向 ``clang`` 可执行文件。 + +详情请参阅 ``clang-sys`` 的文档: 开发依赖 @@ -163,7 +183,9 @@ rust-analyzer 一起使用，以实现语法高亮、补全、转到定义和其他功能。 ``rust-analyzer`` 需要一个配置文件， ``rust-project.json``, 它可以由 ``rust-analyzer`` -Make 目标生成。 +Make 目标生成:: + + make LLVM=1 rust-analyzer 配置 @@ -189,10 +211,6 @@ Rust支持（CONFIG_RUST）需要在 ``General setup`` 菜单中启用。在其 make LLVM=1 -对于不支持完整LLVM工具链的架构，使用:: - - make CC=clang - 使用GCC对某些配置也是可行的，但目前它是非常试验性的。 diff --git a/Documentation/translations/zh_CN/scheduler/sched-domains.rst b/Documentation/translations/zh_CN/scheduler/sched-domains.rst index e814d4c01141..06363169c56b 100644 --- a/Documentation/translations/zh_CN/scheduler/sched-domains.rst +++ b/Documentation/translations/zh_CN/scheduler/sched-domains.rst @@ -34,17 +34,17 @@ CPU共享。任意两个组的CPU掩码的交集不一定为空，如果是这 调度域中的负载均衡发生在调度组中。也就是说，每个组被视为一个实体。组的负载被定义为它 管辖的每个CPU的负载之和。仅当组的负载不均衡后，任务才在组之间发生迁移。 -在kernel/sched/core.c中，trigger_load_balance()在每个CPU上通过scheduler_tick() +在kernel/sched/core.c中，sched_balance_trigger()在每个CPU上通过sched_tick() 周期执行。在当前运行队列下一个定期调度再平衡事件到达后，它引发一个软中断。负载均衡真正 -的工作由run_rebalance_domains()->rebalance_domains()完成，在软中断上下文中执行 +的工作由sched_balance_softirq()->sched_balance_domains()完成，在软中断上下文中执行 （SCHED_SOFTIRQ）。 -后一个函数有两个入参：当前CPU的运行队列、它在scheduler_tick()调用时是否空闲。函数会从 +后一个函数有两个入参：当前CPU的运行队列、它在sched_tick()调用时是否空闲。函数会从 当前CPU所在的基调度域开始迭代执行，并沿着parent指针链向上进入更高层级的调度域。在迭代 过程中，函数会检查当前调度域是否已经耗尽了再平衡的时间间隔，如果是，它在该调度域运行 -load_balance()。接下来它检查父调度域（如果存在），再后来父调度域的父调度域，以此类推。 +sched_balance_rq()。接下来它检查父调度域（如果存在），再后来父调度域的父调度域，以此类推。 -起初，load_balance()查找当前调度域中最繁忙的调度组。如果成功，在该调度组管辖的全部CPU +起初，sched_balance_rq()查找当前调度域中最繁忙的调度组。如果成功，在该调度组管辖的全部CPU 的运行队列中找出最繁忙的运行队列。如能找到，对当前的CPU运行队列和新找到的最繁忙运行 队列均加锁，并把任务从最繁忙队列中迁移到当前CPU上。被迁移的任务数量等于在先前迭代执行 中计算出的该调度域的调度组的不均衡值。 diff --git a/Documentation/translations/zh_CN/scheduler/sched-stats.rst b/Documentation/translations/zh_CN/scheduler/sched-stats.rst index c5e0be663837..09eee2517610 100644 --- a/Documentation/translations/zh_CN/scheduler/sched-stats.rst +++ b/Documentation/translations/zh_CN/scheduler/sched-stats.rst @@ -75,42 +75,42 @@ domain<N> <cpumask> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 繁忙，新空闲）： - 1) 当CPU空闲时，load_balance()在这个调度域中被调用了#次 - 2) 当CPU空闲时，load_balance()在这个调度域中被调用，但是发现负载无需 + 1) 当CPU空闲时，sched_balance_rq()在这个调度域中被调用了#次 + 2) 当CPU空闲时，sched_balance_rq()在这个调度域中被调用，但是发现负载无需 均衡#次 - 3) 当CPU空闲时，load_balance()在这个调度域中被调用，试图迁移1个或更多 + 3) 当CPU空闲时，sched_balance_rq()在这个调度域中被调用，试图迁移1个或更多 任务且失败了#次 - 4) 当CPU空闲时，load_balance()在这个调度域中被调用，发现不均衡（如果有） + 4) 当CPU空闲时，sched_balance_rq()在这个调度域中被调用，发现不均衡（如果有） #次 5) 当CPU空闲时，pull_task()在这个调度域中被调用#次 6) 当CPU空闲时，尽管目标任务是热缓存状态，pull_task()依然被调用#次 - 7) 当CPU空闲时，load_balance()在这个调度域中被调用，未能找到更繁忙的 + 7) 当CPU空闲时，sched_balance_rq()在这个调度域中被调用，未能找到更繁忙的 队列#次 8) 当CPU空闲时，在调度域中找到了更繁忙的队列，但未找到更繁忙的调度组 #次 - 9) 当CPU繁忙时，load_balance()在这个调度域中被调用了#次 - 10) 当CPU繁忙时，load_balance()在这个调度域中被调用，但是发现负载无需 + 9) 当CPU繁忙时，sched_balance_rq()在这个调度域中被调用了#次 + 10) 当CPU繁忙时，sched_balance_rq()在这个调度域中被调用，但是发现负载无需 均衡#次 - 11) 当CPU繁忙时，load_balance()在这个调度域中被调用，试图迁移1个或更多 + 11) 当CPU繁忙时，sched_balance_rq()在这个调度域中被调用，试图迁移1个或更多 任务且失败了#次 - 12) 当CPU繁忙时，load_balance()在这个调度域中被调用，发现不均衡（如果有） + 12) 当CPU繁忙时，sched_balance_rq()在这个调度域中被调用，发现不均衡（如果有） #次 13) 当CPU繁忙时，pull_task()在这个调度域中被调用#次 14) 当CPU繁忙时，尽管目标任务是热缓存状态，pull_task()依然被调用#次 - 15) 当CPU繁忙时，load_balance()在这个调度域中被调用，未能找到更繁忙的 + 15) 当CPU繁忙时，sched_balance_rq()在这个调度域中被调用，未能找到更繁忙的 队列#次 16) 当CPU繁忙时，在调度域中找到了更繁忙的队列，但未找到更繁忙的调度组 #次 - 17) 当CPU新空闲时，load_balance()在这个调度域中被调用了#次 - 18) 当CPU新空闲时，load_balance()在这个调度域中被调用，但是发现负载无需 + 17) 当CPU新空闲时，sched_balance_rq()在这个调度域中被调用了#次 + 18) 当CPU新空闲时，sched_balance_rq()在这个调度域中被调用，但是发现负载无需 均衡#次 - 19) 当CPU新空闲时，load_balance()在这个调度域中被调用，试图迁移1个或更多 + 19) 当CPU新空闲时，sched_balance_rq()在这个调度域中被调用，试图迁移1个或更多 任务且失败了#次 - 20) 当CPU新空闲时，load_balance()在这个调度域中被调用，发现不均衡（如果有） + 20) 当CPU新空闲时，sched_balance_rq()在这个调度域中被调用，发现不均衡（如果有） #次 21) 当CPU新空闲时，pull_task()在这个调度域中被调用#次 22) 当CPU新空闲时，尽管目标任务是热缓存状态，pull_task()依然被调用#次 - 23) 当CPU新空闲时，load_balance()在这个调度域中被调用，未能找到更繁忙的 + 23) 当CPU新空闲时，sched_balance_rq()在这个调度域中被调用，未能找到更繁忙的 队列#次 24) 当CPU新空闲时，在调度域中找到了更繁忙的队列，但未找到更繁忙的调度组 #次 diff --git a/Documentation/translations/zh_TW/gpio.txt b/Documentation/translations/zh_TW/gpio.txt index b9b48012c62e..77d69d381316 100644 --- a/Documentation/translations/zh_TW/gpio.txt +++ b/Documentation/translations/zh_TW/gpio.txt @@ -215,13 +215,10 @@ GPIO 值的命令需要等待其信息排到隊首才發送命令，再獲得其 gpio_request() ## gpio_request_one() -## gpio_request_array() -## gpio_free_array() gpio_free() - 聲明和釋放 GPIO ---------------------------- 爲了有助於捕獲系統配置錯誤,定義了兩個函數。 @@ -278,14 +275,6 @@ gpio_request()前將這類細節配置好，例如使用 pinctrl 子系統的映 */ int gpio_request_one(unsigned gpio, unsigned long flags, const char *label); - /* 在單個函數中申請多個 GPIO - */ - int gpio_request_array(struct gpio *array, size_t num); - - /* 在單個函數中釋放多個 GPIO - */ - void gpio_free_array(struct gpio *array, size_t num); - 這裡 'flags' 當前定義可指定以下屬性: * GPIOF_DIR_IN - 配置方向爲輸入 @@ -323,12 +312,6 @@ gpio_request()前將這類細節配置好，例如使用 pinctrl 子系統的映 if (err) ... - err = gpio_request_array(leds_gpios, ARRAY_SIZE(leds_gpios)); - if (err) - ... - - gpio_free_array(leds_gpios, ARRAY_SIZE(leds_gpios)); - GPIO 映射到 IRQ -------------------- diff --git a/Documentation/translations/zh_TW/process/submit-checklist.rst b/Documentation/translations/zh_TW/process/submit-checklist.rst index 43f2e3c5b514..0ecb187753e4 100644 --- a/Documentation/translations/zh_TW/process/submit-checklist.rst +++ b/Documentation/translations/zh_TW/process/submit-checklist.rst @@ -31,7 +31,7 @@ Linux內核補丁提交檢查單 c) 使用 ``O=builddir`` 時可以成功編譯 - d) 任何 Doucmentation/ 下的變更都能成功構建且不引入新警告/錯誤。 + d) 任何 Documentation/ 下的變更都能成功構建且不引入新警告/錯誤。 用 ``make htmldocs`` 或 ``make pdfdocs`` 檢驗構建情況並修復問題。 3) 通過使用本地交叉編譯工具或其他一些構建設施在多個CPU體系結構上構建。 diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst index 99fa0f2fe6f4..f12f2f193f85 100644 --- a/Documentation/translations/zh_TW/process/submitting-patches.rst +++ b/Documentation/translations/zh_TW/process/submitting-patches.rst @@ -334,10 +334,10 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對 未參與其開發。簽署鏈應當反映補丁傳播到維護者並最終傳播到Linus所經過的 **真實** 路徑，首個簽署指明單個作者的主要作者身份。 -何時使用Acked-by:，CC:，和Co-Developed by: +何時使用Acked-by:，Cc:，和Co-developed-by: ------------------------------------------ -Singed-off-by: 標籤表示簽名者參與了補丁的開發，或者他/她在補丁的傳遞路徑中。 +Signed-off-by: 標籤表示簽名者參與了補丁的開發，或者他/她在補丁的傳遞路徑中。 如果一個人沒有直接參與補丁的準備或處理，但希望表示並記錄他們對補丁的批准/贊成， 那麼他們可以要求在補丁的變更日誌中添加一個Acked-by:。 @@ -359,8 +359,8 @@ Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁 Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個人在一個補丁上工 作時，它用於給出共同作者（除了From:所給出的作者之外）。因爲Co-developed-by: 表示作者身份，所以每個Co-developed-by:必須緊跟在相關合作作者的簽署之後。標準 -簽署程序要求Singed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通 -過From:還是Co-developed-by:表明。值得注意的是，最後一個Singed-off-by:必須是 +簽署程序要求Signed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通 +過From:還是Co-developed-by:表明。值得注意的是，最後一個Signed-off-by:必須是 提交補丁的開發人員。 注意，如果From:作者也是電子郵件標題的From:行中列出的人，則From:標籤是可選的。 diff --git a/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst b/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst index 56b975801b6a..6615d6ced755 100644 --- a/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst +++ b/Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst @@ -81,7 +81,7 @@ Only one event clock flag, ``GPIO_V2_LINE_FLAG_EVENT_CLOCK_xxx``, may be set. If none are set then the event clock defaults to ``CLOCK_MONOTONIC``. The ``GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE`` flag requires supporting hardware and a kernel with ``CONFIG_HTE`` set. Requesting HTE from a device that -doesn't support it is an error (**EOPNOTSUP**). +doesn't support it is an error (**EOPNOTSUPP**). The :c:type:`debounce_period_us<gpio_v2_line_attribute>` attribute may only be applied to lines with ``GPIO_V2_LINE_FLAG_INPUT`` set. When set, debounce diff --git a/Documentation/userspace-api/netlink/genetlink-legacy.rst b/Documentation/userspace-api/netlink/genetlink-legacy.rst index 70a77387f6c4..fa005989193a 100644 --- a/Documentation/userspace-api/netlink/genetlink-legacy.rst +++ b/Documentation/userspace-api/netlink/genetlink-legacy.rst @@ -46,10 +46,16 @@ For reference the ``multi-attr`` array may look like this:: where ``ARRAY-ATTR`` is the array entry type. -array-nest -~~~~~~~~~~ +indexed-array +~~~~~~~~~~~~~ + +``indexed-array`` wraps the entire array in an extra attribute (hence +limiting its size to 64kB). The ``ENTRY`` nests are special and have the +index of the entry as their type instead of normal attribute type. -``array-nest`` creates the following structure:: +A ``sub-type`` is needed to describe what type in the ``ENTRY``. A ``nest`` +``sub-type`` means there are nest arrays in the ``ENTRY``, with the structure +looks like:: [SOME-OTHER-ATTR] [ARRAY-ATTR] @@ -60,9 +66,13 @@ array-nest [MEMBER1] [MEMBER2] -It wraps the entire array in an extra attribute (hence limiting its size -to 64kB). The ``ENTRY`` nests are special and have the index of the entry -as their type instead of normal attribute type. +Other ``sub-type`` like ``u32`` means there is only one member as described +in ``sub-type`` in the ``ENTRY``. The structure looks like:: + + [SOME-OTHER-ATTR] + [ARRAY-ATTR] + [ENTRY u32] + [ENTRY u32] type-value ~~~~~~~~~~ diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 0b5a33ee71ee..8c29b5167c63 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6316,7 +6316,7 @@ The "flags" field is reserved for future extensions and must be '0'. :Architectures: none :Type: vm ioctl :Parameters: struct kvm_create_guest_memfd(in) -:Returns: 0 on success, <0 on error +:Returns: A file descriptor on success, <0 on error KVM_CREATE_GUEST_MEMFD creates an anonymous file and returns a file descriptor that refers to it. guest_memfd files are roughly analogous to files created @@ -6894,6 +6894,13 @@ Note that KVM does not skip the faulting instruction as it does for KVM_EXIT_MMIO, but userspace has to emulate any change to the processing state if it decides to decode and emulate the instruction. +This feature isn't available to protected VMs, as userspace does not +have access to the state that is required to perform the emulation. +Instead, a data abort exception is directly injected in the guest. +Note that although KVM_CAP_ARM_NISV_TO_USER will be reported if +queried outside of a protected VM context, the feature will not be +exposed if queried on a protected VM file descriptor. + :: /* KVM_EXIT_X86_RDMSR / KVM_EXIT_X86_WRMSR */ @@ -8819,6 +8826,8 @@ means the VM type with value @n is supported. Possible values of @n are:: #define KVM_X86_DEFAULT_VM 0 #define KVM_X86_SW_PROTECTED_VM 1 + #define KVM_X86_SEV_VM 2 + #define KVM_X86_SEV_ES_VM 3 Note, KVM_X86_SW_PROTECTED_VM is currently only for development and testing. Do not use KVM_X86_SW_PROTECTED_VM for "real" VMs, and especially not in diff --git a/Documentation/virt/kvm/arm/fw-pseudo-registers.rst b/Documentation/virt/kvm/arm/fw-pseudo-registers.rst new file mode 100644 index 000000000000..b90fd0b0fa66 --- /dev/null +++ b/Documentation/virt/kvm/arm/fw-pseudo-registers.rst @@ -0,0 +1,138 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================= +ARM firmware pseudo-registers interface +======================================= + +KVM handles the hypercall services as requested by the guests. New hypercall +services are regularly made available by the ARM specification or by KVM (as +vendor services) if they make sense from a virtualization point of view. + +This means that a guest booted on two different versions of KVM can observe +two different "firmware" revisions. This could cause issues if a given guest +is tied to a particular version of a hypercall service, or if a migration +causes a different version to be exposed out of the blue to an unsuspecting +guest. + +In order to remedy this situation, KVM exposes a set of "firmware +pseudo-registers" that can be manipulated using the GET/SET_ONE_REG +interface. These registers can be saved/restored by userspace, and set +to a convenient value as required. + +The following registers are defined: + +* KVM_REG_ARM_PSCI_VERSION: + + KVM implements the PSCI (Power State Coordination Interface) + specification in order to provide services such as CPU on/off, reset + and power-off to the guest. + + - Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set + (and thus has already been initialized) + - Returns the current PSCI version on GET_ONE_REG (defaulting to the + highest PSCI version implemented by KVM and compatible with v0.2) + - Allows any PSCI version implemented by KVM and compatible with + v0.2 to be set with SET_ONE_REG + - Affects the whole VM (even if the register view is per-vcpu) + +* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1: + Holds the state of the firmware support to mitigate CVE-2017-5715, as + offered by KVM to the guest via a HVC call. The workaround is described + under SMCCC_ARCH_WORKAROUND_1 in [1]. + + Accepted values are: + + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL: + KVM does not offer + firmware support for the workaround. The mitigation status for the + guest is unknown. + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL: + The workaround HVC call is + available to the guest and required for the mitigation. + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED: + The workaround HVC call + is available to the guest, but it is not needed on this VCPU. + +* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2: + Holds the state of the firmware support to mitigate CVE-2018-3639, as + offered by KVM to the guest via a HVC call. The workaround is described + under SMCCC_ARCH_WORKAROUND_2 in [1]_. + + Accepted values are: + + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL: + A workaround is not + available. KVM does not offer firmware support for the workaround. + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN: + The workaround state is + unknown. KVM does not offer firmware support for the workaround. + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL: + The workaround is available, + and can be disabled by a vCPU. If + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED is set, it is active for + this vCPU. + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED: + The workaround is always active on this vCPU or it is not needed. + + +Bitmap Feature Firmware Registers +--------------------------------- + +Contrary to the above registers, the following registers exposes the +hypercall services in the form of a feature-bitmap to the userspace. This +bitmap is translated to the services that are available to the guest. +There is a register defined per service call owner and can be accessed via +GET/SET_ONE_REG interface. + +By default, these registers are set with the upper limit of the features +that are supported. This way userspace can discover all the usable +hypercall services via GET_ONE_REG. The user-space can write-back the +desired bitmap back via SET_ONE_REG. The features for the registers that +are untouched, probably because userspace isn't aware of them, will be +exposed as is to the guest. + +Note that KVM will not allow the userspace to configure the registers +anymore once any of the vCPUs has run at least once. Instead, it will +return a -EBUSY. + +The pseudo-firmware bitmap register are as follows: + +* KVM_REG_ARM_STD_BMAP: + Controls the bitmap of the ARM Standard Secure Service Calls. + + The following bits are accepted: + + Bit-0: KVM_REG_ARM_STD_BIT_TRNG_V1_0: + The bit represents the services offered under v1.0 of ARM True Random + Number Generator (TRNG) specification, ARM DEN0098. + +* KVM_REG_ARM_STD_HYP_BMAP: + Controls the bitmap of the ARM Standard Hypervisor Service Calls. + + The following bits are accepted: + + Bit-0: KVM_REG_ARM_STD_HYP_BIT_PV_TIME: + The bit represents the Paravirtualized Time service as represented by + ARM DEN0057A. + +* KVM_REG_ARM_VENDOR_HYP_BMAP: + Controls the bitmap of the Vendor specific Hypervisor Service Calls. + + The following bits are accepted: + + Bit-0: KVM_REG_ARM_VENDOR_HYP_BIT_FUNC_FEAT + The bit represents the ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID + and ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID function-ids. + + Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_PTP: + The bit represents the Precision Time Protocol KVM service. + +Errors: + + ======= ============================================================= + -ENOENT Unknown register accessed. + -EBUSY Attempt a 'write' to the register after the VM has started. + -EINVAL Invalid bitmap written to the register. + ======= ============================================================= + +.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf diff --git a/Documentation/virt/kvm/arm/hypercalls.rst b/Documentation/virt/kvm/arm/hypercalls.rst index 3e23084644ba..17be111f493f 100644 --- a/Documentation/virt/kvm/arm/hypercalls.rst +++ b/Documentation/virt/kvm/arm/hypercalls.rst @@ -1,138 +1,46 @@ .. SPDX-License-Identifier: GPL-2.0 -======================= -ARM Hypercall Interface -======================= - -KVM handles the hypercall services as requested by the guests. New hypercall -services are regularly made available by the ARM specification or by KVM (as -vendor services) if they make sense from a virtualization point of view. - -This means that a guest booted on two different versions of KVM can observe -two different "firmware" revisions. This could cause issues if a given guest -is tied to a particular version of a hypercall service, or if a migration -causes a different version to be exposed out of the blue to an unsuspecting -guest. - -In order to remedy this situation, KVM exposes a set of "firmware -pseudo-registers" that can be manipulated using the GET/SET_ONE_REG -interface. These registers can be saved/restored by userspace, and set -to a convenient value as required. - -The following registers are defined: - -* KVM_REG_ARM_PSCI_VERSION: - - KVM implements the PSCI (Power State Coordination Interface) - specification in order to provide services such as CPU on/off, reset - and power-off to the guest. - - - Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set - (and thus has already been initialized) - - Returns the current PSCI version on GET_ONE_REG (defaulting to the - highest PSCI version implemented by KVM and compatible with v0.2) - - Allows any PSCI version implemented by KVM and compatible with - v0.2 to be set with SET_ONE_REG - - Affects the whole VM (even if the register view is per-vcpu) - -* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1: - Holds the state of the firmware support to mitigate CVE-2017-5715, as - offered by KVM to the guest via a HVC call. The workaround is described - under SMCCC_ARCH_WORKAROUND_1 in [1]. - - Accepted values are: - - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL: - KVM does not offer - firmware support for the workaround. The mitigation status for the - guest is unknown. - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL: - The workaround HVC call is - available to the guest and required for the mitigation. - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED: - The workaround HVC call - is available to the guest, but it is not needed on this VCPU. - -* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2: - Holds the state of the firmware support to mitigate CVE-2018-3639, as - offered by KVM to the guest via a HVC call. The workaround is described - under SMCCC_ARCH_WORKAROUND_2 in [1]_. - - Accepted values are: - - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL: - A workaround is not - available. KVM does not offer firmware support for the workaround. - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN: - The workaround state is - unknown. KVM does not offer firmware support for the workaround. - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL: - The workaround is available, - and can be disabled by a vCPU. If - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED is set, it is active for - this vCPU. - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED: - The workaround is always active on this vCPU or it is not needed. - - -Bitmap Feature Firmware Registers ---------------------------------- - -Contrary to the above registers, the following registers exposes the -hypercall services in the form of a feature-bitmap to the userspace. This -bitmap is translated to the services that are available to the guest. -There is a register defined per service call owner and can be accessed via -GET/SET_ONE_REG interface. - -By default, these registers are set with the upper limit of the features -that are supported. This way userspace can discover all the usable -hypercall services via GET_ONE_REG. The user-space can write-back the -desired bitmap back via SET_ONE_REG. The features for the registers that -are untouched, probably because userspace isn't aware of them, will be -exposed as is to the guest. - -Note that KVM will not allow the userspace to configure the registers -anymore once any of the vCPUs has run at least once. Instead, it will -return a -EBUSY. - -The pseudo-firmware bitmap register are as follows: - -* KVM_REG_ARM_STD_BMAP: - Controls the bitmap of the ARM Standard Secure Service Calls. - - The following bits are accepted: - - Bit-0: KVM_REG_ARM_STD_BIT_TRNG_V1_0: - The bit represents the services offered under v1.0 of ARM True Random - Number Generator (TRNG) specification, ARM DEN0098. - -* KVM_REG_ARM_STD_HYP_BMAP: - Controls the bitmap of the ARM Standard Hypervisor Service Calls. - - The following bits are accepted: - - Bit-0: KVM_REG_ARM_STD_HYP_BIT_PV_TIME: - The bit represents the Paravirtualized Time service as represented by - ARM DEN0057A. - -* KVM_REG_ARM_VENDOR_HYP_BMAP: - Controls the bitmap of the Vendor specific Hypervisor Service Calls. - - The following bits are accepted: - - Bit-0: KVM_REG_ARM_VENDOR_HYP_BIT_FUNC_FEAT - The bit represents the ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID - and ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID function-ids. - - Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_PTP: - The bit represents the Precision Time Protocol KVM service. - -Errors: - - ======= ============================================================= - -ENOENT Unknown register accessed. - -EBUSY Attempt a 'write' to the register after the VM has started. - -EINVAL Invalid bitmap written to the register. - ======= ============================================================= - -.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf +=============================================== +KVM/arm64-specific hypercalls exposed to guests +=============================================== + +This file documents the KVM/arm64-specific hypercalls which may be +exposed by KVM/arm64 to guest operating systems. These hypercalls are +issued using the HVC instruction according to version 1.1 of the Arm SMC +Calling Convention (DEN0028/C): + +https://developer.arm.com/docs/den0028/c + +All KVM/arm64-specific hypercalls are allocated within the "Vendor +Specific Hypervisor Service Call" range with a UID of +``28b46fb6-2ec5-11e9-a9ca-4b564d003a74``. This UID should be queried by the +guest using the standard "Call UID" function for the service range in +order to determine that the KVM/arm64-specific hypercalls are available. + +``ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID`` +--------------------------------------------- + +Provides a discovery mechanism for other KVM/arm64 hypercalls. + ++---------------------+-------------------------------------------------------------+ +| Presence: | Mandatory for the KVM/arm64 UID | ++---------------------+-------------------------------------------------------------+ +| Calling convention: | HVC32 | ++---------------------+----------+--------------------------------------------------+ +| Function ID: | (uint32) | 0x86000000 | ++---------------------+----------+--------------------------------------------------+ +| Arguments: | None | ++---------------------+----------+----+---------------------------------------------+ +| Return Values: | (uint32) | R0 | Bitmap of available function numbers 0-31 | +| +----------+----+---------------------------------------------+ +| | (uint32) | R1 | Bitmap of available function numbers 32-63 | +| +----------+----+---------------------------------------------+ +| | (uint32) | R2 | Bitmap of available function numbers 64-95 | +| +----------+----+---------------------------------------------+ +| | (uint32) | R3 | Bitmap of available function numbers 96-127 | ++---------------------+----------+----+---------------------------------------------+ + +``ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID`` +---------------------------------------- + +See ptp_kvm.rst diff --git a/Documentation/virt/kvm/arm/index.rst b/Documentation/virt/kvm/arm/index.rst index 7f231c724e16..ec09881de4cf 100644 --- a/Documentation/virt/kvm/arm/index.rst +++ b/Documentation/virt/kvm/arm/index.rst @@ -7,6 +7,7 @@ ARM .. toctree:: :maxdepth: 2 + fw-pseudo-registers hyp-abi hypercalls pvtime diff --git a/Documentation/virt/kvm/arm/ptp_kvm.rst b/Documentation/virt/kvm/arm/ptp_kvm.rst index aecdc80ddcd8..7c0960970a0e 100644 --- a/Documentation/virt/kvm/arm/ptp_kvm.rst +++ b/Documentation/virt/kvm/arm/ptp_kvm.rst @@ -7,19 +7,29 @@ PTP_KVM is used for high precision time sync between host and guests. It relies on transferring the wall clock and counter value from the host to the guest using a KVM-specific hypercall. -* ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID: 0x86000001 +``ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID`` +---------------------------------------- -This hypercall uses the SMC32/HVC32 calling convention: +Retrieve current time information for the specific counter. There are no +endianness restrictions. -ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID - ============== ======== ===================================== - Function ID: (uint32) 0x86000001 - Arguments: (uint32) KVM_PTP_VIRT_COUNTER(0) - KVM_PTP_PHYS_COUNTER(1) - Return Values: (int32) NOT_SUPPORTED(-1) on error, or - (uint32) Upper 32 bits of wall clock time (r0) - (uint32) Lower 32 bits of wall clock time (r1) - (uint32) Upper 32 bits of counter (r2) - (uint32) Lower 32 bits of counter (r3) - Endianness: No Restrictions. - ============== ======== ===================================== ++---------------------+-------------------------------------------------------+ +| Presence: | Optional | ++---------------------+-------------------------------------------------------+ +| Calling convention: | HVC32 | ++---------------------+----------+--------------------------------------------+ +| Function ID: | (uint32) | 0x86000001 | ++---------------------+----------+----+---------------------------------------+ +| Arguments: | (uint32) | R1 | ``KVM_PTP_VIRT_COUNTER (0)`` | +| | | +---------------------------------------+ +| | | | ``KVM_PTP_PHYS_COUNTER (1)`` | ++---------------------+----------+----+---------------------------------------+ +| Return Values: | (int32) | R0 | ``NOT_SUPPORTED (-1)`` on error, else | +| | | | upper 32 bits of wall clock time | +| +----------+----+---------------------------------------+ +| | (uint32) | R1 | Lower 32 bits of wall clock time | +| +----------+----+---------------------------------------+ +| | (uint32) | R2 | Upper 32 bits of counter | +| +----------+----+---------------------------------------+ +| | (uint32) | R3 | Lower 32 bits of counter | ++---------------------+----------+----+---------------------------------------+ diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst index 84335d119ff1..9677a0714a39 100644 --- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst @@ -76,15 +76,56 @@ are defined in ``<linux/psp-dev.h>``. KVM implements the following commands to support common lifecycle events of SEV guests, such as launching, running, snapshotting, migrating and decommissioning. -1. KVM_SEV_INIT ---------------- +1. KVM_SEV_INIT2 +---------------- -The KVM_SEV_INIT command is used by the hypervisor to initialize the SEV platform +The KVM_SEV_INIT2 command is used by the hypervisor to initialize the SEV platform context. In a typical workflow, this command should be the first command issued. +For this command to be accepted, either KVM_X86_SEV_VM or KVM_X86_SEV_ES_VM +must have been passed to the KVM_CREATE_VM ioctl. A virtual machine created +with those machine types in turn cannot be run until KVM_SEV_INIT2 is invoked. + +Parameters: struct kvm_sev_init (in) Returns: 0 on success, -negative on error +:: + + struct kvm_sev_init { + __u64 vmsa_features; /* initial value of features field in VMSA */ + __u32 flags; /* must be 0 */ + __u16 ghcb_version; /* maximum guest GHCB version allowed */ + __u16 pad1; + __u32 pad2[8]; + }; + +It is an error if the hypervisor does not support any of the bits that +are set in ``flags`` or ``vmsa_features``. ``vmsa_features`` must be +0 for SEV virtual machines, as they do not have a VMSA. + +``ghcb_version`` must be 0 for SEV virtual machines, as they do not issue GHCB +requests. If ``ghcb_version`` is 0 for any other guest type, then the maximum +allowed guest GHCB protocol will default to version 2. + +This command replaces the deprecated KVM_SEV_INIT and KVM_SEV_ES_INIT commands. +The commands did not have any parameters (the ```data``` field was unused) and +only work for the KVM_X86_DEFAULT_VM machine type (0). + +They behave as if: + +* the VM type is KVM_X86_SEV_VM for KVM_SEV_INIT, or KVM_X86_SEV_ES_VM for + KVM_SEV_ES_INIT + +* the ``flags`` and ``vmsa_features`` fields of ``struct kvm_sev_init`` are + set to zero, and ``ghcb_version`` is set to 0 for KVM_SEV_INIT and 1 for + KVM_SEV_ES_INIT. + +If the ``KVM_X86_SEV_VMSA_FEATURES`` attribute does not exist, the hypervisor only +supports KVM_SEV_INIT and KVM_SEV_ES_INIT. In that case, note that KVM_SEV_ES_INIT +might set the debug swap VMSA feature (bit 5) depending on the value of the +``debug_swap`` parameter of ``kvm-amd.ko``. + 2. KVM_SEV_LAUNCH_START ----------------------- @@ -425,6 +466,18 @@ issued by the hypervisor to make the guest ready for execution. Returns: 0 on success, -negative on error +Device attribute API +==================== + +Attributes of the SEV implementation can be retrieved through the +``KVM_HAS_DEVICE_ATTR`` and ``KVM_GET_DEVICE_ATTR`` ioctls on the ``/dev/kvm`` +device node, using group ``KVM_X86_GRP_SEV``. + +Currently only one attribute is implemented: + +* ``KVM_X86_SEV_VMSA_FEATURES``: return the set of all bits that + are accepted in the ``vmsa_features`` of ``KVM_SEV_INIT2``. + Firmware Management =================== |
