2025-07-19 15:50:12 +02:00
3669 changed files with 37465 additions and 713181 deletions
--- a/.gitignore
+++ b/.gitignore
@ -135,6 +135,7 @@ GTAGS
 # id-utils files
 ID
 *.orig
 *~
 \#*#
--- a/BUILD.bazel
+++ b/BUILD.bazel
--- a/Documentation/ABI/stable/sysfs-module
+++ b/Documentation/ABI/stable/sysfs-module
@ -45,21 +45,3 @@ Date:		Jun 2005
 Description:
 		If the module source has MODULE_VERSION, this file will contain
 		the version of the source code.
 What:		/sys/module/MODULENAME/scmversion
 Date:		November 2020
 KernelVersion:	5.12
 Contact:	Will McVicker <willmcvicker@google.com>
 Description:	This read-only file will appear if modpost was supplied with an
 		SCM version for the module. It can be enabled with the config
 		MODULE_SCMVERSION. The SCM version is retrieved by
 		scripts/setlocalversion, which means that the presence of this
 		file depends on CONFIG_LOCALVERSION_AUTO=y. When read, the SCM
 		version that the module was compiled with is returned. The SCM
 		version is returned in the following format::
 		===
 		Git:		g[a-f0-9]\+(-dirty)\?
 		Mercurial:	hg[a-f0-9]\+(-dirty)\?
 		Subversion:	svn[0-9]\+
 		===
--- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
@ -342,70 +342,6 @@ Description:	Specific uncompressed frame descriptors
 					   support
 		=========================  =====================================
 What:           /config/usb-gadget/gadget/functions/uvc.name/streaming/framebased
 Date:           Sept 2024
 KernelVersion:  5.15
 Description:    Framebased format descriptors
 What:           /config/usb-gadget/gadget/functions/uvc.name/streaming/framebased/name
 Date:           Sept 2024
 KernelVersion:  5.15
 Description:    Specific framebased format descriptors
                ==================      =======================================
                bFormatIndex            unique id for this format descriptor;
                                        only defined after parent header is
                                        linked into the streaming class;
                                        read-only
                bmaControls             this format's data for bmaControls in
                                        the streaming header
                bmInterlaceFlags        specifies interlace information,
                                        read-only
                bAspectRatioY           the X dimension of the picture aspect
                                        ratio, read-only
                bAspectRatioX           the Y dimension of the picture aspect
                                        ratio, read-only
                bDefaultFrameIndex      optimum frame index for this stream
                bBitsPerPixel           number of bits per pixel used to
                                        specify color in the decoded video
                                        frame
                guidFormat              globally unique id used to identify
                                        stream-encoding format
                ==================      =======================================
 What:           /config/usb-gadget/gadget/functions/uvc.name/streaming/framebased/name/name
 Date:           Sept 2024
 KernelVersion:  5.15
 Description:    Specific framebased frame descriptors
                =========================  =====================================
                bFrameIndex                unique id for this framedescriptor;
                                           only defined after parent format is
                                           linked into the streaming header;
                                           read-only
                dwFrameInterval            indicates how frame interval can be
                                           programmed; a number of values
                                           separated by newline can be specified
                dwDefaultFrameInterval     the frame interval the device would
                                           like to use as default
                dwBytesPerLine             Specifies the number of bytes per line
                                           of video for packed fixed frame size
                                           formats, allowing the receiver to
                                           perform stride alignment of the video.
                                           If the bVariableSize value (above) is
                                           TRUE (1), or if the format does not
                                           permit such alignment, this value shall
                                           be set to zero (0).
                dwMaxBitRate               the maximum bit rate at the shortest
                                           frame interval in bps
                dwMinBitRate               the minimum bit rate at the longest
                                           frame interval in bps
                wHeight                    height of decoded bitmap frame in px
                wWidth                     width of decoded bitmam frame in px
                bmCapabilities             still image support, fixed frame-rate
                                           support
                =========================  =====================================
 What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/header
 Date:		Dec 2014
 KernelVersion:	4.0
--- a/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818
+++ b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818
@ -3,7 +3,7 @@ KernelVersion:
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Reading this returns the valid values that can be written to the
-		filter_mode attribute:
+		on_altvoltage0_mode attribute:
 		- auto -> Adjust bandpass filter to track changes in input clock rate.
 		- manual -> disable/unregister the clock rate notifier / input clock tracking.
--- a/Documentation/ABI/testing/sysfs-class-android_usb
+++ b/Documentation/ABI/testing/sysfs-class-android_usb
@ -1,32 +0,0 @@
 Android USB devices (eg. /sys/class/android_usb/android0/)
 What:		/sys/class/android_usb/<android_device>/state
 Date:		Feb 2024
 Contact:	Neill Kapron <nkapron@google.com>
 Description:
 		The state of the USB connection. This attribute is likely
 		redundant with the /sys/class/UDC/state attribute, and should
 		be deprecated/removed when userspace can be refactored.
 		Change on the state will also generate uevent KOBJ_CHANGE on
 		the port with the new state included in the message as
 		"USB_STATE=<STATE>". Note this is not the correct usage of
 		uevents, but necessary due to the requirement to maintaine
 		userspace API compatibility.
 		Valid values: CONNECTED, DISCONNECTED, CONFIGURED
 Android USB MIDI Function devices (eg. /sys/class/android_usb/androidN/f_midi/)
 What:		/sys/class/android_usb/<android_device>/f_midi/alsa
 Date:		Feb 2024
 Contact		Neill Kapron <nkapron@google.com>
 Description:
 		The PCM card and device numbers created by the f_midi driver.
 		This is not the correct use of sysfs due to passing multiple
 		values through a single file, which is directly against the
 		"one value per file" nature of sysfs, however Android userspace
 		code currently relies on this functionality as-is.
 		Valid values: card and device numbers in the format of
 		<PCM_card_number> <device number>", or "-1 -1" if the attr
 		is read prior to binding the f_midi device.
--- a/Documentation/ABI/testing/sysfs-driver-ufs
+++ b/Documentation/ABI/testing/sysfs-driver-ufs
@ -920,16 +920,14 @@ Description:	This file shows whether the configuration descriptor is locked.
 What:		/sys/bus/platform/drivers/ufshcd/*/attributes/max_number_of_rtt
 What:		/sys/bus/platform/devices/*.ufs/attributes/max_number_of_rtt
-Date:		May 2024
+Date:		February 2018
-Contact:	Avri Altman <avri.altman@wdc.com>
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
 Description:	This file provides the maximum current number of
-		outstanding RTTs in device that is allowed. bMaxNumOfRTT is a
+		outstanding RTTs in device that is allowed. The full
-		read-write persistent attribute and is equal to two after device
+		information about the attribute could be found at
-		manufacturing. It shall not be set to a value greater than
+		UFS specifications 2.1.
 		bDeviceRTTCap value, and it may be set only when the hw queues are
 		empty.
-		The file is read write.
+		The file is read only.
 What:		/sys/bus/platform/drivers/ufshcd/*/attributes/exception_event_control
 What:		/sys/bus/platform/devices/*.ufs/attributes/exception_event_control
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@ -311,13 +311,10 @@ Description:	Do background GC aggressively when set. Set to 0 by default.
 		GC approach and turns SSR mode on.
 		gc urgent low(2): lowers the bar of checking I/O idling in
 		order to process outstanding discard commands and GC a
-		little bit aggressively. always uses cost benefit GC approach,
+		little bit aggressively. uses cost benefit GC approach.
 		and will override age-threshold GC approach if ATGC is enabled
 		at the same time.
 		gc urgent mid(3): does GC forcibly in a period of given
 		gc_urgent_sleep_time and executes a mid level of I/O idling check.
-		always uses cost benefit GC approach, and will override
+		uses cost benefit GC approach.
 		age-threshold GC approach if ATGC is enabled at the same time.
 What:		/sys/fs/f2fs/<disk>/gc_urgent_sleep_time
 Date:		August 2017
@ -334,7 +331,7 @@ Date:		January 2018
 Contact:	Jaegeuk Kim <jaegeuk@kernel.org>
 Description:	This indicates how many GC can be failed for the pinned
 		file. If it exceeds this, F2FS doesn't guarantee its pinning
-		state. 2048 trials is set by default, and 65535 as maximum.
+		state. 2048 trials is set by default.
 What:		/sys/fs/f2fs/<disk>/extension_list
 Date:		February 2018
@ -501,21 +498,6 @@ Description:	Show status of f2fs checkpoint in real time.
 		CP_RESIZEFS_FLAG		0x00004000
 		=============================== ==============================
 What:		/sys/fs/f2fs/<disk>/stat/issued_discard
 Date:		December 2023
 Contact:	"Zhiguo Niu" <zhiguo.niu@unisoc.com>
 Description:	Shows the number of issued discard.
 What:		/sys/fs/f2fs/<disk>/stat/queued_discard
 Date:		December 2023
 Contact:	"Zhiguo Niu" <zhiguo.niu@unisoc.com>
 Description:	Shows the number of queued discard.
 What:		/sys/fs/f2fs/<disk>/stat/undiscard_blks
 Date:		December 2023
 Contact:	"Zhiguo Niu" <zhiguo.niu@unisoc.com>
 Description:	Shows the total number of undiscard blocks.
 What:		/sys/fs/f2fs/<disk>/ckpt_thread_ioprio
 Date:		January 2021
 Contact:	"Daeho Jeong" <daehojeong@google.com>
@ -582,12 +564,6 @@ Description:	When ATGC is on, it controls age threshold to bypass GCing young
 		candidates whose age is not beyond the threshold, by default it was
 		initialized as 604800 seconds (equals to 7 days).
 What:		/sys/fs/f2fs/<disk>/atgc_enabled
 Date:		Feb 2024
 Contact:	"Jinbao Liu" <liujinbao1@xiaomi.com>
 Description:	It represents whether ATGC is on or off. The value is 1 which
               indicates that ATGC is on, and 0 indicates that it is off.
 What:		/sys/fs/f2fs/<disk>/gc_reclaimed_segments
 Date:		July 2021
 Contact:	"Daeho Jeong" <daehojeong@google.com>
@ -710,9 +686,9 @@ Description:	Support configuring fault injection type, should be
 		enabled with fault_injection option, fault type value
 		is shown below, it supports single or combined type.
-		===========================      ===========
+		===================      ===========
 		Type_Name                Type_Value
-		===========================      ===========
+		===================      ===========
 		FAULT_KMALLOC            0x000000001
 		FAULT_KVMALLOC           0x000000002
 		FAULT_PAGE_ALLOC         0x000000004
@ -731,10 +707,8 @@ Description:	Support configuring fault injection type, should be
 		FAULT_SLAB_ALLOC         0x000008000
 		FAULT_DQUOT_INIT         0x000010000
 		FAULT_LOCK_OP            0x000020000
-		FAULT_BLKADDR_VALIDITY           0x000040000
+		FAULT_BLKADDR            0x000040000
-		FAULT_BLKADDR_CONSISTENCE        0x000080000
+		===================      ===========
 		FAULT_NO_SEGMENT                 0x000100000
 		===========================      ===========
 What:		/sys/fs/f2fs/<disk>/discard_io_aware_gran
 Date:		January 2023
@ -766,65 +740,3 @@ Description:	When compress cache is on, it controls cached page
 		If cached page percent exceed threshold, then deny caching compress page.
 		The value should be in range of (0, 100], by default it was initialized
 		as 20(%).
 What:		/sys/fs/f2fs/<disk>/discard_io_aware
 Date:		November 2023
 Contact:	"Chao Yu" <chao@kernel.org>
 Description:	It controls to enable/disable IO aware feature for background discard.
 		By default, the value is 1 which indicates IO aware is on.
 What:		/sys/fs/f2fs/<disk>/blkzone_alloc_policy
 Date:		July 2024
 Contact:	"Yuanhong Liao" <liaoyuanhong@vivo.com>
 Description:	The zone UFS we are currently using consists of two parts:
 		conventional zones and sequential zones. It can be used to control which part
 		to prioritize for writes, with a default value of 0.
 		========================  =========================================
 		value					  description
 		blkzone_alloc_policy = 0  Prioritize writing to sequential zones
 		blkzone_alloc_policy = 1  Only allow writing to sequential zones
 		blkzone_alloc_policy = 2  Prioritize writing to conventional zones
 		========================  =========================================
 What:		/sys/fs/f2fs/<disk>/migration_window_granularity
 Date:		September 2024
 Contact:	"Daeho Jeong" <daehojeong@google.com>
 Description:	Controls migration window granularity of garbage collection on large
 		section. it can control the scanning window granularity for GC migration
 		in a unit of segment, while migration_granularity controls the number
 		of segments which can be migrated at the same turn.
 What:		/sys/fs/f2fs/<disk>/reserved_segments
 Date:		September 2024
 Contact:	"Daeho Jeong" <daehojeong@google.com>
 Description:	In order to fine tune GC behavior, we can control the number of
 		reserved segments.
 What:		/sys/fs/f2fs/<disk>/gc_no_zoned_gc_percent
 Date:		September 2024
 Contact:	"Daeho Jeong" <daehojeong@google.com>
 Description:	If the percentage of free sections over total sections is above this
 		number, F2FS do not garbage collection for zoned devices through the
 		background GC thread. the default number is "60".
 What:		/sys/fs/f2fs/<disk>/gc_boost_zoned_gc_percent
 Date:		September 2024
 Contact:	"Daeho Jeong" <daehojeong@google.com>
 Description:	If the percentage of free sections over total sections is under this
 		number, F2FS boosts garbage collection for zoned devices through the
 		background GC thread. the default number is "25".
 What:		/sys/fs/f2fs/<disk>/gc_valid_thresh_ratio
 Date:		September 2024
 Contact:	"Daeho Jeong" <daehojeong@google.com>
 Description:	It controls the valid block ratio threshold not to trigger excessive GC
 		for zoned deivces. The initial value of it is 95(%). F2FS will stop the
 		background GC thread from intiating GC for sections having valid blocks
 		exceeding the ratio.
 What:		/sys/fs/f2fs/<disk>/max_read_extent_count
 Date:		November 2024
 Contact:	"Chao Yu" <chao@kernel.org>
 Description:	It controls max read extent count for per-inode, the value of threshold
 		is 10240 by default.
--- a/Documentation/ABI/testing/sysfs-fs-fuse
+++ b/Documentation/ABI/testing/sysfs-fs-fuse
@ -1,19 +0,0 @@
 What:		/sys/fs/fuse/features/fuse_bpf
 Date:		December 2022
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:
 		Read-only file that contains the word 'supported' if fuse-bpf is
 		supported, does not exist otherwise
 What:		/sys/fs/fuse/bpf_prog_type_fuse
 Date:		December 2022
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:
 		bpf_prog_type_fuse defines the program type of bpf programs that
 		may be passed to fuse-bpf. For upstream bpf program types, this
 		is a constant defined in a contiguous array of constants.
 		bpf_prog_type_fuse is appended to the end of the list, so it may
 		change and therefore its value must be read from this file.
 		Contents is ASCII decimal representation of bpf_prog_type_fuse
--- a/Documentation/ABI/testing/sysfs-fs-incfs
+++ b/Documentation/ABI/testing/sysfs-fs-incfs
@ -1,70 +0,0 @@
 What:		/sys/fs/incremental-fs/features/corefs
 Date:		2019
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Reads 'supported'. Always present.
 What:		/sys/fs/incremental-fs/features/v2
 Date:		April 2021
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Reads 'supported'. Present if all v2 features of incfs are
 		supported.
 What:		/sys/fs/incremental-fs/features/zstd
 Date:		April 2021
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Reads 'supported'. Present if zstd compression is supported
 		for data blocks.
 What:		/sys/fs/incremental-fs/features/bugfix_throttling
 Date:		January 2023
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Reads 'supported'. Present if the throttling lock bug is fixed
 		https://android-review.git.corp.google.com/c/kernel/common/+/2381827
 What:		/sys/fs/incremental-fs/instances/[name]
 Date:		April 2021
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Folder created when incfs is mounted with the sysfs_name=[name]
 		option. If this option is used, the following values are created
 		in this folder.
 What:		/sys/fs/incremental-fs/instances/[name]/reads_delayed_min
 Date:		April 2021
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Returns a count of the number of reads that were delayed as a
 		result of the per UID read timeouts min time setting.
 What:		/sys/fs/incremental-fs/instances/[name]/reads_delayed_min_us
 Date:		April 2021
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Returns total delay time for all files since first mount as a
 		result of the per UID read timeouts min time setting.
 What:		/sys/fs/incremental-fs/instances/[name]/reads_delayed_pending
 Date:		April 2021
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Returns a count of the number of reads that were delayed as a
 		result of waiting for a pending read.
 What:		/sys/fs/incremental-fs/instances/[name]/reads_delayed_pending_us
 Date:		April 2021
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Returns total delay time for all files since first mount as a
 		result of waiting for a pending read.
 What:		/sys/fs/incremental-fs/instances/[name]/reads_failed_hash_verification
 Date:		April 2021
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Returns number of reads that failed because of hash verification
 		failures.
 What:		/sys/fs/incremental-fs/instances/[name]/reads_failed_other
 Date:		April 2021
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Returns number of reads that failed for reasons other than
 		timing out or hash failures.
 What:		/sys/fs/incremental-fs/instances/[name]/reads_failed_timed_out
 Date:		April 2021
 Contact:	Paul Lawrence <paullawrence@google.com>
 Description:	Returns number of reads that timed out.
--- a/Documentation/ABI/testing/sysfs-kernel-dmaheap
+++ b/Documentation/ABI/testing/sysfs-kernel-dmaheap
@ -1,7 +0,0 @@
 What:		/sys/kernel/dma_heap/total_pools_kb
 Date:		Feb 2021
 KernelVersion:	5.10
 Contact:	T.J. Mercier <tjmercier@google.com>
 Description:
 		The total_pools_kb file is read-only and specifies how much
 		memory in KiB is allocated to DMA-BUF heap pools.
--- a/Documentation/ABI/testing/sysfs-kernel-mm-transparent-hugepage
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-transparent-hugepage
@ -1,18 +0,0 @@
 What:		/sys/kernel/mm/transparent_hugepage/
 Date:		April 2024
 Contact:	Linux memory management mailing list <linux-mm@kvack.org>
 Description:
 		/sys/kernel/mm/transparent_hugepage/ contains a number of files and
 		subdirectories,
 			- defrag
 			- enabled
 			- hpage_pmd_size
 			- khugepaged
 			- shmem_enabled
 			- use_zero_page
 			- subdirectories of the form hugepages-<size>kB, where <size>
 			  is the page size of the hugepages supported by the kernel/CPU
 			  combination.
 		See Documentation/admin-guide/mm/transhuge.rst for details.
--- a/Documentation/ABI/testing/sysfs-kernel-wakeup_reasons
+++ b/Documentation/ABI/testing/sysfs-kernel-wakeup_reasons
@ -1,16 +0,0 @@
 What:		/sys/kernel/wakeup_reasons/last_resume_reason
 Date:		February 2014
 Contact:	Ruchi Kandoi <kandoiruchi@google.com>
 Description:
 		The /sys/kernel/wakeup_reasons/last_resume_reason is
 		used to report wakeup reasons after system exited suspend.
 What:		/sys/kernel/wakeup_reasons/last_suspend_time
 Date:		March 2015
 Contact:	jinqian <jinqian@google.com>
 Description:
 		The /sys/kernel/wakeup_reasons/last_suspend_time is
 		used to report time spent in last suspend cycle. It contains
 		two numbers (in seconds) separated by space. First number is
 		the time spent in suspend and resume processes. Second number
 		is the time spent in sleep state.
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@ -1067,10 +1067,6 @@
 			can be useful when debugging issues that require an SLB
 			miss to occur.
 	disable_dma32=	[KNL]
 			Dynamically disable ZONE_DMA32 on kernels compiled with
 			CONFIG_ZONE_DMA32=y.
 	disable=	[IPV6]
 			See Documentation/networking/ipv6.rst.
@ -1565,28 +1561,12 @@
 			The above will cause the "foo" tracing instance to trigger
 			a snapshot at the end of boot up.
-	ftrace_dump_on_oops[=2(orig_cpu) | =<instance>][,<instance> |
+	ftrace_dump_on_oops[=orig_cpu]
 			  ,<instance>=2(orig_cpu)]
 			[FTRACE] will dump the trace buffers on oops.
-			If no parameter is passed, ftrace will dump global
+			If no parameter is passed, ftrace will dump
-			buffers of all CPUs, if you pass 2 or orig_cpu, it
+			buffers of all CPUs, but if you pass orig_cpu, it will
-			will dump only the buffer of the CPU that triggered
+			dump only the buffer of the CPU that triggered the
-			the oops, or the specific instance will be dumped if
+			oops.
 			its name is passed. Multiple instance dump is also
 			supported, and instances are separated by commas. Each
 			instance supports only dump on CPU that triggered the
 			oops by passing 2 or orig_cpu to it.
 			ftrace_dump_on_oops=foo=orig_cpu
 			The above will dump only the buffer of "foo" instance
 			on CPU that triggered the oops.
 			ftrace_dump_on_oops,foo,bar=orig_cpu
 			The above will dump global buffer on all CPUs, the
 			buffer of "foo" instance on all CPUs and the buffer
 			of "bar" instance on CPU that triggered the oops.
 	ftrace_filter=[function-list]
 			[FTRACE] Limit the functions traced by the function
@ -1870,10 +1850,6 @@
 				If specified, z/VM IUCV HVC accepts connections
 				from listed z/VM user IDs only.
 	hvc_dcc.enable=	[ARM,ARM64]	Enable DCC driver at runtime. For GKI,
 				disabled at runtime by default to prevent
 				crashes in devices which do not support DCC.
 	hv_nopvspin	[X86,HYPER_V] Disables the paravirt spinlock optimizations
 				      which allow the hypervisor to 'idle' the
 				      guest on lock contention.
@ -2280,9 +2256,6 @@
 			1 - Bypass the IOMMU for DMA.
 			unset - Use value of CONFIG_IOMMU_DEFAULT_PASSTHROUGH.
 	ioremap_guard	[ARM64] enable the KVM MMIO guard functionality
 			if available.
 	io7=		[HW] IO7 for Marvel-based Alpha systems
 			See comment before marvel_specify_io7 in
 			arch/alpha/kernel/core_marvel.c.
@ -2571,7 +2544,7 @@
 			CONFIG_KUNIT to be set to be fully enabled. The
 			default value can be overridden via
 			KUNIT_DEFAULT_ENABLED.
-			Default is 0 (disabled)
+			Default is 1 (enabled)
 	kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs.
 			Default is 0 (don't ignore, but inject #GP)
@ -2647,9 +2620,7 @@
 			      protected guests.
 			protected: nVHE-based mode with support for guests whose
-				   state is kept private from the host. See
+				   state is kept private from the host.
 				   Documentation/virt/kvm/arm/pkvm.rst for more
 				   information about this mode of operation.
 			nested: VHE-based mode with support for nested
 				virtualization. Requires at least ARMv8.3
@ -2660,13 +2631,6 @@
 			for the host. "nested" is experimental and should be
 			used with extreme caution.
 	kvm-arm.protected_modules=
 			[KVM,ARM] List of pKVM modules to load before the host
 			is deprevileged.
 			This option only applies when booting with
 			kvm-arm.mode=protected.
 	kvm-arm.vgic_v3_group0_trap=
 			[KVM,ARM] Trap guest accesses to GICv3 group-0
 			system registers
@ -3506,16 +3470,6 @@
 			allocations which rules out almost all kernel
 			allocations. Use with caution!
 	nosplit=X,Y	[MM] Set the minimum order of the nosplit zone. Pages in
 			this zone can't be split down below order Y, while free
 			or in use.
 			Like movablecore, X should be either nn[KMGTPE] or n%.
 	nomerge=X,Y	[MM] Set the exact orders of the nomerge zone. Pages in
 			this zone are always order Y, meaning they can't be
 			split or merged while free or in use.
 			Like movablecore, X should be either nn[KMGTPE] or n%.
 	MTD_Partition=	[MTD]
 			Format: <name>,<region-number>,<size>,<offset>
@ -4685,16 +4639,6 @@
 	printk.time=	Show timing data prefixed to each printk message line
 			Format: <bool>  (1/Y/y=enable, 0/N/n=disable)
 	proc_mem.force_override= [KNL]
 			Format: {always | ptrace | never}
 			Traditionally /proc/pid/mem allows memory permissions to be
 			overridden without restrictions. This option may be set to
 			restrict that. Can be one of:
 			- 'always': traditional behavior always allows mem overrides.
 			- 'ptrace': only allow mem overrides for active ptracers.
 			- 'never':  never allow mem overrides.
 			If not specified, default is the CONFIG_PROC_MEM_* choice.
 	processor.max_cstate=	[HW,ACPI]
 			Limit processor to maximum C-state
 			max_cstate=9 overrides any DMI blacklist limit.
@ -5015,11 +4959,6 @@
 			this kernel boot parameter, forcibly setting it
 			to zero.
 	rcutree.enable_rcu_lazy= [KNL]
 			To save power, batch RCU callbacks and flush after
 			delay, memory pressure or callback list growing too
 			big.
 	rcuscale.gp_async= [KNL]
 			Measure performance of asynchronous
 			grace-period primitives such as call_rcu().
@ -5297,21 +5236,6 @@
 	rcutorture.verbose= [KNL]
 			Enable additional printk() statements.
 	rcupdate.rcu_boot_end_delay= [KNL]
 			Minimum time in milliseconds from the start of boot
 			that must elapse before the boot sequence can be marked
 			complete from RCU's perspective, after which RCU's
 			behavior becomes more relaxed. The default value is also
 			configurable via CONFIG_RCU_BOOT_END_DELAY.
 			Userspace can also mark the boot as completed
 			sooner by writing the time in milliseconds, say once
 			userspace considers the system as booted, to:
 			/sys/module/rcupdate/parameters/rcu_boot_end_delay
 			Or even just writing a value of 0 to this sysfs node.
 			The sysfs node can also be used to extend the delay
 			to be larger than the default, assuming the marking
 			of boot complete has not yet occurred.
 	rcupdate.rcu_cpu_stall_ftrace_dump= [KNL]
 			Dump ftrace buffer after reporting RCU CPU
 			stall warning.
@ -6472,15 +6396,6 @@
 			<deci-seconds>: poll all this frequency
 			0: no polling (default)
 	thp_anon=	[KNL]
 			Format: <size>,<size>[KMG]:<state>;<size>-<size>[KMG]:<state>
 			state is one of "always", "madvise", "never" or "inherit".
 			Control the default behavior of the system with respect
 			to anonymous transparent hugepages.
 			Can be used multiple times for multiple anon THP sizes.
 			See Documentation/admin-guide/mm/transhuge.rst for more
 			details.
 	threadirqs	[KNL]
 			Force threading of all interrupt handlers except those
 			marked explicitly IRQF_NO_THREAD.
@ -7223,15 +7138,6 @@
 			threshold repeatedly. They are likely good
 			candidates for using WQ_UNBOUND workqueues instead.
 	workqueue.cpu_intensive_warning_thresh=<uint>
 			If CONFIG_WQ_CPU_INTENSIVE_REPORT is set, the kernel
 			will report the work functions which violate the
 			intensive_threshold_us repeatedly. In order to prevent
 			spurious warnings, start printing only after a work
 			function has violated this threshold number of times.
 			The default is 4 times. 0 disables the warning.
 	workqueue.power_efficient
 			Per-cpu workqueues are generally preferred because
 			they show better performance thanks to cache
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@ -45,25 +45,10 @@ components:
   the two is using hugepages just because of the fact the TLB miss is
   going to run faster.
 Modern kernels support "multi-size THP" (mTHP), which introduces the
 ability to allocate memory in blocks that are bigger than a base page
 but smaller than traditional PMD-size (as described above), in
 increments of a power-of-2 number of pages. mTHP can back anonymous
 memory (for example 16K, 32K, 64K, etc). These THPs continue to be
 PTE-mapped, but in many cases can still provide similar benefits to
 those outlined above: Page faults are significantly reduced (by a
 factor of e.g. 4, 8, 16, etc), but latency spikes are much less
 prominent because the size of each page isn't as huge as the PMD-sized
 variant and there is less memory to clear in each page fault. Some
 architectures also employ TLB compression mechanisms to squeeze more
 entries in when a set of PTEs are virtually and physically contiguous
 and approporiately aligned. In this case, TLB misses will occur less
 often.
 THP can be enabled system wide or restricted to certain tasks or even
 memory ranges inside task's address space. Unless THP is completely
 disabled, there is ``khugepaged`` daemon that scans memory and
-collapses sequences of basic pages into PMD-sized huge pages.
+collapses sequences of basic pages into huge pages.
 The THP behaviour is controlled via :ref:`sysfs <thp_sysfs>`
 interface and using madvise(2) and prctl(2) system calls.
@ -110,40 +95,12 @@ Global THP controls
 Transparent Hugepage Support for anonymous memory can be entirely disabled
 (mostly for debugging purposes) or only enabled inside MADV_HUGEPAGE
 regions (to avoid the risk of consuming more memory resources) or enabled
-system wide. This can be achieved per-supported-THP-size with one of::
+system wide. This can be achieved with one of::
 	echo always >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
 	echo madvise >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
 	echo never >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
 where <size> is the hugepage size being addressed, the available sizes
 for which vary by system.
 For example::
 	echo always >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
 Alternatively it is possible to specify that a given hugepage size
 will inherit the top-level "enabled" value::
 	echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
 For example::
 	echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
 The top-level setting (for use with "inherit") can be set by issuing
 one of the following commands::
 	echo always >/sys/kernel/mm/transparent_hugepage/enabled
 	echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
 	echo never >/sys/kernel/mm/transparent_hugepage/enabled
 By default, PMD-sized hugepages have enabled="inherit" and all other
 hugepage sizes have enabled="never". If enabling multiple hugepage
 sizes, the kernel will select the most appropriate enabled size for a
 given allocation.
 It's also possible to limit defrag efforts in the VM to generate
 anonymous hugepages in case they're not immediately free to madvise
 regions or to never try to defrag memory and simply fallback to regular
@ -189,34 +146,25 @@ madvise
 never
 	should be self-explanatory.
-By default kernel tries to use huge, PMD-mappable zero page on read
+By default kernel tries to use huge zero page on read page fault to
-page fault to anonymous mapping. It's possible to disable huge zero
+anonymous mapping. It's possible to disable huge zero page by writing 0
-page by writing 0 or enable it back by writing 1::
+or enable it back by writing 1::
 	echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page
 	echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
-Some userspace (such as a test program, or an optimized memory
+Some userspace (such as a test program, or an optimized memory allocation
-allocation library) may want to know the size (in bytes) of a
+library) may want to know the size (in bytes) of a transparent hugepage::
 PMD-mappable transparent hugepage::
 	cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
-khugepaged will be automatically started when one or more hugepage
+khugepaged will be automatically started when
-sizes are enabled (either by directly setting "always" or "madvise",
+transparent_hugepage/enabled is set to "always" or "madvise, and it'll
-or by setting "inherit" while the top-level enabled is set to "always"
+be automatically shutdown if it's set to "never".
 or "madvise"), and it'll be automatically shutdown when the last
 hugepage size is disabled (either by directly setting "never", or by
 setting "inherit" while the top-level enabled is set to "never").
 Khugepaged controls
 -------------------
 .. note::
   khugepaged currently only searches for opportunities to collapse to
   PMD-sized THP and no attempt is made to collapse to other THP
   sizes.
 khugepaged runs usually at low frequency so while one may not want to
 invoke defrag algorithms synchronously during the page faults, it
 should be worth invoking defrag at least in khugepaged. However it's
@ -284,37 +232,13 @@ processes. Exceeding the number would block the collapse::
 A higher value may increase memory footprint for some workloads.
-Boot parameters
+Boot parameter
-===============
+==============
-You can change the sysfs boot time default for the top-level "enabled"
+You can change the sysfs boot time defaults of Transparent Hugepage
-control by passing the parameter ``transparent_hugepage=always`` or
+Support by passing the parameter ``transparent_hugepage=always`` or
-``transparent_hugepage=madvise`` or ``transparent_hugepage=never`` to the
+``transparent_hugepage=madvise`` or ``transparent_hugepage=never``
-kernel command line.
+to the kernel command line.
 Alternatively, each supported anonymous THP size can be controlled by
 passing ``thp_anon=<size>,<size>[KMG]:<state>;<size>-<size>[KMG]:<state>``,
 where ``<size>`` is the THP size (must be a power of 2 of PAGE_SIZE and
 supported anonymous THP)  and ``<state>`` is one of ``always``, ``madvise``,
 ``never`` or ``inherit``.
 For example, the following will set 16K, 32K, 64K THP to ``always``,
 set 128K, 512K to ``inherit``, set 256K to ``madvise`` and 1M, 2M
 to ``never``::
 	thp_anon=16K-64K:always;128K,512K:inherit;256K:madvise;1M-2M:never
 ``thp_anon=`` may be specified multiple times to configure all THP sizes as
 required. If ``thp_anon=`` is specified at least once, any anon THP sizes
 not explicitly configured on the command line are implicitly set to
 ``never``.
 ``transparent_hugepage`` setting only affects the global toggle. If
 ``thp_anon`` is not specified, PMD_ORDER THP will default to ``inherit``.
 However, if a valid ``thp_anon`` setting is provided by the user, the
 PMD_ORDER THP policy will be overridden. If the policy for PMD_ORDER
 is not defined within a valid ``thp_anon``, its policy will default to
 ``never``.
 Hugepages in tmpfs/shmem
 ========================
@ -358,22 +282,19 @@ force
 Need of application restart
 ===========================
-The transparent_hugepage/enabled and
+The transparent_hugepage/enabled values and tmpfs mount option only affect
-transparent_hugepage/hugepages-<size>kB/enabled values and tmpfs mount
+future behavior. So to make them effective you need to restart any
-option only affect future behavior. So to make them effective you need
+application that could have been using hugepages. This also applies to the
-to restart any application that could have been using hugepages. This
+regions registered in khugepaged.
 also applies to the regions registered in khugepaged.
 Monitoring usage
 ================
-The number of PMD-sized anonymous transparent huge pages currently used by the
+The number of anonymous transparent huge pages currently used by the
 system is available by reading the AnonHugePages field in ``/proc/meminfo``.
-To identify what applications are using PMD-sized anonymous transparent huge
+To identify what applications are using anonymous transparent huge pages,
-pages, it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages
+it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages fields
-fields for each mapping. (Note that AnonHugePages only applies to traditional
+for each mapping.
 PMD-sized THP for historical reasons and should have been called
 AnonHugePmdMapped).
 The number of file transparent huge pages mapped to userspace is available
 by reading ShmemPmdMapped and ShmemHugePages fields in ``/proc/meminfo``.
@ -389,7 +310,7 @@ monitor how successfully the system is providing huge pages for use.
 thp_fault_alloc
 	is incremented every time a huge page is successfully
-	allocated and charged to handle a page fault.
+	allocated to handle a page fault.
 thp_collapse_alloc
 	is incremented by khugepaged when it has found
@ -397,7 +318,7 @@ thp_collapse_alloc
 	successfully allocated a new huge page to store the data.
 thp_fault_fallback
-	is incremented if a page fault fails to allocate or charge
+	is incremented if a page fault fails to allocate
 	a huge page and instead falls back to using small pages.
 thp_fault_fallback_charge
@ -467,49 +388,6 @@ thp_swpout_fallback
 	Usually because failed to allocate some continuous swap space
 	for the huge page.
 In /sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/stats, There are
 also individual counters for each huge page size, which can be utilized to
 monitor the system's effectiveness in providing huge pages for usage. Each
 counter has its own corresponding file.
 anon_fault_alloc
 	is incremented every time a huge page is successfully
 	allocated and charged to handle a page fault.
 anon_fault_fallback
 	is incremented if a page fault fails to allocate or charge
 	a huge page and instead falls back to using huge pages with
 	lower orders or small pages.
 anon_fault_fallback_charge
 	is incremented if a page fault fails to charge a huge page and
 	instead falls back to using huge pages with lower orders or
 	small pages even though the allocation was successful.
 swpout
 	is incremented every time a huge page is swapped out in one
 	piece without splitting.
 swpout_fallback
 	is incremented if a huge page has to be split before swapout.
 	Usually because failed to allocate some continuous swap space
 	for the huge page.
 split
 	is incremented every time a huge page is successfully split into
 	smaller orders. This can happen for a variety of reasons but a
 	common reason is that a huge page is old and is being reclaimed.
 split_failed
 	is incremented if kernel fails to split huge
 	page. This can happen if the page was pinned by somebody.
 split_deferred
 	is incremented when a huge page is put onto split queue.
 	This happens when a huge page is partially unmapped and splitting
 	it would free up some memory. Pages on split queue are going to
 	be split under memory pressure, if splitting is possible.
 As the system ages, allocating huge pages may be expensive as the
 system uses memory compaction to copy data around memory to free a
 huge page for use. There are some counters in ``/proc/vmstat`` to help
@ -535,7 +413,7 @@ for huge pages.
 Optimizing the applications
 ===========================
-To be guaranteed that the kernel will map a THP immediately in any
+To be guaranteed that the kernel will map a 2M page immediately in any
 memory region, the mmap region has to be hugepage naturally
 aligned. posix_memalign() can provide that guarantee.
--- a/Documentation/admin-guide/mm/userfaultfd.rst
+++ b/Documentation/admin-guide/mm/userfaultfd.rst
@ -113,9 +113,6 @@ events, except page fault notifications, may be generated:
  areas. ``UFFD_FEATURE_MINOR_SHMEM`` is the analogous feature indicating
  support for shmem virtual memory areas.
 - ``UFFD_FEATURE_MOVE`` indicates that the kernel supports moving an
  existing page contents from userspace.
 The userland application should set the feature flags it intends to use
 when invoking the ``UFFDIO_API`` ioctl, to request that those features be
 enabled if supported.
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@ -296,30 +296,12 @@ kernel panic). This will output the contents of the ftrace buffers to
 the console.  This is very useful for capturing traces that lead to
 crashes and outputting them to a serial console.
-======================= ===========================================
+= ===================================================
 0 Disabled (default).
 1 Dump buffers of all CPUs.
-2(orig_cpu)             Dump the buffer of the CPU that triggered the
+2 Dump the buffer of the CPU that triggered the oops.
-                        oops.
+= ===================================================
 <instance>              Dump the specific instance buffer on all CPUs.
 <instance>=2(orig_cpu)  Dump the specific instance buffer on the CPU
                        that triggered the oops.
 ======================= ===========================================
 Multiple instance dump is also supported, and instances are separated
 by commas. If global buffer also needs to be dumped, please specify
 the dump mode (1/2/orig_cpu) first for global buffer.
 So for example to dump "foo" and "bar" instance buffer on all CPUs,
 user can::
  echo "foo,bar" > /proc/sys/kernel/ftrace_dump_on_oops
 To dump global buffer and "foo" instance buffer on all
 CPUs along with the "bar" instance buffer on CPU that triggered the
 oops, user can::
  echo "1,foo,bar=2" > /proc/sys/kernel/ftrace_dump_on_oops
 ftrace_enabled, stack_tracer_enabled
 ====================================
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@ -54,8 +54,6 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | Ampere         | AmpereOne       | AC03_CPU_38     | AMPERE_ERRATUM_AC03_CPU_38  |
 +----------------+-----------------+-----------------+-----------------------------+
 | Ampere         | AmpereOne AC04  | AC04_CPU_10     | AMPERE_ERRATUM_AC03_CPU_38  |
 +----------------+-----------------+-----------------+-----------------------------+
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Cortex-A510     | #2457168        | ARM64_ERRATUM_2457168       |
 +----------------+-----------------+-----------------+-----------------------------+
@ -141,8 +139,6 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Cortex-A715     | #2645198        | ARM64_ERRATUM_2645198       |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Cortex-A715     | #3456084        | ARM64_ERRATUM_3194386       |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Cortex-A720     | #3456091        | ARM64_ERRATUM_3194386       |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Cortex-A725     | #3456106        | ARM64_ERRATUM_3194386       |
@ -179,8 +175,6 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Neoverse-N2     | #3324339        | ARM64_ERRATUM_3194386       |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Neoverse-N3     | #3456111        | ARM64_ERRATUM_3194386       |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Neoverse-V1     | #3324341        | ARM64_ERRATUM_3194386       |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Neoverse-V2     | #3324336        | ARM64_ERRATUM_3194386       |
@ -284,5 +278,3 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | Microsoft      | Azure Cobalt 100| #2253138        | ARM64_ERRATUM_2253138       |
 +----------------+-----------------+-----------------+-----------------------------+
 | Microsoft      | Azure Cobalt 100| #3324339        | ARM64_ERRATUM_3194386       |
 +----------------+-----------------+-----------------+-----------------------------+
--- a/Documentation/block/inline-encryption.rst
+++ b/Documentation/block/inline-encryption.rst
@ -77,10 +77,10 @@ Basic design
 ============
 We introduce ``struct blk_crypto_key`` to represent an inline encryption key and
-how it will be used.  This includes the type of the key (standard or
+how it will be used.  This includes the actual bytes of the key; the size of the
-hardware-wrapped); the actual bytes of the key; the size of the key; the
+key; the algorithm and data unit size the key will be used with; and the number
-algorithm and data unit size the key will be used with; and the number of bytes
+of bytes needed to represent the maximum data unit number the key will be used
-needed to represent the maximum data unit number the key will be used with.
+with.
 We introduce ``struct bio_crypt_ctx`` to represent an encryption context.  It
 contains a data unit number and a pointer to a blk_crypto_key.  We add pointers
@ -301,216 +301,3 @@ kernel will pretend that the device does not support hardware inline encryption
 When the crypto API fallback is enabled, this means that all bios with and
 encryption context will use the fallback, and IO will complete as usual.  When
 the fallback is disabled, a bio with an encryption context will be failed.
 .. _hardware_wrapped_keys:
 Hardware-wrapped keys
 =====================
 Motivation and threat model
 ---------------------------
 Linux storage encryption (dm-crypt, fscrypt, eCryptfs, etc.) traditionally
 relies on the raw encryption key(s) being present in kernel memory so that the
 encryption can be performed.  This traditionally isn't seen as a problem because
 the key(s) won't be present during an offline attack, which is the main type of
 attack that storage encryption is intended to protect from.
 However, there is an increasing desire to also protect users' data from other
 types of attacks (to the extent possible), including:
 - Cold boot attacks, where an attacker with physical access to a system suddenly
  powers it off, then immediately dumps the system memory to extract recently
  in-use encryption keys, then uses these keys to decrypt user data on-disk.
 - Online attacks where the attacker is able to read kernel memory without fully
  compromising the system, followed by an offline attack where any extracted
  keys can be used to decrypt user data on-disk.  An example of such an online
  attack would be if the attacker is able to run some code on the system that
  exploits a Meltdown-like vulnerability but is unable to escalate privileges.
 - Online attacks where the attacker fully compromises the system, but their data
  exfiltration is significantly time-limited and/or bandwidth-limited, so in
  order to completely exfiltrate the data they need to extract the encryption
  keys to use in a later offline attack.
 Hardware-wrapped keys are a feature of inline encryption hardware that is
 designed to protect users' data from the above attacks (to the extent possible),
 without introducing limitations such as a maximum number of keys.
 Note that it is impossible to **fully** protect users' data from these attacks.
 Even in the attacks where the attacker "just" gets read access to kernel memory,
 they can still extract any user data that is present in memory, including
 plaintext pagecache pages of encrypted files.  The focus here is just on
 protecting the encryption keys, as those instantly give access to **all** user
 data in any following offline attack, rather than just some of it (where which
 data is included in that "some" might not be controlled by the attacker).
 Solution overview
 -----------------
 Inline encryption hardware typically has "keyslots" into which software can
 program keys for the hardware to use; the contents of keyslots typically can't
 be read back by software.  As such, the above security goals could be achieved
 if the kernel simply erased its copy of the key(s) after programming them into
 keyslot(s) and thereafter only referred to them via keyslot number.
 However, that naive approach runs into the problem that it limits the number of
 unlocked keys to the number of keyslots, which typically is a small number.  In
 cases where there is only one encryption key system-wide (e.g., a full-disk
 encryption key), that can be tolerable.  However, in general there can be many
 logged-in users with many different keys, and/or many running applications with
 application-specific encrypted storage areas.  This is especially true if
 file-based encryption (e.g. fscrypt) is being used.
 Thus, it is important for the kernel to still have a way to "remind" the
 hardware about a key, without actually having the raw key itself.  This would
 ensure that the number of hardware keyslots only limits the number of active I/O
 requests, not other things such as the number of logged-in users, the number of
 running apps, or the number of encrypted storage areas that apps can create.
 Somewhat less importantly, it is also desirable that the raw keys are never
 visible to software at all, even while being initially unlocked.  This would
 ensure that a read-only compromise of system memory will never allow a key to be
 extracted to be used off-system, even if it occurs when a key is being unlocked.
 To solve all these problems, some vendors of inline encryption hardware have
 made their hardware support *hardware-wrapped keys*.  Hardware-wrapped keys
 are encrypted keys that can only be unwrapped (decrypted) and used by hardware
 -- either by the inline encryption hardware itself, or by a dedicated hardware
 block that can directly provision keys to the inline encryption hardware.
 (We refer to them as "hardware-wrapped keys" rather than simply "wrapped keys"
 to add some clarity in cases where there could be other types of wrapped keys,
 such as in file-based encryption.  Key wrapping is a commonly used technique.)
 The key which wraps (encrypts) hardware-wrapped keys is a hardware-internal key
 that is never exposed to software; it is either a persistent key (a "long-term
 wrapping key") or a per-boot key (an "ephemeral wrapping key").  The long-term
 wrapped form of the key is what is initially unlocked, but it is erased from
 memory as soon as it is converted into an ephemerally-wrapped key.  In-use
 hardware-wrapped keys are always ephemerally-wrapped, not long-term wrapped.
 As inline encryption hardware can only be used to encrypt/decrypt data on-disk,
 the hardware also includes a level of indirection; it doesn't use the unwrapped
 key directly for inline encryption, but rather derives both an inline encryption
 key and a "software secret" from it.  Software can use the "software secret" for
 tasks that can't use the inline encryption hardware, such as filenames
 encryption.  The software secret is not protected from memory compromise.
 Key hierarchy
 -------------
 Here is the key hierarchy for a hardware-wrapped key::
                       Hardware-wrapped key
                                |
                                |
                          <Hardware KDF>
                                |
                  -----------------------------
                  |                           |
        Inline encryption key           Software secret
 The components are:
 - *Hardware-wrapped key*: a key for the hardware's KDF (Key Derivation
  Function), in ephemerally-wrapped form.  The key wrapping algorithm is a
  hardware implementation detail that doesn't impact kernel operation, but a
  strong authenticated encryption algorithm such as AES-256-GCM is recommended.
 - *Hardware KDF*: a KDF (Key Derivation Function) which the hardware uses to
  derive subkeys after unwrapping the wrapped key.  The hardware's choice of KDF
  doesn't impact kernel operation, but it does need to be known for testing
  purposes, and it's also assumed to have at least a 256-bit security strength.
  All known hardware uses the SP800-108 KDF in Counter Mode with AES-256-CMAC,
  with a particular choice of labels and contexts; new hardware should use this
  already-vetted KDF.
 - *Inline encryption key*: a derived key which the hardware directly provisions
  to a keyslot of the inline encryption hardware, without exposing it to
  software.  In all known hardware, this will always be an AES-256-XTS key.
  However, in principle other encryption algorithms could be supported too.
  Hardware must derive distinct subkeys for each supported encryption algorithm.
 - *Software secret*: a derived key which the hardware returns to software so
  that software can use it for cryptographic tasks that can't use inline
  encryption.  This value is cryptographically isolated from the inline
  encryption key, i.e. knowing one doesn't reveal the other.  (The KDF ensures
  this.)  Currently, the software secret is always 32 bytes and thus is suitable
  for cryptographic applications that require up to a 256-bit security strength.
  Some use cases (e.g. full-disk encryption) won't require the software secret.
 Example: in the case of fscrypt, the fscrypt master key (the key that protects a
 particular set of encrypted directories) is made hardware-wrapped.  The inline
 encryption key is used as the file contents encryption key, while the software
 secret (rather than the master key directly) is used to key fscrypt's KDF
 (HKDF-SHA512) to derive other subkeys such as filenames encryption keys.
 Note that currently this design assumes a single inline encryption key per
 hardware-wrapped key, without any further key derivation.  Thus, in the case of
 fscrypt, currently hardware-wrapped keys are only compatible with the "inline
 encryption optimized" settings, which use one file contents encryption key per
 encryption policy rather than one per file.  This design could be extended to
 make the hardware derive per-file keys using per-file nonces passed down the
 storage stack, and in fact some hardware already supports this; future work is
 planned to remove this limitation by adding the corresponding kernel support.
 Kernel support
 --------------
 The inline encryption support of the kernel's block layer ("blk-crypto") has
 been extended to support hardware-wrapped keys as an alternative to standard
 keys, when hardware support is available.  This works in the following way:
 - A ``key_types_supported`` field is added to the crypto capabilities in
  ``struct blk_crypto_profile``.  This allows device drivers to declare that
  they support standard keys, hardware-wrapped keys, or both.
 - ``struct blk_crypto_key`` can now contain a hardware-wrapped key as an
  alternative to a standard key; a ``key_type`` field is added to
  ``struct blk_crypto_config`` to distinguish between the different key types.
  This allows users of blk-crypto to en/decrypt data using a hardware-wrapped
  key in a way very similar to using a standard key.
 - A new method ``blk_crypto_ll_ops::derive_sw_secret`` is added.  Device drivers
  that support hardware-wrapped keys must implement this method.  Users of
  blk-crypto can call ``blk_crypto_derive_sw_secret()`` to access this method.
 - The programming and eviction of hardware-wrapped keys happens via
  ``blk_crypto_ll_ops::keyslot_program`` and
  ``blk_crypto_ll_ops::keyslot_evict``, just like it does for standard keys.  If
  a driver supports hardware-wrapped keys, then it must handle hardware-wrapped
  keys being passed to these methods.
 blk-crypto-fallback doesn't support hardware-wrapped keys.  Therefore,
 hardware-wrapped keys can only be used with actual inline encryption hardware.
 Currently, the kernel only works with hardware-wrapped keys in
 ephemerally-wrapped form.  No generic kernel interfaces are provided for
 generating or importing hardware-wrapped keys in the first place, or converting
 them to ephemerally-wrapped form.  In Android, SoC vendors are required to
 support these operations in their KeyMint implementation (a hardware abstraction
 layer in userspace); for details, see the `Android documentation
 <https://source.android.com/security/encryption/hw-wrapped-keys>`_.
 Testability
 -----------
 Both the hardware KDF and the inline encryption itself are well-defined
 algorithms that don't depend on any secrets other than the unwrapped key.
 Therefore, if the unwrapped key is known to software, these algorithms can be
 reproduced in software in order to verify the ciphertext that is written to disk
 by the inline encryption hardware.
 However, the unwrapped key will only be known to software for testing if the
 "import" functionality is used.  Proper testing is not possible in the
 "generate" case where the hardware generates the key itself.  The correct
 operation of the "generate" mode thus relies on the security and correctness of
 the hardware RNG and its use to generate the key, as well as the testing of the
 "import" mode as that should cover all parts other than the key generation.
 For an example of a test that verifies the ciphertext written to disk in the
 "import" mode, see the fscrypt hardware-wrapped key tests in xfstests, or
 `Android's vts_kernel_encryption_test
 <https://android.googlesource.com/platform/test/vts-testcase/kernel/+/refs/heads/master/encryption/>`_.
--- a/Documentation/core-api/maple_tree.rst
+++ b/Documentation/core-api/maple_tree.rst
@ -81,9 +81,6 @@ section.
 Sometimes it is necessary to ensure the next call to store to a maple tree does
 not allocate memory, please see :ref:`maple-tree-advanced-api` for this use case.
 You can use mtree_dup() to duplicate an entire maple tree. It is a more
 efficient way than inserting all elements one by one into a new tree.
 Finally, you can remove all entries from a maple tree by calling
 mtree_destroy().  If the maple tree entries are pointers, you may wish to free
 the entries first.
@ -115,7 +112,6 @@ Takes ma_lock internally:
 * mtree_insert()
 * mtree_insert_range()
 * mtree_erase()
 * mtree_dup()
 * mtree_destroy()
 * mt_set_in_rcu()
 * mt_clear_in_rcu()
--- a/Documentation/csf_sync_state_dump.txt
+++ b/Documentation/csf_sync_state_dump.txt
@ -1,55 +1,58 @@
-.. SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
 #
 # (C) COPYRIGHT 2022-2023 ARM Limited. All rights reserved.
 #
 # This program is free software and is provided to you under the terms of the
 # GNU General Public License version 2 as published by the Free Software
 # Foundation, and any use by you of this program is subject to the terms
 # of such GNU license.
 #
 # This program is distributed in the hope that it will be useful,
 # but WITHOUT ANY WARRANTY; without even the implied warranty of
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, you can access it online at
 # http://www.gnu.org/licenses/gpl-2.0.html.
 #
 #
-==================
+DebugFS interface:
-DebugFS interface
+------------------
 ==================
 **Copyright:** \(C) 2022-2024 ARM Limited. All rights reserved.
 ..
    This program is free software and is provided to you under the terms of the
    GNU General Public License version 2 as published by the Free Software
    Foundation, and any use by you of this program is subject to the terms
    of such GNU license.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    GNU General Public License for more details.
    You should have received a copy of the GNU General Public License
    along with this program; if not, you can access it online at
    http://www.gnu.org/licenses/gpl-2.0.html.
 A new per-kbase-context debugfs file called csf_sync has been implemented
 which captures the current KCPU & GPU queue state of the not-yet-completed
 operations and displayed through the debugfs file.
-This file is at
+This file is at:
 =======================================================
 /sys/kernel/debug/mali0/ctx/<pid>_<context id>/csf_sync
 =======================================================
-::
+Output Format:
-
+----------------
        /sys/kernel/debug/mali0/ctx/<pid>_<context id>/csf_sync
 Output Format
 -------------
 The csf_sync file contains important data for the currently active queues.
 This data is formatted into two segments, which are separated by a
 pipe character: the common properties and the operation-specific properties.
-Common Properties
+Common Properties:
-----------------
+------------------
 * Queue type: GPU or KCPU.
 * kbase context id and the queue id.
-* If the queue type is a GPU queue then the group handle is also noted,in the middle of the other two IDs. The slot value is also dumped.
+* If the queue type is a GPU queue then the group handle is also noted,
 in the middle of the other two IDs. The slot value is also dumped.
 * Execution status, which can either be 'P' for pending or 'S' for started.
-* Command type is then output which indicates the type of dependency (i.e. wait or signal).
+* Command type is then output which indicates the type of dependency
-* Object address which is a pointer to the sync object that the command operates on.
+(i.e. wait or signal).
 * Object address which is a pointer to the sync object that the
 command operates on.
 * The live value, which is the value of the synchronization object
 at the time of dumping. This could help to determine why wait
 operations might be blocked.
-* The live value, which is the value of the synchronization object at the time of dumping. This could help to determine why wait operations might be blocked.
+Operation-Specific Properties:
 Operation-Specific Properties
 ------------------------------
 The operation-specific values for KCPU queue fence operations
@ -64,49 +67,48 @@ which are always shown; the argument value to wait on or set/add to,
 and the operation type (set/add) or wait condition (e.g. LE, GT, GE).
 Examples
-========
+--------
 GPU Queue Example
 ------------------
 The following output is of a GPU queue, from a process that has a KCTX ID of 52,
 is in Queue Group (CSG) 0, and has Queue ID 0. It has started and is waiting on
-the object at address **0x0000007f81ffc800**. The live value is 0,
+the object at address 0x0000007f81ffc800. The live value is 0,
 as is the arg value. However, the operation "op" is GT, indicating it's waiting
 for the live value to surpass the arg value:
-::
+======================================================================================================================================
-
+queue:GPU-52-0-0 exec:S cmd:SYNC_WAIT slot:4 obj:0x0000007f81ffc800 live_value:0x0000000000000000 | op:gt arg_value:0x0000000000000000
-        queue:GPU-52-0-0 exec:S cmd:SYNC_WAIT slot:4 obj:0x0000007f81ffc800 live_value:0x0000000000000000 | op:gt arg_value:0x0000000000000000
+======================================================================================================================================
 The following is an example of GPU queue dump, where the SYNC SET operation
 is blocked by the preceding SYNC WAIT operation. This shows two GPU queues,
 with the same KCTX ID of 8, Queue Group (CSG) 0, and Queue ID 0. The SYNC WAIT
 operation has started, while the SYNC SET is pending, blocked by the SYNC WAIT.
 Both operations are on the same slot, 2 and have live value of 0. The SYNC WAIT
-is waiting on the object at address **0x0000007f81ffc800**, while the SYNC SET will
+is waiting on the object at address 0x0000007f81ffc800, while the SYNC SET will
-set the object at address **0x00000000a3bad4fb** when it is unblocked.
+set the object at address 0x00000000a3bad4fb when it is unblocked.
 The operation "op" is GT for the SYNC WAIT, indicating it's waiting for the
 live value to surpass the arg value, while the operation and arg value for the
-SYNC SET is "set" and "1" respectively.
+SYNC SET is "set" and "1" respectively:
-::
+======================================================================================================================================
-
+queue:GPU-8-0-0 exec:S cmd:SYNC_WAIT slot:2 obj:0x0000007f81ffc800 live_value:0x0000000000000000 | op:gt arg_value:0x0000000000000000
-        queue:GPU-8-0-0 exec:S cmd:SYNC_WAIT slot:2 obj:0x0000007f81ffc800 live_value:0x0000000000000000 | op:gt arg_value:0x0000000000000000
+queue:GPU-8-0-0 exec:P cmd:SYNC_SET slot:2 obj:0x00000000a3bad4fb live_value:0x0000000000000000 | op:set arg_value:0x0000000000000001
-        queue:GPU-8-0-0 exec:P cmd:SYNC_SET slot:2 obj:0x00000000a3bad4fb live_value:0x0000000000000000 | op:set arg_value:0x0000000000000001
+======================================================================================================================================
 KCPU Queue Example
 ------------------
 The following is an example of a KCPU queue, from a process that has
 a KCTX ID of 0 and has Queue ID 1. It has started and is waiting on the
-object at address **0x0000007fbf6f2ff8**. The live value is currently 0 with
+object at address 0x0000007fbf6f2ff8. The live value is currently 0 with
 the "op" being GT indicating it is waiting on the live value to
 surpass the arg value.
-::
+===============================================================================================================================
-
+queue:KCPU-0-1 exec:S cmd:CQS_WAIT_OPERATION obj:0x0000007fbf6f2ff8 live_value:0x0000000000000000 | op:gt arg_value: 0x00000000
-        queue:KCPU-0-1 exec:S cmd:CQS_WAIT_OPERATION obj:0x0000007fbf6f2ff8 live_value:0x0000000000000000 | op:gt arg_value: 0x00000000
+===============================================================================================================================
 CSF Sync State Dump For Fence Signal Timeouts
 ---------------------------------------------
@ -140,23 +142,18 @@ which is written to, to turn this feature on and off.
 Example:
 --------
-when writing to fence_signal_timeout_enable entry
+when writing to fence_signal_timeout_enable entry:
-
+echo 1 > /sys/kernel/debug/mali0/fence_signal_timeout_enable -> feature is enabled.
-::
+echo 0 > /sys/kernel/debug/mali0/fence_signal_timeout_enable -> feature is disabled.
        echo 1 > /sys/kernel/debug/mali0/fence_signal_timeout_enable -> feature is enabled.
        echo 0 > /sys/kernel/debug/mali0/fence_signal_timeout_enable -> feature is disabled.
 It is also possible to read from this file to check if the feature is currently
 enabled or not checking the return value of fence_signal_timeout_enable.
 Example:
 --------
-when reading from fence_signal_timeout_enable entry, if
+when reading from fence_signal_timeout_enable entry, if:
-::
+cat /sys/kernel/debug/mali0/fence_signal_timeout_enable returns 1 -> feature is enabled.
-
+cat /sys/kernel/debug/mali0/fence_signal_timeout_enable returns 0 -> feature is disabled.
        cat /sys/kernel/debug/mali0/fence_signal_timeout_enable returns 1 -> feature is enabled.
        cat /sys/kernel/debug/mali0/fence_signal_timeout_enable returns 0 -> feature is disabled.
 Update Timer Duration
 ---------------------
@ -166,15 +163,11 @@ milliseconds.
 Example:
 --------
-::
+cat /sys/kernel/debug/mali0/fence_signal_timeout_ms
        cat /sys/kernel/debug/mali0/fence_signal_timeout_ms
 The 'fence_signal_timeout_ms' debugfs entry can also be written to, to update
 the time in milliseconds.
 Example:
 --------
-::
+echo 10000 > /sys/kernel/debug/mali0/fence_signal_timeout_ms
        echo 10000 > /sys/kernel/debug/mali0/fence_signal_timeout_ms
--- a/Documentation/dev-tools/kselftest.rst
+++ b/Documentation/dev-tools/kselftest.rst
@ -255,21 +255,9 @@ Contributing new tests (details)
   TEST_PROGS_EXTENDED, TEST_GEN_PROGS_EXTENDED mean it is the
   executable which is not tested by default.
   TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
   test.
   TEST_INCLUDES is similar to TEST_FILES, it lists files which should be
   included when exporting or installing the tests, with the following
   differences:
    * symlinks to files in other directories are preserved
    * the part of paths below tools/testing/selftests/ is preserved when
      copying the files to the output directory
   TEST_INCLUDES is meant to list dependencies located in other directories of
   the selftests hierarchy.
 * First use the headers inside the kernel source and/or git repo, and then the
   system headers.  Headers for the kernel release as opposed to headers
   installed by the distro on the system should be the primary focus to be able
--- a/Documentation/dev-tools/kunit/index.rst
+++ b/Documentation/dev-tools/kunit/index.rst
@ -18,15 +18,6 @@ KUnit - Linux Kernel Unit Testing
 	faq
 	running_tips
 .. warning::
 	AOSP only supports running tests loaded with modules. Built-in
 	test execution support has been disabled. In addition, in order
 	to fully enable running module loaded tests both CONFIG_KUNIT
 	needs to be enabled and kernel command line  argument
 	`kunit.enable` needs to be set to 1.
 	The remaining KUnit documentation has been left as-is.
 This section details the kernel unit testing framework.
 Introduction
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@ -651,16 +651,12 @@ For example:
 	}
 Note that, for functions like device_unregister which only accept a single
-pointer-sized argument, it's possible to automatically generate a wrapper
+pointer-sized argument, it's possible to directly cast that function to
-with the ``KUNIT_DEFINE_ACTION_WRAPPER()`` macro, for example:
+a ``kunit_action_t`` rather than writing a wrapper function, for example:
 .. code-block:: C
-	KUNIT_DEFINE_ACTION_WRAPPER(device_unregister, device_unregister_wrapper, struct device *);
+	kunit_add_action(test, (kunit_action_t *)&device_unregister, &dev);
 	kunit_add_action(test, &device_unregister_wrapper, &dev);
 You should do this in preference to manually casting to the ``kunit_action_t`` type,
 as casting function pointers will break Control Flow Integrity (CFI).
 ``kunit_add_action`` can fail if, for example, the system is out of memory.
 You can use ``kunit_add_action_or_reset`` instead which runs the action
--- a/Documentation/device-mapper/dm-bow.txt
+++ b/Documentation/device-mapper/dm-bow.txt
@ -1,99 +0,0 @@
 dm_bow (backup on write)
 ========================
 dm_bow is a device mapper driver that uses the free space on a device to back up
 data that is overwritten. The changes can then be committed by a simple state
 change, or rolled back by removing the dm_bow device and running a command line
 utility over the underlying device.
 dm_bow has three states, set by writing ‘1’ or ‘2’ to /sys/block/dm-?/bow/state.
 It is only possible to go from state 0 (initial state) to state 1, and then from
 state 1 to state 2.
 State 0: dm_bow collects all trims to the device and assumes that these mark
 free space on the overlying file system that can be safely used. Typically the
 mount code would create the dm_bow device, mount the file system, call the
 FITRIM ioctl on the file system then switch to state 1. These trims are not
 propagated to the underlying device.
 State 1: All writes to the device cause the underlying data to be backed up to
 the free (trimmed) area as needed in such a way as they can be restored.
 However, the writes, with one exception, then happen exactly as they would
 without dm_bow, so the device is always in a good final state. The exception is
 that sector 0 is used to keep a log of the latest changes, both to indicate that
 we are in this state and to allow rollback. See below for all details. If there
 isn't enough free space, writes are failed with -ENOSPC.
 State 2: The transition to state 2 triggers replacing the special sector 0 with
 the normal sector 0, and the freeing of all state information. dm_bow then
 becomes a pass-through driver, allowing the device to continue to be used with
 minimal performance impact.
 Usage
 =====
 dm-bow takes one command line parameter, the name of the underlying device.
 dm-bow will typically be used in the following way. dm-bow will be loaded with a
 suitable underlying device and the resultant device will be mounted. A file
 system trim will be issued via the FITRIM ioctl, then the device will be
 switched to state 1. The file system will now be used as normal. At some point,
 the changes can either be committed by switching to state 2, or rolled back by
 unmounting the file system, removing the dm-bow device and running the command
 line utility. Note that rebooting the device will be equivalent to unmounting
 and removing, but the command line utility must still be run
 Details of operation in state 1
 ===============================
 dm_bow maintains a type for all sectors. A sector can be any of:
 SECTOR0
 SECTOR0_CURRENT
 UNCHANGED
 FREE
 CHANGED
 BACKUP
 SECTOR0 is the first sector on the device, and is used to hold the log of
 changes. This is the one exception.
 SECTOR0_CURRENT is a sector picked from the FREE sectors, and is where reads and
 writes from the true sector zero are redirected to. Note that like any backup
 sector, if the sector is written to directly, it must be moved again.
 UNCHANGED means that the sector has not been changed since we entered state 1.
 Thus if it is written to or trimmed, the contents must first be backed up.
 FREE means that the sector was trimmed in state 0 and has not yet been written
 to or used for backup. On being written to, a FREE sector is changed to CHANGED.
 CHANGED means that the sector has been modified, and can be further modified
 without further backup.
 BACKUP means that this is a free sector being used as a backup. On being written
 to, the contents must first be backed up again.
 All backup operations are logged to the first sector. The log sector has the
 format:
 --------------------------------------------------------
 | Magic | Count | Sequence | Log entry | Log entry | …
 --------------------------------------------------------
 Magic is a magic number. Count is the number of log entries. Sequence is 0
 initially. A log entry is
 -----------------------------------
 | Source | Dest | Size | Checksum |
 -----------------------------------
 When SECTOR0 is full, the log sector is backed up and another empty log sector
 created with sequence number one higher. The first entry in any log entry with
 sequence > 0 therefore must be the log of the backing up of the previous log
 sector. Note that sequence is not strictly needed, but is a useful sanity check
 and potentially limits the time spent trying to restore a corrupted snapshot.
 On entering state 1, dm_bow has a list of free sectors. All other sectors are
 unchanged. Sector0_current is selected from the free sectors and the contents of
 sector 0 are copied there. The sector 0 is backed up, which triggers the first
 log entry to be written.
--- a/Documentation/devicetree/bindings/arm/arm,coresight-mali-source.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-mali-source.yaml
@ -1,163 +0,0 @@
 # SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
 #
 # (C) COPYRIGHT 2022-2024 ARM Limited. All rights reserved.
 #
 # This program is free software and is provided to you under the terms of the
 # GNU General Public License version 2 as published by the Free Software
 # Foundation, and any use by you of this program is subject to the terms
 # of such GNU license.
 #
 # This program is distributed in the hope that it will be useful,
 # but WITHOUT ANY WARRANTY; without even the implied warranty of
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, you can access it online at
 # http://www.gnu.org/licenses/gpl-2.0.html.
 #
 #
 %YAML 1.2
 ---
 $id: http://devicetree.org/schemas/arm/arm,coresight-mali-source.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: ARM CoreSight Mali Source integration
 maintainers:
  - ARM Ltd.
 description: |
  See Documentation/trace/coresight/coresight.rst for detailed information
  about Coresight.
  This documentation will cover Mali specific devicetree integration.
  References to Sink ports are given as examples. Access to Sink is specific
  to an implementation and would require dedicated kernel modules.
  Arm Mali GPU are supporting 3 different sources: ITM, ETM, ELA
  ELA source configuration via SysFS entries:
    The register values used by CoreSight for ELA can be configured using SysFS
    interfaces. This implicitly includes configuring the ELA for independent or
    shared JCN request and response channels.
 properties:
  compatible:
    enum:
      - arm,coresight-mali-source-itm
      - arm,coresight-mali-source-etm
      - arm,coresight-mali-source-ela
  gpu:
    minItems: 1
    maxItems: 1
    description:
      Phandle to a Mali GPU definition
  port:
    description:
      Output connection to CoreSight Sink Trace bus.
      Legacy binding between Coresight Sources and CoreSight Sink.
      For Linux kernel < v4.20.
    $ref: /schemas/graph.yaml#/properties/port
  out-ports:
    description:
      Binding between Coresight Sources and CoreSight Sink.
      For Linux kernel >= v4.20.
    $ref: /schemas/graph.yaml#/properties/ports
    properties:
      port:
        description: Output connection to CoreSight Sink Trace bus.
        $ref: /schemas/graph.yaml#/properties/port
 required:
  - compatible
  - gpu
  - port
  - out-ports
 additionalProperties: false
 examples:
 # A Sink node without legacy CoreSight connections
  - |
    mali-source-itm {
        compatible = "arm,coresight-mali-source-itm";
        gpu = <&gpu>;
        out-ports {
            port {
                mali_source_itm_out_port0: endpoint {
                    remote-endpoint = <&mali_sink_in_port0>;
                };
            };
        };
    };
    mali-source-ela {
        compatible = "arm,coresight-mali-source-ela";
        gpu = <&gpu>;
        out-ports {
            port {
                mali_source_ela_out_port0: endpoint {
                    remote-endpoint = <&mali_sink_in_port1>;
                };
            };
        };
    };
    mali-source-etm {
        compatible = "arm,coresight-mali-source-etm";
        gpu = <&gpu>;
        out-ports {
            port {
                mali_source_etm_out_port0: endpoint {
                    remote-endpoint = <&mali_sink_in_port2>;
                };
            };
        };
    };
 # A Sink node with legacy CoreSight connections
  - |
    mali-source-itm {
        compatible = "arm,coresight-mali-source-itm";
        gpu = <&gpu>;
        port {
            mali_source_itm_out_port0: endpoint {
                remote-endpoint = <&mali_sink_in_port0>;
            };
        };
    };
    mali-source-etm {
        compatible = "arm,coresight-mali-source-etm";
        gpu = <&gpu>;
        port {
            mali_source_etm_out_port0: endpoint {
                remote-endpoint = <&mali_sink_in_port1>;
            };
        };
    };
    mali-source-ela {
        compatible = "arm,coresight-mali-source-ela";
        gpu = <&gpu>;
        port {
            mali_source_ela_out_port0: endpoint {
                remote-endpoint = <&mali_sink_in_port2>;
            };
        };
    };
--- a/Documentation/devicetree/bindings/arm/mali-coresight-source.txt
+++ b/Documentation/devicetree/bindings/arm/mali-coresight-source.txt
@ -0,0 +1,116 @@
 # SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
 #
 # (C) COPYRIGHT 2023 ARM Limited. All rights reserved.
 #
 # This program is free software and is provided to you under the terms of the
 # GNU General Public License version 2 as published by the Free Software
 # Foundation, and any use by you of this program is subject to the terms
 # of such GNU license.
 #
 # This program is distributed in the hope that it will be useful,
 # but WITHOUT ANY WARRANTY; without even the implied warranty of
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, you can access it online at
 # http://www.gnu.org/licenses/gpl-2.0.html.
 #
 #
 =====================================
 ARM CoreSight Mali Source integration
 =====================================
 See Documentation/trace/coresight/coresight.rst for detailed information
 about Coresight.
 This documentation will cover Mali specific devicetree integration.
 References to Sink ports are given as examples. Access to Sink is specific
 to an implementation and would require dedicated kernel modules.
 ARM Coresight Mali Source ITM
 =============================
 Required properties
 -------------------
 - compatible: Has to be "arm,coresight-mali-source-itm"
 - gpu : phandle to a Mali GPU definition
 - port:
  - endpoint:
    - remote-endpoint: phandle to a Coresight sink port
 Example
 -------
 mali-source-itm {
  compatible = "arm,coresight-mali-source-itm";
  gpu = <&gpu>;
  port {
    mali_source_itm_out_port0: endpoint {
      remote-endpoint = <&mali_sink_in_port0>;
    };
  };
 };
 ARM Coresight Mali Source ETM
 =============================
 Required properties
 -------------------
 - compatible: Has to be "arm,coresight-mali-source-etm"
 - gpu : phandle to a Mali GPU definition
 - port:
  - endpoint:
    - remote-endpoint: phandle to a Coresight sink port
 Example
 -------
 mali-source-etm {
  compatible = "arm,coresight-mali-source-etm";
  gpu = <&gpu>;
  port {
    mali_source_etm_out_port0: endpoint {
      remote-endpoint = <&mali_sink_in_port1>;
    };
  };
 };
 ARM Coresight Mali Source ELA
 =============================
 Required properties
 -------------------
 - compatible: Has to be "arm,coresight-mali-source-ela"
 - gpu : phandle to a Mali GPU definition
 - port:
  - endpoint:
    - remote-endpoint: phandle to a Coresight sink port
 Example: Split JCN request/response channel
 --------------------------------------------
 This examples applies to implementations with a total of 5 signal groups,
 where JCN request and response are assigned to independent or shared
 channels depending on the GPU model.
 mali-source-ela {
  compatible = "arm,coresight-mali-source-ela";
  gpu = <&gpu>;
  port {
    mali_source_ela_out_port0: endpoint {
      remote-endpoint = <&mali_sink_in_port2>;
    };
  };
 };
 SysFS Configuration
 --------------------------------------------
 The register values used by CoreSight for ELA can be configured using SysFS
 interfaces. This implicitly includes configuring the ELA for independent or
 shared JCN request and response channels.
--- a/Documentation/devicetree/bindings/arm/mali-midgard.txt
+++ b/Documentation/devicetree/bindings/arm/mali-midgard.txt
@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
 #
-# (C) COPYRIGHT 2013-2024 ARM Limited. All rights reserved.
+# (C) COPYRIGHT 2013-2023 ARM Limited. All rights reserved.
 #
 # This program is free software and is provided to you under the terms of the
 # GNU General Public License version 2 as published by the Free Software
@ -35,21 +35,14 @@ Optional:
 - clocks : One or more pairs of phandle to clock and clock specifier
           for the Mali device. The order is important: the first clock
-           shall correspond to the "clk_mali" source. Other clocks are optional
+           shall correspond to the "clk_mali" source, while the second clock
-           and, if present, they shall correspond to domains like "shadercores",
+           (that is optional) shall correspond to the "shadercores" source.
-           which is available for all GPUs, or "coregroup" and "neuralengines"
+- clock-names : Shall be set to: "clk_mali", "shadercores".
           which are available for newer GPUs. Also notice that the "neuralengines"
           clock domain, if present, doesn't expect a corresponding regulator.
 - clock-names : Shall be set to values like: "clk_mali", "shadercores", "coregroup",
                "neuralengines". Only the first one is mandatory. Most GPUs
                support only the first two entries.
 - mali-supply : Phandle to the top level regulator for the Mali device.
                Refer to
 Documentation/devicetree/bindings/regulator/regulator.txt for details.
 - shadercores-supply : Phandle to shader cores regulator for the Mali device.
                       This is optional.
 - coregroup-supply: Phandle to core group regulator for the Mali device.
                    This is optional and only available on newer GPUs.
 - operating-points-v2 : Refer to Documentation/devicetree/bindings/power/mali-opp.txt
 for details.
 - quirks-gpu : Used to write to the JM_CONFIG or CSF_CONFIG register.
@ -140,10 +133,6 @@ for details.
 		   set and the setting coresponding to the SYSC_ALLOC register.
 - propagate-bits: Used to write to L2_CONFIG.PBHA_HWU. This bitset establishes which
 		   PBHA bits are propagated on the AXI bus.
 - mma-wa-id: Sets the PBHA ID to be used for the PBHA override based MMA violation workaround.
 	     The read and write allocation override bits for the PBHA are set to NONCACHEABLE
 	     and the driver encodes the PBHA ID in the PTEs where this workaround is to be applied.
 	     Valid values are from 1 to 15.
 Example for a Mali GPU with 1 clock and 1 regulator:
@ -253,7 +242,6 @@ gpu@0xfc010000 {
    pbha {
        int-id-override = <2 0x32>, <9 0x05>, <16 0x32>;
        propagate-bits = /bits/ 8 <0x03>;
        mma-wa-id = <2>;
    };
    ...
 };
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@ -231,46 +231,6 @@ properties:
      SNK_READY for non-pd link.
    type: boolean
  sink-wait-cap-time-ms:
    description: Represents the max time in ms that USB Type-C port (in sink
      role) should wait for the port partner (source role) to send source caps.
      SinkWaitCap timer starts when port in sink role attaches to the source.
      This timer will stop when sink receives PD source cap advertisement before
      timeout in which case it'll move to capability negotiation stage. A
      timeout leads to a hard reset message by the port.
    minimum: 310
    maximum: 620
    default: 310
  ps-source-off-time-ms:
    description: Represents the max time in ms that a DRP in source role should
      take to turn off power after the PsSourceOff timer starts. PsSourceOff
      timer starts when a sink's PHY layer receives EOP of the GoodCRC message
      (corresponding to an Accept message sent in response to a PR_Swap or a
      FR_Swap request). This timer stops when last bit of GoodCRC EOP
      corresponding to the received PS_RDY message is transmitted by the PHY
      layer. A timeout shall lead to error recovery in the type-c port.
    minimum: 750
    maximum: 920
    default: 920
  cc-debounce-time-ms:
    description: Represents the max time in ms that a port shall wait to
      determine if it's attached to a partner.
    minimum: 100
    maximum: 200
    default: 200
  sink-bc12-completion-time-ms:
    description: Represents the max time in ms that a port in sink role takes
      to complete Battery Charger (BC1.2) Detection. BC1.2 detection is a
      hardware mechanism, which in some TCPC implementations, can run in
      parallel once the Type-C connection state machine reaches the "potential
      connect as sink" state. In TCPCs where this causes delays to respond to
      the incoming PD messages, sink-bc12-completion-time-ms is used to delay
      PD negotiation till BC1.2 detection completes.
    default: 0
 dependencies:
  sink-vdos-v1: [ sink-vdos ]
  sink-vdos: [ sink-vdos-v1 ]
@ -356,7 +316,7 @@ examples:
    };
  # USB-C connector attached to a typec port controller(ptn5110), which has
-  # power delivery support, explicitly defines time properties and enables drp.
+  # power delivery support and enables drp.
  - |
    #include <dt-bindings/usb/pd.h>
    typec: ptn5110 {
@ -369,10 +329,6 @@ examples:
            sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)
                         PDO_VAR(5000, 12000, 2000)>;
            op-sink-microwatt = <10000000>;
            sink-wait-cap-time-ms = <465>;
            ps-source-off-time-ms = <835>;
            cc-debounce-time-ms = <101>;
            sink-bc12-completion-time-ms = <500>;
        };
    };
--- a/Documentation/devicetree/bindings/cpufreq/qemu,virtual-cpufreq.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/qemu,virtual-cpufreq.yaml
@ -1,48 +0,0 @@
 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
 %YAML 1.2
 ---
 $id: http://devicetree.org/schemas/cpufreq/qemu,virtual-cpufreq.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: Virtual CPUFreq
 maintainers:
  - David Dai <davidai@google.com>
  - Saravana Kannan <saravanak@google.com>
 description:
  Virtual CPUFreq is a virtualized driver in guest kernels that sends performance
  selection of its vCPUs as a hint to the host through MMIO regions. Each vCPU
  is associated with a performance domain which can be shared with other vCPUs.
  Each performance domain has its own set of registers for performance controls.
 properties:
  compatible:
    const: qemu,virtual-cpufreq
  reg:
    maxItems: 1
    description:
      Address and size of region containing performance controls for each of the
      performance domains. Regions for each performance domain is placed
      contiguously and contain registers for controlling DVFS(Dynamic Frequency
      and Voltage) characteristics. The size of the region is proportional to
      total number of performance domains.
 required:
  - compatible
  - reg
 additionalProperties: false
 examples:
  - |
    soc {
      #address-cells = <1>;
      #size-cells = <1>;
      cpufreq@1040000 {
        compatible = "qemu,virtual-cpufreq";
        reg = <0x1040000 0x2000>;
      };
    };
--- a/Documentation/devicetree/bindings/cpufreq/virtual,android-v-only-cpufreq.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/virtual,android-v-only-cpufreq.yaml
@ -1,111 +0,0 @@
 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
 %YAML 1.2
 ---
 $id: http://devicetree.org/schemas/cpufreq/virtual,android-v-only-cpufreq.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: Android-V-Only Virtual CPUFreq
 maintainers:
  - David Dai <davidai@google.com>
  - Saravana Kannan <saravanak@google.com>
 description:
  Android-V-Only Virtual CPUFreq is a virtualized driver in guest kernels that
  sends frequency selection of its vCPUs as a hint to the host through MMIO
  regions.  Each vCPU is associated with a frequency domain which can be shared
  with other vCPUs.  Each frequency domain has its own set of registers for
  frequency controls.
 properties:
  compatible:
    const: virtual,android-v-only-cpufreq
  reg:
    maxItems: 1
    description:
      Address and size of region containing frequency controls for each of the
      frequency domains. Regions for each frequency domain is placed
      contiguously and contain registers for controlling DVFS(Dynamic Frequency
      and Voltage) characteristics. The size of the region is proportional to
      total number of frequency domains. This device also needs the CPUs to
      list their OPPs using operating-points-v2 tables. The OPP tables for the
      CPUs should use normalized "frequency" values where the OPP with the
      highest performance among all the vCPUs is listed as 1024 KHz. The rest
      of the frequencies of all the vCPUs should be normalized based on their
      performance relative to that 1024 KHz OPP. This makes it much easier to
      migrate the VM across systems which might have different physical CPU
      OPPs.
 required:
  - compatible
  - reg
 additionalProperties: false
 examples:
  - |
    // This example shows a two CPU configuration with a frequency domain
    // for each CPU showing normalized performance points.
    cpus {
      #address-cells = <1>;
      #size-cells = <0>;
      cpu@0 {
        compatible = "arm,armv8";
        device_type = "cpu";
        reg = <0x0>;
        operating-points-v2 = <&opp_table0>;
      };
      cpu@1 {
        compatible = "arm,armv8";
        device_type = "cpu";
        reg = <0x0>;
        operating-points-v2 = <&opp_table1>;
      };
    };
    opp_table0: opp-table-0 {
      compatible = "operating-points-v2";
      opp64000 { opp-hz = /bits/ 64 <64000>; };
      opp128000 { opp-hz = /bits/ 64 <128000>; };
      opp192000 { opp-hz = /bits/ 64 <192000>; };
      opp256000 { opp-hz = /bits/ 64 <256000>; };
      opp320000 { opp-hz = /bits/ 64 <320000>; };
      opp384000 { opp-hz = /bits/ 64 <384000>; };
      opp425000 { opp-hz = /bits/ 64 <425000>; };
    };
    opp_table1: opp-table-1 {
      compatible = "operating-points-v2";
      opp64000 { opp-hz = /bits/ 64 <64000>; };
      opp128000 { opp-hz = /bits/ 64 <128000>; };
      opp192000 { opp-hz = /bits/ 64 <192000>; };
      opp256000 { opp-hz = /bits/ 64 <256000>; };
      opp320000 { opp-hz = /bits/ 64 <320000>; };
      opp384000 { opp-hz = /bits/ 64 <384000>; };
      opp448000 { opp-hz = /bits/ 64 <448000>; };
      opp512000 { opp-hz = /bits/ 64 <512000>; };
      opp576000 { opp-hz = /bits/ 64 <576000>; };
      opp640000 { opp-hz = /bits/ 64 <640000>; };
      opp704000 { opp-hz = /bits/ 64 <704000>; };
      opp768000 { opp-hz = /bits/ 64 <768000>; };
      opp832000 { opp-hz = /bits/ 64 <832000>; };
      opp896000 { opp-hz = /bits/ 64 <896000>; };
      opp960000 { opp-hz = /bits/ 64 <960000>; };
      opp1024000 { opp-hz = /bits/ 64 <1024000>; };
    };
    soc {
      #address-cells = <1>;
      #size-cells = <1>;
      cpufreq@1040000 {
        compatible = "virtual,android-v-only-cpufreq";
        reg = <0x1040000 0x10>;
      };
    };
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@ -69,17 +69,14 @@ properties:
          - const: tx
          - const: tx_reply
          - const: rx
          - const: rx_reply
        minItems: 2
  mboxes:
    description:
      List of phandle and mailbox channel specifiers. It should contain
-      exactly one, two, three or four mailboxes; the first one or two for
+      exactly one, two or three mailboxes; the first one or two for transmitting
-      transmitting messages ("tx") and another optional ("rx") for receiving
+      messages ("tx") and another optional ("rx") for receiving notifications
-      notifications and delayed responses, if supported by the platform.
+      and delayed responses, if supported by the platform.
      The optional ("rx_reply") is for notifications completion interrupt,
      if supported by the platform.
      The number of mailboxes needed for transmitting messages depends on the
      type of channels exposed by the specific underlying mailbox controller;
      one single channel descriptor is enough if such channel is bidirectional,
@ -92,10 +89,9 @@ properties:
       2 mbox / 2 shmem => SCMI TX and RX over 2 mailbox bidirectional channels
       2 mbox / 1 shmem => SCMI TX over 2 mailbox unidirectional channels
       3 mbox / 2 shmem => SCMI TX and RX over 3 mailbox unidirectional channels
       4 mbox / 2 shmem => SCMI TX and RX over 4 mailbox unidirectional channels
      Any other combination of mboxes and shmem is invalid.
    minItems: 1
-    maxItems: 4
+    maxItems: 3
  shmem:
    description:
@ -118,13 +114,6 @@ properties:
      atomic mode of operation, even if requested.
    default: 0
  max-rx-timeout-ms:
    description:
      An optional time value, expressed in milliseconds, representing the
      transport maximum timeout value for the receive channel. The value should
      be a non-zero value if set.
    minimum: 1
  arm,smc-id:
    $ref: /schemas/types.yaml#/definitions/uint32
    description:
@ -251,30 +240,32 @@ properties:
  protocol@19:
    type: object
    allOf:
-      - $ref: '#/$defs/protocol-node'
+      - $ref: "#/$defs/protocol-node"
-      - $ref: /schemas/pinctrl/pinctrl.yaml
+      - $ref: "../pinctrl/pinctrl.yaml"
    unevaluatedProperties: false
    properties:
      reg:
        const: 0x19
      '#pinctrl-cells':
        const: 0
    patternProperties:
      '-pins$':
        type: object
        allOf:
-          - $ref: /schemas/pinctrl/pincfg-node.yaml#
+          - $ref: "../pinctrl/pincfg-node.yaml#"
-          - $ref: /schemas/pinctrl/pinmux-node.yaml#
+          - $ref: "../pinctrl/pinmux-node.yaml#"
        unevaluatedProperties: false
        description:
-          A pin multiplexing sub-node describes how to configure a
+          A pin multiplexing sub-node describe how to configure a
-          set of pins in some desired function.
+          set of pins is some desired function.
          A single sub-node may define several pin configurations.
-          This sub-node is using the default pinctrl bindings to configure
+          This sub-node is using default pinctrl bindings to configure
-          pin multiplexing and using SCMI protocol to apply a specified
+          pin multiplexing and using SCMI protocol to apply specified
-          configuration.
+          configuration using SCMI protocol.
    required:
      - reg
@ -435,19 +426,20 @@ examples:
            scmi_pinctrl: protocol@19 {
                reg = <0x19>;
                #pinctrl-cells = <0>;
                i2c2-pins {
-                    groups = "g_i2c2_a", "g_i2c2_b";
+                    groups = "i2c2_a", "i2c2_b";
-                    function = "f_i2c2";
+                    function = "i2c2";
                };
                mdio-pins {
-                    groups = "g_avb_mdio";
+                    groups = "avb_mdio";
                    drive-strength = <24>;
                };
                keys_pins: keys-pins {
-                    pins = "gpio_5_17", "gpio_5_20", "gpio_5_22", "gpio_2_1";
+                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
                    bias-pull-up;
                };
            };
--- a/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
+++ b/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
@ -1,82 +0,0 @@
 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
 %YAML 1.2
 ---
 $id: http://devicetree.org/schemas/firmware/gunyah-hypervisor.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: Gunyah Hypervisor
 maintainers:
  - Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
  - Elliot Berman <quic_eberman@quicinc.com>
 description: |+
  Gunyah virtual machines use this information to determine the capability IDs
  of the message queues used to communicate with the Gunyah Resource Manager.
  See also: https://github.com/quic/gunyah-resource-manager/blob/develop/src/vm_creation/dto_construct.c
 properties:
  compatible:
    const: gunyah-hypervisor
  "#address-cells":
    description: Number of cells needed to represent 64-bit capability IDs.
    const: 2
  "#size-cells":
    description: must be 0, because capability IDs are not memory address
                  ranges and do not have a size.
    const: 0
 patternProperties:
  "^gunyah-resource-mgr(@.*)?":
    type: object
    description:
      Resource Manager node which is required to communicate to Resource
      Manager VM using Gunyah Message Queues.
    properties:
      compatible:
        const: gunyah-resource-manager
      reg:
        items:
          - description: Gunyah capability ID of the TX message queue
          - description: Gunyah capability ID of the RX message queue
      interrupts:
        items:
          - description: Interrupt for the TX message queue
          - description: Interrupt for the RX message queue
    additionalProperties: false
    required:
      - compatible
      - reg
      - interrupts
 additionalProperties: false
 required:
  - compatible
  - "#address-cells"
  - "#size-cells"
 examples:
  - |
    #include <dt-bindings/interrupt-controller/arm-gic.h>
    hypervisor {
        #address-cells = <2>;
        #size-cells = <0>;
        compatible = "gunyah-hypervisor";
        gunyah-resource-mgr@0 {
            compatible = "gunyah-resource-manager";
            interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>, /* TX allowed IRQ */
                         <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>; /* RX requested IRQ */
            reg = <0x00000000 0x00000000>, /* TX capability ID */
                  <0x00000000 0x00000001>; /* RX capability ID */
        };
    };
--- a/Documentation/devicetree/bindings/firmware/mediatek,geniezone.yaml
+++ b/Documentation/devicetree/bindings/firmware/mediatek,geniezone.yaml
@ -1,34 +0,0 @@
 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
 %YAML 1.2
 ---
 $id: http://devicetree.org/schemas/firmware/mediatek,geniezone.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: MediaTek GenieZone hypervisor
 maintainers:
  - Yingshiuan Pan <yingshiuan.pan@mediatek.com>
 description:
  GenieZone is a proprietary type-I hypervisor firmware developed by MediaTek,
  providing an isolated execution environment for mTEE (MediaTek Trusted
  Execution Environment) and AVF (Android Virtualization Framework) virtual
  machines. This binding facilitates the integration of GenieZone into the
  Android Virtualization Framework (AVF) with Crosvm as the VMM. The driver
  exposes hypervisor control interfaces to the VMM for managing virtual
  machine lifecycles and assisting virtual device emulation.
 properties:
  compatible:
    const: mediatek,geniezone
 required:
  - compatible
 additionalProperties: false
 examples:
  - |
    hypervisor {
        compatible = "mediatek,geniezone";
    };
--- a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
@ -23,6 +23,7 @@ properties:
          - ak8963
          - ak09911
          - ak09912
          - ak09916
        deprecated: true
  reg:
--- a/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
+++ b/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
@ -34,7 +34,6 @@ properties:
      and length of the AXI DMA controller IO space, unless
      axistream-connected is specified, in which case the reg
      attribute of the node referenced by it is used.
    minItems: 1
    maxItems: 2
  interrupts:
@ -166,7 +165,7 @@ examples:
        clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
        clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
        phy-mode = "mii";
-        reg = <0x40000000 0x40000>;
+        reg = <0x00 0x40000000 0x00 0x40000>;
        xlnx,rxcsum = <0x2>;
        xlnx,rxmem = <0x800>;
        xlnx,txcsum = <0x2>;
--- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
@ -21,7 +21,6 @@ properties:
          - nxp,imx8mm-fspi
          - nxp,imx8mp-fspi
          - nxp,imx8qxp-fspi
          - nxp,imx8ulp-fspi
          - nxp,lx2160a-fspi
      - items:
          - enum:
--- a/Documentation/devicetree/bindings/trusty/OWNERS
+++ b/Documentation/devicetree/bindings/trusty/OWNERS
@ -1,2 +0,0 @@
 # include OWNERS from the top level trusty repo
 include trusty:refs/meta/config:/OWNERS
--- a/Documentation/devicetree/bindings/trusty/trusty-irq.txt
+++ b/Documentation/devicetree/bindings/trusty/trusty-irq.txt
@ -1,67 +0,0 @@
 Trusty irq interface
 Trusty requires non-secure irqs to be forwarded to the secure OS.
 Required properties:
 - compatible: "android,trusty-irq-v1"
 Optional properties:
 - interrupt-templates: is an optional property that works together
  with "interrupt-ranges" to specify secure side to kernel IRQs mapping.
  It is a list of entries, each one of which defines a group of interrupts
  having common properties, and has the following format:
    < phandle irq_id_pos [templ_data]>
      phandle - phandle of interrupt controller this template is for
      irq_id_pos - the position of irq id in interrupt specifier array
                   for interrupt controller referenced by phandle.
      templ_data - is an array of u32 values (could be empty) in the same
                   format as interrupt specifier for interrupt controller
                   referenced by phandle but with omitted irq id field.
 - interrupt-ranges: list of entries that specifies secure side to kernel
  IRQs mapping.
  Each entry in the "interrupt-ranges" list has the following format:
    <beg end templ_idx>
      beg - first entry in this range
      end - last entry in this range
      templ_idx  - index of entry in "interrupt-templates" property
                   that must be used as a template for all interrupts
                   in this range
 - ipi-range: optional mapping of a linear range of trusty IRQs to a linear range
  of IPIs (inter-processor interrupts).  This has the following format:
    <beg end ipi_base>
      beg - first trusty IRQ number that is an IPI
      end - last trusty IRQ number that is an IPI
      ipi_base - IPI number of 'beg'
 Example:
 {
 	gic: interrupt-controller@50041000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
 		interrupt-controller;
 		...
 	};
 	...
 	trusty {
 		compatible = "android,trusty-smc-v1";
 		ranges;
 		#address-cells = <2>;
 		#size-cells = <2>;
 		irq {
 			compatible = "android,trusty-irq-v1";
 			interrupt-templates = <&gic 1 GIC_PPI 0>,
 					      <&gic 1 GIC_SPI 0>;
 			interrupt-ranges = <16  31 0>,
 					   <32 223 1>;
 			ipi-range = <8 15 8>;
 		};
 	}
 }
 Must be a child of the node that provides the trusty std/fast call interface.
--- a/Documentation/devicetree/bindings/trusty/trusty-smc.txt
+++ b/Documentation/devicetree/bindings/trusty/trusty-smc.txt
@ -1,6 +0,0 @@
 Trusty smc interface
 Trusty is running in secure mode on the same (arm) cpu(s) as the current os.
 Required properties:
 - compatible: "android,trusty-smc-v1"
--- a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
+++ b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
@ -69,7 +69,6 @@ examples:
                                       PDO_FIXED_DATA_SWAP |
                                       PDO_FIXED_DUAL_ROLE)
                                       PDO_FIXED(9000, 2000, 0)>;
                sink-bc12-completion-time-ms = <500>;
            };
        };
    };
--- a/Documentation/dma-buf-test-exporter.rst
+++ b/Documentation/dma-buf-test-exporter.rst
@ -1,42 +0,0 @@
 ..  SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
 =====================
 dma-buf-test-exporter
 =====================
 **Copyright:** \(C) 2012-2013, 2020-2022, 2024 ARM Limited. All rights reserved.
 ..
    This program is free software and is provided to you under the terms of the
    GNU General Public License version 2 as published by the Free Software
    Foundation, and any use by you of this program is subject to the terms
    of such GNU license.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    GNU General Public License for more details.
    You should have received a copy of the GNU General Public License
    along with this program; if not, you can access it online at
    http://www.gnu.org/licenses/gpl-2.0.html.
 Overview
 --------
 The dma-buf-test-exporter is a simple exporter of dma_buf objects.
 It has a private API to allocate and manipulate the buffers which are represented as dma_buf fds.
 The private API allows:
 * simple allocation of physically non-contiguous buffers
 * simple allocation of physically contiguous buffers
 * query kernel side API usage stats (number of attachments, number of mappings, mmaps)
 * failure mode configuration (fail attach, mapping, mmap)
 * kernel side memset of buffers
 The buffers support all of the dma_buf API, including mmap.
 It supports being compiled as a module both in-tree and out-of-tree.
 See **include/uapi/base/arm/dma_buf_test_exporter/dma-buf-test-exporter.h** for the ioctl interface.
 See **Documentation/dma-buf-sharing.txt** for details on dma_buf.
--- a/Documentation/dma-buf-test-exporter.txt
+++ b/Documentation/dma-buf-test-exporter.txt
@ -0,0 +1,42 @@
 # SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
 #
 # (C) COPYRIGHT 2012-2013, 2020-2022 ARM Limited. All rights reserved.
 #
 # This program is free software and is provided to you under the terms of the
 # GNU General Public License version 2 as published by the Free Software
 # Foundation, and any use by you of this program is subject to the terms
 # of such GNU license.
 #
 # This program is distributed in the hope that it will be useful,
 # but WITHOUT ANY WARRANTY; without even the implied warranty of
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, you can access it online at
 # http://www.gnu.org/licenses/gpl-2.0.html.
 #
 #
 =====================
 dma-buf-test-exporter
 =====================
 Overview
 --------
 The dma-buf-test-exporter is a simple exporter of dma_buf objects.
 It has a private API to allocate and manipulate the buffers which are represented as dma_buf fds.
 The private API allows:
 * simple allocation of physically non-contiguous buffers
 * simple allocation of physically contiguous buffers
 * query kernel side API usage stats (number of attachments, number of mappings, mmaps)
 * failure mode configuration (fail attach, mapping, mmap)
 * kernel side memset of buffers
 The buffers support all of the dma_buf API, including mmap.
 It supports being compiled as a module both in-tree and out-of-tree.
 See include/uapi/base/arm/dma_buf_test_exporter/dma-buf-test-exporter.h for the ioctl interface.
 See Documentation/dma-buf-sharing.txt for details on dma_buf.
--- a/Documentation/driver-api/ipmi.rst
+++ b/Documentation/driver-api/ipmi.rst
@ -540,7 +540,7 @@ at module load time (for a module) with::
 	alerts_broken
 The addresses are normal I2C addresses.  The adapter is the string
-name of the adapter, as shown in /sys/bus/i2c/devices/i2c-<n>/name.
+name of the adapter, as shown in /sys/class/i2c-adapter/i2c-<n>/name.
 It is *NOT* i2c-<n> itself.  Also, the comparison is done ignoring
 spaces, so if the name is "This is an I2C chip" you can say
 adapter_name=ThisisanI2cchip.  This is because it's hard to pass in
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@ -182,9 +182,9 @@ fault_type=%d		 Support configuring fault injection type, should be
 			 enabled with fault_injection option, fault type value
 			 is shown below, it supports single or combined type.
-			 ===========================      ===========
+			 ===================	  ===========
 			 Type_Name		  Type_Value
-			 ===========================      ===========
+			 ===================	  ===========
 			 FAULT_KMALLOC		  0x000000001
 			 FAULT_KVMALLOC		  0x000000002
 			 FAULT_PAGE_ALLOC	  0x000000004
@ -203,10 +203,8 @@ fault_type=%d		 Support configuring fault injection type, should be
 			 FAULT_SLAB_ALLOC	  0x000008000
 			 FAULT_DQUOT_INIT	  0x000010000
 			 FAULT_LOCK_OP		  0x000020000
-			 FAULT_BLKADDR_VALIDITY           0x000040000
+			 FAULT_BLKADDR		  0x000040000
-			 FAULT_BLKADDR_CONSISTENCE        0x000080000
+			 ===================	  ===========
 			 FAULT_NO_SEGMENT                 0x000100000
 			 ===========================      ===========
 mode=%s			 Control block allocation mode which supports "adaptive"
 			 and "lfs". In "lfs" mode, there should be no random
 			 writes towards main area.
@ -774,35 +772,6 @@ In order to identify whether the data in the victim segment are valid or not,
 F2FS manages a bitmap. Each bit represents the validity of a block, and the
 bitmap is composed of a bit stream covering whole blocks in main area.
 Write-hint Policy
 -----------------
 F2FS sets the whint all the time with the below policy.
 ===================== ======================== ===================
 User                  F2FS                     Block
 ===================== ======================== ===================
 N/A                   META                     WRITE_LIFE_NONE|REQ_META
 N/A                   HOT_NODE                 WRITE_LIFE_NONE
 N/A                   WARM_NODE                WRITE_LIFE_MEDIUM
 N/A                   COLD_NODE                WRITE_LIFE_LONG
 ioctl(COLD)           COLD_DATA                WRITE_LIFE_EXTREME
 extension list        "                        "
 -- buffered io
 N/A                   COLD_DATA                WRITE_LIFE_EXTREME
 N/A                   HOT_DATA                 WRITE_LIFE_SHORT
 N/A                   WARM_DATA                WRITE_LIFE_NOT_SET
 -- direct io
 WRITE_LIFE_EXTREME    COLD_DATA                WRITE_LIFE_EXTREME
 WRITE_LIFE_SHORT      HOT_DATA                 WRITE_LIFE_SHORT
 WRITE_LIFE_NOT_SET    WARM_DATA                WRITE_LIFE_NOT_SET
 WRITE_LIFE_NONE       "                        WRITE_LIFE_NONE
 WRITE_LIFE_MEDIUM     "                        WRITE_LIFE_MEDIUM
 WRITE_LIFE_LONG       "                        WRITE_LIFE_LONG
 ===================== ======================== ===================
 Fallocate(2) Policy
 -------------------
@ -943,47 +912,3 @@ NVMe Zoned Namespace devices
  can start before the zone-capacity and span across zone-capacity boundary.
  Such spanning segments are also considered as usable segments. All blocks
  past the zone-capacity are considered unusable in these segments.
 Device aliasing feature
 -----------------------
 f2fs can utilize a special file called a "device aliasing file." This file allows
 the entire storage device to be mapped with a single, large extent, not using
 the usual f2fs node structures. This mapped area is pinned and primarily intended
 for holding the space.
 Essentially, this mechanism allows a portion of the f2fs area to be temporarily
 reserved and used by another filesystem or for different purposes. Once that
 external usage is complete, the device aliasing file can be deleted, releasing
 the reserved space back to F2FS for its own use.
 <use-case>
 # ls /dev/vd*
 /dev/vdb (32GB) /dev/vdc (32GB)
 # mkfs.ext4 /dev/vdc
 # mkfs.f2fs -c /dev/vdc@vdc.file /dev/vdb
 # mount /dev/vdb /mnt/f2fs
 # ls -l /mnt/f2fs
 vdc.file
 # df -h
 /dev/vdb                            64G   33G   32G  52% /mnt/f2fs
 # mount -o loop /dev/vdc /mnt/ext4
 # df -h
 /dev/vdb                            64G   33G   32G  52% /mnt/f2fs
 /dev/loop7                          32G   24K   30G   1% /mnt/ext4
 # umount /mnt/ext4
 # f2fs_io getflags /mnt/f2fs/vdc.file
 get a flag on /mnt/f2fs/vdc.file ret=0, flags=nocow(pinned),immutable
 # f2fs_io setflags noimmutable /mnt/f2fs/vdc.file
 get a flag on noimmutable ret=0, flags=800010
 set a flag on /mnt/f2fs/vdc.file ret=0, flags=noimmutable
 # rm /mnt/f2fs/vdc.file
 # df -h
 /dev/vdb                            64G  753M   64G   2% /mnt/f2fs
 So, the key idea is, user can do any file operations on /dev/vdc, and
 reclaim the space after the use, while the space is counted as /data.
 That doesn't require modifying partition size and filesystem format.
--- a/Documentation/filesystems/fscrypt.rst
+++ b/Documentation/filesystems/fscrypt.rst
@ -261,9 +261,9 @@ DIRECT_KEY policies
 The Adiantum encryption mode (see `Encryption modes and usage`_) is
 suitable for both contents and filenames encryption, and it accepts
-long IVs --- long enough to hold both an 8-byte data unit index and a
+long IVs --- long enough to hold both an 8-byte logical block number
-16-byte per-file nonce.  Also, the overhead of each Adiantum key is
+and a 16-byte per-file nonce.  Also, the overhead of each Adiantum key
-greater than that of an AES-256-XTS key.
+is greater than that of an AES-256-XTS key.
 Therefore, to improve performance and save memory, for Adiantum a
 "direct key" configuration is supported.  When the user has enabled
@ -300,8 +300,8 @@ IV_INO_LBLK_32 policies
 IV_INO_LBLK_32 policies work like IV_INO_LBLK_64, except that for
 IV_INO_LBLK_32, the inode number is hashed with SipHash-2-4 (where the
-SipHash key is derived from the master key) and added to the file data
+SipHash key is derived from the master key) and added to the file
-unit index mod 2^32 to produce a 32-bit IV.
+logical block number mod 2^32 to produce a 32-bit IV.
 This format is optimized for use with inline encryption hardware
 compliant with the eMMC v5.2 standard, which supports only 32 IV bits
@ -451,62 +451,31 @@ acceleration is recommended:
 Contents encryption
 -------------------
-For contents encryption, each file's contents is divided into "data
+For file contents, each filesystem block is encrypted independently.
-units".  Each data unit is encrypted independently.  The IV for each
+Starting from Linux kernel 5.5, encryption of filesystems with block
-data unit incorporates the zero-based index of the data unit within
+size less than system's page size is supported.
 the file.  This ensures that each data unit within a file is encrypted
 differently, which is essential to prevent leaking information.
-Note: the encryption depending on the offset into the file means that
+Each block's IV is set to the logical block number within the file as
-operations like "collapse range" and "insert range" that rearrange the
+a little endian number, except that:
 extent mapping of files are not supported on encrypted files.
-There are two cases for the sizes of the data units:
+- With CBC mode encryption, ESSIV is also used.  Specifically, each IV
  is encrypted with AES-256 where the AES-256 key is the SHA-256 hash
  of the file's data encryption key.
-* Fixed-size data units.  This is how all filesystems other than UBIFS
+- With `DIRECT_KEY policies`_, the file's nonce is appended to the IV.
-  work.  A file's data units are all the same size; the last data unit
+  Currently this is only allowed with the Adiantum encryption mode.
  is zero-padded if needed.  By default, the data unit size is equal
  to the filesystem block size.  On some filesystems, users can select
  a sub-block data unit size via the ``log2_data_unit_size`` field of
  the encryption policy; see `FS_IOC_SET_ENCRYPTION_POLICY`_.
-* Variable-size data units.  This is what UBIFS does.  Each "UBIFS
+- With `IV_INO_LBLK_64 policies`_, the logical block number is limited
-  data node" is treated as a crypto data unit.  Each contains variable
+  to 32 bits and is placed in bits 0-31 of the IV.  The inode number
-  length, possibly compressed data, zero-padded to the next 16-byte
+  (which is also limited to 32 bits) is placed in bits 32-63.
  boundary.  Users cannot select a sub-block data unit size on UBIFS.
-In the case of compression + encryption, the compressed data is
+- With `IV_INO_LBLK_32 policies`_, the logical block number is limited
-encrypted.  UBIFS compression works as described above.  f2fs
+  to 32 bits and is placed in bits 0-31 of the IV.  The inode number
-compression works a bit differently; it compresses a number of
+  is then hashed and added mod 2^32.
 filesystem blocks into a smaller number of filesystem blocks.
 Therefore a f2fs-compressed file still uses fixed-size data units, and
 it is encrypted in a similar way to a file containing holes.
-As mentioned in `Key hierarchy`_, the default encryption setting uses
+Note that because file logical block numbers are included in the IVs,
-per-file keys.  In this case, the IV for each data unit is simply the
+filesystems must enforce that blocks are never shifted around within
-index of the data unit in the file.  However, users can select an
+encrypted files, e.g. via "collapse range" or "insert range".
 encryption setting that does not use per-file keys.  For these, some
 kind of file identifier is incorporated into the IVs as follows:
 - With `DIRECT_KEY policies`_, the data unit index is placed in bits
  0-63 of the IV, and the file's nonce is placed in bits 64-191.
 - With `IV_INO_LBLK_64 policies`_, the data unit index is placed in
  bits 0-31 of the IV, and the file's inode number is placed in bits
  32-63.  This setting is only allowed when data unit indices and
  inode numbers fit in 32 bits.
 - With `IV_INO_LBLK_32 policies`_, the file's inode number is hashed
  and added to the data unit index.  The resulting value is truncated
  to 32 bits and placed in bits 0-31 of the IV.  This setting is only
  allowed when data unit indices and inode numbers fit in 32 bits.
 The byte order of the IV is always little endian.
 If the user selects FSCRYPT_MODE_AES_128_CBC for the contents mode, an
 ESSIV layer is automatically included.  In this case, before the IV is
 passed to AES-128-CBC, it is encrypted with AES-256 where the AES-256
 key is the SHA-256 hash of the file's contents encryption key.
 Filenames encryption
 --------------------
@ -575,8 +544,7 @@ follows::
            __u8 contents_encryption_mode;
            __u8 filenames_encryption_mode;
            __u8 flags;
-            __u8 log2_data_unit_size;
+            __u8 __reserved[4];
            __u8 __reserved[3];
            __u8 master_key_identifier[FSCRYPT_KEY_IDENTIFIER_SIZE];
    };
@ -618,29 +586,6 @@ This structure must be initialized as follows:
  The DIRECT_KEY, IV_INO_LBLK_64, and IV_INO_LBLK_32 flags are
  mutually exclusive.
 - ``log2_data_unit_size`` is the log2 of the data unit size in bytes,
  or 0 to select the default data unit size.  The data unit size is
  the granularity of file contents encryption.  For example, setting
  ``log2_data_unit_size`` to 12 causes file contents be passed to the
  underlying encryption algorithm (such as AES-256-XTS) in 4096-byte
  data units, each with its own IV.
  Not all filesystems support setting ``log2_data_unit_size``.  ext4
  and f2fs support it since Linux v6.7.  On filesystems that support
  it, the supported nonzero values are 9 through the log2 of the
  filesystem block size, inclusively.  The default value of 0 selects
  the filesystem block size.
  The main use case for ``log2_data_unit_size`` is for selecting a
  data unit size smaller than the filesystem block size for
  compatibility with inline encryption hardware that only supports
  smaller data unit sizes.  ``/sys/block/$disk/queue/crypto/`` may be
  useful for checking which data unit sizes are supported by a
  particular system's inline encryption hardware.
  Leave this field zeroed unless you are certain you need it.  Using
  an unnecessarily small data unit size reduces performance.
 - For v2 encryption policies, ``__reserved`` must be zeroed.
 - For v1 encryption policies, ``master_key_descriptor`` specifies how
@ -1134,8 +1079,8 @@ The caller must zero all input fields, then fill in ``key_spec``:
 On success, 0 is returned and the kernel fills in the output fields:
 - ``status`` indicates whether the key is absent, present, or
-  incompletely removed.  Incompletely removed means that removal has
+  incompletely removed.  Incompletely removed means that the master
-  been initiated, but some files are still in use; i.e.,
+  secret has been removed, but some files are still in use; i.e.,
  `FS_IOC_REMOVE_ENCRYPTION_KEY`_ returned 0 but set the informational
  status flag FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY.
--- a/Documentation/filesystems/incfs.rst
+++ b/Documentation/filesystems/incfs.rst
@ -1,85 +0,0 @@
 .. SPDX-License-Identifier: GPL-2.0
 =================================================
 incfs: A stacked incremental filesystem for Linux
 =================================================
 /sys/fs interface
 =================
 Please update Documentation/ABI/testing/sysfs-fs-incfs if you update this
 section.
 incfs creates the following files in /sys/fs.
 Features
 --------
 /sys/fs/incremental-fs/features/corefs
  Reads 'supported'. Always present.
 /sys/fs/incremental-fs/features/v2
  Reads 'supported'. Present if all v2 features of incfs are supported. These
  are:
    fs-verity support
    inotify support
    ioclts:
      INCFS_IOC_SET_READ_TIMEOUTS
      INCFS_IOC_GET_READ_TIMEOUTS
      INCFS_IOC_GET_BLOCK_COUNT
      INCFS_IOC_CREATE_MAPPED_FILE
    .incomplete folder
    .blocks_written pseudo file
    report_uid mount option
 /sys/fs/incremental-fs/features/zstd
  Reads 'supported'. Present if zstd compression is supported for data blocks.
 /sys/fs/incremental-fs/features/bugfix_throttling
  Reads 'supported'. Present if the throttling lock bug is fixed
 Optional per mount
 ------------------
 For each incfs mount, the mount option sysfs_name=[name] creates a /sys/fs
 node called:
 /sys/fs/incremental-fs/instances/[name]
 This will contain the following files:
 /sys/fs/incremental-fs/instances/[name]/reads_delayed_min
  Returns a count of the number of reads that were delayed as a result of the
  per UID read timeouts min time setting.
 /sys/fs/incremental-fs/instances/[name]/reads_delayed_min_us
  Returns total delay time for all files since first mount as a result of the
  per UID read timeouts min time setting.
 /sys/fs/incremental-fs/instances/[name]/reads_delayed_pending
  Returns a count of the number of reads that were delayed as a result of
  waiting for a pending read.
 /sys/fs/incremental-fs/instances/[name]/reads_delayed_pending_us
  Returns total delay time for all files since first mount as a result of
  waiting for a pending read.
 /sys/fs/incremental-fs/instances/[name]/reads_failed_hash_verification
  Returns number of reads that failed because of hash verification failures.
 /sys/fs/incremental-fs/instances/[name]/reads_failed_other
  Returns number of reads that failed for reasons other than timing out or
  hash failures.
 /sys/fs/incremental-fs/instances/[name]/reads_failed_timed_out
  Returns number of reads that timed out.
 For reads_delayed_*** settings, note that a file can count for both
 reads_delayed_min and reads_delayed_pending if incfs first waits for a pending
 read then has to wait further for the min time. In that case, the time spent
 waiting is split between reads_delayed_pending_us, which is increased by the
 time spent waiting for the pending read, and reads_delayed_min_us, which is
 increased by the remainder of the time spent waiting.
 Reads that timed out are not added to the reads_delayed_pending or the
 reads_delayed_pending_us counters.
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@ -323,30 +323,6 @@ and
 The resulting access permissions should be the same.  The difference is in
 the time of copy (on-demand vs. up-front).
 ### Non overlapping credentials
 As noted above, all access to the upper, lower and work directories is the
 recorded mounter's MAC and DAC credentials.  The incoming accesses are
 checked against the caller's credentials.
 In the case where caller MAC or DAC credentials do not overlap the mounter, a
 use case available in older versions of the driver, the override_creds mount
 flag can be turned off.  For when the use pattern has caller with legitimate
 credentials where the mounter does not.  For example init may have been the
 mounter, but the caller would have execute or read MAC permissions where
 init would not.  override_creds off means all access, incoming, upper, lower
 or working, will be tested against the caller.
 Several unintended side effects will occur though.  The caller without certain
 key capabilities or lower privilege will not always be able to delete files or
 directories, create nodes, or search some restricted directories.  The ability
 to search and read a directory entry is spotty as a result of the cache
 mechanism not re-testing the credentials because of the assumption, a
 privileged caller can fill cache, then a lower privilege can read the directory
 cache.  The uneven security model where cache, upperdir and workdir are opened
 at privilege, but accessed without creating a form of privilege escalation,
 should only be used with strict understanding of the side effects and of the
 security policies.
 Multiple lower layers
 ---------------------
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@ -528,9 +528,9 @@ replaced by copy-on-write) part of the underlying shmem object out on swap.
 does not take into account swapped out page of underlying shmem objects.
 "Locked" indicates whether the mapping is locked in memory or not.
-"THPeligible" indicates whether the mapping is eligible for allocating
+"THPeligible" indicates whether the mapping is eligible for allocating THP
-naturally aligned THP pages of any currently enabled size. 1 if true, 0
+pages as well as the THP is PMD mappable or not - 1 if true, 0 otherwise.
-otherwise.
+It just shows the current status.
 "VmFlags" field deserves a separate description. This member represents the
 kernel flags associated with the particular virtual memory area in two letter
@ -571,7 +571,6 @@ encoded manner. The codes are the following:
    um    userfaultfd missing tracking
    uw    userfaultfd wr-protect tracking
    ss    shadow stack page
    sl    sealed
    ==    =======================================
 Note that there is no guarantee that every flag and associated mnemonic will
--- a/Documentation/kbuild/kbuild.rst
+++ b/Documentation/kbuild/kbuild.rst
@ -32,11 +32,6 @@ Additional options to pass when preprocessing. The preprocessing options
 will be used in all cases where kbuild does preprocessing including
 building C files and assembler files.
 KCPPFLAGS_COMPAT
 ----------------
 Additional options to pass to $(CC_COMPAT) when preprocessing C and assembler
 files.
 KAFLAGS
 -------
 Additional options to the assembler (for built-in and modules).
--- a/Documentation/kbuild/modules.rst
+++ b/Documentation/kbuild/modules.rst
@ -21,7 +21,6 @@ This document describes how to build an out-of-tree kernel module.
 	   --- 4.1 Kernel Includes
 	   --- 4.2 Single Subdirectory
 	   --- 4.3 Several Subdirectories
 	   --- 4.4 UAPI Headers Installation
 	=== 5. Module Installation
 	   --- 5.1 INSTALL_MOD_PATH
 	   --- 5.2 INSTALL_MOD_DIR
@ -132,10 +131,6 @@ executed to make module versioning work.
 		/lib/modules/<kernel_release>/updates/, but a prefix may
 		be added with INSTALL_MOD_PATH (discussed in section 5).
 	headers_install
 		Export headers in a format suitable for userspace. The default
 		location is $PWD/usr. INSTALL_HDR_PATH can change this path.
 	clean
 		Remove all generated files in the module directory only.
@ -411,17 +406,6 @@ according to the following rule:
 	pointing to the directory where the currently executing kbuild
 	file is located.
 4.4 UAPI Headers Installation
 -----------------------------
 	External modules may export headers to userspace in a similar
 	fashion to the in-tree counterpart drivers. kbuild supports
 	running headers_install target in an out-of-tree. The location
 	where kbuild searches for headers is $(M)/include/uapi and
 	$(M)/arch/$(SRCARCH)/include/uapi.
 	See also Documentation/kbuild/headers_install.rst.
 5. Module Installation
 ======================
--- a/Documentation/mm/transhuge.rst
+++ b/Documentation/mm/transhuge.rst
@ -117,7 +117,7 @@ pages:
  - map/unmap of a PMD entry for the whole THP increment/decrement
    folio->_entire_mapcount and also increment/decrement
-    folio->_nr_pages_mapped by ENTIRELY_MAPPED when _entire_mapcount
+    folio->_nr_pages_mapped by COMPOUND_MAPPED when _entire_mapcount
    goes from -1 to 0 or 0 to -1.
  - map/unmap of individual pages with PTE entry increment/decrement
@ -156,7 +156,7 @@ Partial unmap and deferred_split_folio()
 Unmapping part of THP (with munmap() or other way) is not going to free
 memory immediately. Instead, we detect that a subpage of THP is not in use
-in folio_remove_rmap_*() and queue the THP for splitting if memory pressure
+in page_remove_rmap() and queue the THP for splitting if memory pressure
 comes. Splitting will free up unused subpages.
 Splitting the page right away is not an option due to locking context in
--- a/Documentation/mm/unevictable-lru.rst
+++ b/Documentation/mm/unevictable-lru.rst
@ -486,7 +486,7 @@ munlock the pages if we're removing the last VM_LOCKED VMA that maps the pages.
 Before the unevictable/mlock changes, mlocking did not mark the pages in any
 way, so unmapping them required no processing.
-For each PTE (or PMD) being unmapped from a VMA, folio_remove_rmap_*() calls
+For each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls
 munlock_vma_folio(), which calls munlock_folio() when the VMA is VM_LOCKED
 (unless it was a PTE mapping of a part of a transparent huge page).
@ -511,7 +511,7 @@ userspace; truncation even unmaps and deletes any private anonymous pages
 which had been Copied-On-Write from the file pages now being truncated.
 Mlocked pages can be munlocked and deleted in this way: like with munmap(),
-for each PTE (or PMD) being unmapped from a VMA, folio_remove_rmap_*() calls
+for each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls
 munlock_vma_folio(), which calls munlock_folio() when the VMA is VM_LOCKED
 (unless it was a PTE mapping of a part of a transparent huge page).
--- a/Documentation/power/energy-model.rst
+++ b/Documentation/power/energy-model.rst
@ -71,31 +71,6 @@ whose performance is scaled together. Performance domains generally have a
 required to have the same micro-architecture. CPUs in different performance
 domains can have different micro-architectures.
 To better reflect power variation due to static power (leakage) the EM
 supports runtime modifications of the power values. The mechanism relies on
 RCU to free the modifiable EM perf_state table memory. Its user, the task
 scheduler, also uses RCU to access this memory. The EM framework provides
 API for allocating/freeing the new memory for the modifiable EM table.
 The old memory is freed automatically using RCU callback mechanism when there
 are no owners anymore for the given EM runtime table instance. This is tracked
 using kref mechanism. The device driver which provided the new EM at runtime,
 should call EM API to free it safely when it's no longer needed. The EM
 framework will handle the clean-up when it's possible.
 The kernel code which want to modify the EM values is protected from concurrent
 access using a mutex. Therefore, the device driver code must run in sleeping
 context when it tries to modify the EM.
 With the runtime modifiable EM we switch from a 'single and during the entire
 runtime static EM' (system property) design to a 'single EM which can be
 changed during runtime according e.g. to the workload' (system and workload
 property) design.
 It is possible also to modify the CPU performance values for each EM's
 performance state. Thus, the full power and performance profile (which
 is an exponential curve) can be changed according e.g. to the workload
 or system property.
 2. Core APIs
 ------------
@ -200,82 +175,10 @@ CPUfreq governor is in use in case of CPU device. Currently this calculation is
 not provided for other type of devices.
 More details about the above APIs can be found in ``<linux/energy_model.h>``
-or in Section 2.5
+or in Section 2.4
-2.4 Runtime modifications
+2.4 Description details of this API
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 Drivers willing to update the EM at runtime should use the following dedicated
 function to allocate a new instance of the modified EM. The API is listed
 below::
  struct em_perf_table __rcu *em_table_alloc(struct em_perf_domain *pd);
 This allows to allocate a structure which contains the new EM table with
 also RCU and kref needed by the EM framework. The 'struct em_perf_table'
 contains array 'struct em_perf_state state[]' which is a list of performance
 states in ascending order. That list must be populated by the device driver
 which wants to update the EM. The list of frequencies can be taken from
 existing EM (created during boot). The content in the 'struct em_perf_state'
 must be populated by the driver as well.
 This is the API which does the EM update, using RCU pointers swap::
  int em_dev_update_perf_domain(struct device *dev,
 			struct em_perf_table __rcu *new_table);
 Drivers must provide a pointer to the allocated and initialized new EM
 'struct em_perf_table'. That new EM will be safely used inside the EM framework
 and will be visible to other sub-systems in the kernel (thermal, powercap).
 The main design goal for this API is to be fast and avoid extra calculations
 or memory allocations at runtime. When pre-computed EMs are available in the
 device driver, than it should be possible to simply re-use them with low
 performance overhead.
 In order to free the EM, provided earlier by the driver (e.g. when the module
 is unloaded), there is a need to call the API::
  void em_table_free(struct em_perf_table __rcu *table);
 It will allow the EM framework to safely remove the memory, when there is
 no other sub-system using it, e.g. EAS.
 To use the power values in other sub-systems (like thermal, powercap) there is
 a need to call API which protects the reader and provide consistency of the EM
 table data::
  struct em_perf_state *em_perf_state_from_pd(struct em_perf_domain *pd);
 It returns the 'struct em_perf_state' pointer which is an array of performance
 states in ascending order.
 This function must be called in the RCU read lock section (after the
 rcu_read_lock()). When the EM table is not needed anymore there is a need to
 call rcu_real_unlock(). In this way the EM safely uses the RCU read section
 and protects the users. It also allows the EM framework to manage the memory
 and free it. More details how to use it can be found in Section 3.2 in the
 example driver.
 There is dedicated API for device drivers to calculate em_perf_state::cost
 values::
  int em_dev_compute_costs(struct device *dev, struct em_perf_state *table,
                           int nr_states);
 These 'cost' values from EM are used in EAS. The new EM table should be passed
 together with the number of entries and device pointer. When the computation
 of the cost values is done properly the return value from the function is 0.
 The function takes care for right setting of inefficiency for each performance
 state as well. It updates em_perf_state::flags accordingly.
 Then such prepared new EM can be passed to the em_dev_update_perf_domain()
 function, which will allow to use it.
 More details about the above APIs can be found in ``<linux/energy_model.h>``
 or in Section 3.2 with an example code showing simple implementation of the
 updating mechanism in a device driver.
 2.5 Description details of this API
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .. kernel-doc:: include/linux/energy_model.h
   :internal:
@ -284,11 +187,8 @@ updating mechanism in a device driver.
   :export:
-3. Examples
+3. Example driver
-----------
+-----------------
 3.1 Example driver with EM registration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 The CPUFreq framework supports dedicated callback for registering
 the EM for a given CPU(s) 'policy' object: cpufreq_driver::register_em().
@ -342,78 +242,3 @@ EM framework::
  39	static struct cpufreq_driver foo_cpufreq_driver = {
  40		.register_em = foo_cpufreq_register_em,
  41	};
 3.2 Example driver with EM modification
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 This section provides a simple example of a thermal driver modifying the EM.
 The driver implements a foo_thermal_em_update() function. The driver is woken
 up periodically to check the temperature and modify the EM data::
  -> drivers/soc/example/example_em_mod.c
  01	static void foo_get_new_em(struct foo_context *ctx)
  02	{
  03		struct em_perf_table __rcu *em_table;
  04		struct em_perf_state *table, *new_table;
  05		struct device *dev = ctx->dev;
  06		struct em_perf_domain *pd;
  07		unsigned long freq;
  08		int i, ret;
  09
  10		pd = em_pd_get(dev);
  11		if (!pd)
  12			return;
  13
  14		em_table = em_table_alloc(pd);
  15		if (!em_table)
  16			return;
  17
  18		new_table = em_table->state;
  19
  20		rcu_read_lock();
  21		table = em_perf_state_from_pd(pd);
  22		for (i = 0; i < pd->nr_perf_states; i++) {
  23			freq = table[i].frequency;
  24			foo_get_power_perf_values(dev, freq, &new_table[i]);
  25		}
  26		rcu_read_unlock();
  27
  28		/* Calculate 'cost' values for EAS */
  29		ret = em_dev_compute_costs(dev, table, pd->nr_perf_states);
  30		if (ret) {
  31			dev_warn(dev, "EM: compute costs failed %d\n", ret);
  32			em_free_table(em_table);
  33			return;
  34		}
  35
  36		ret = em_dev_update_perf_domain(dev, em_table);
  37		if (ret) {
  38			dev_warn(dev, "EM: update failed %d\n", ret);
  39			em_free_table(em_table);
  40			return;
  41		}
  42
  43		/*
  44		 * Since it's one-time-update drop the usage counter.
  45		 * The EM framework will later free the table when needed.
  46		 */
  47		em_table_free(em_table);
  48	}
  49
  50	/*
  51	 * Function called periodically to check the temperature and
  52	 * update the EM if needed
  53	 */
  54	static void foo_thermal_em_update(struct foo_context *ctx)
  55	{
  56		struct device *dev = ctx->dev;
  57		int cpu;
  58
  59		ctx->temperature = foo_get_temp(dev, ctx);
  60		if (ctx->temperature < FOO_EM_UPDATE_TEMP_THRESHOLD)
  61			return;
  62
  63		foo_get_new_em(ctx);
  64	}
--- 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)  11.0.0           clang --version
-Rust (optional)        1.71.1           rustc --version
+Rust (optional)        1.73.0           rustc --version
 bindgen (optional)     0.65.1           bindgen --version
 GNU make               3.82             make --version
 bash                   4.2              bash --version
--- a/Documentation/scheduler/sched-energy.rst
+++ b/Documentation/scheduler/sched-energy.rst
@ -402,7 +402,7 @@ Consequently, the only sane governor to use together with EAS is schedutil,
 because it is the only one providing some degree of consistency between
 frequency requests and energy predictions.
-Using EAS with any other governor than schedutil is not recommended.
+Using EAS with any other governor than schedutil is not supported.
 6.5 Scale-invariant utilization signals
--- a/Documentation/scheduler/schedutil.rst
+++ b/Documentation/scheduler/schedutil.rst
@ -90,8 +90,8 @@ For more detail see:
 - Documentation/scheduler/sched-capacity.rst:"1. CPU Capacity + 2. Task utilization"
-UTIL_EST
+UTIL_EST / UTIL_EST_FASTUP
-========
+==========================
 Because periodic tasks have their averages decayed while they sleep, even
 though when running their expected utilization will be the same, they suffer a
@ -99,7 +99,8 @@ though when running their expected utilization will be the same, they suffer a
 To alleviate this (a default enabled option) UTIL_EST drives an Infinite
 Impulse Response (IIR) EWMA with the 'running' value on dequeue -- when it is
-highest. UTIL_EST filters to instantly increase and only decay on decrease.
+highest. A further default enabled option UTIL_EST_FASTUP modifies the IIR
 filter to instantly increase and only decay on decrease.
 A further runqueue wide sum (of runnable tasks) is maintained of:
--- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
+++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
@ -107,14 +107,14 @@ GetOptions(
 );
 # Defaults for dynamically discovered regex's
-my $regex_direct_begin_default = 'order=([0-9]*) gfp_flags=([A-Z_|]*)';
+my $regex_direct_begin_default = 'order=([0-9]*) may_writepage=([0-9]*) gfp_flags=([A-Z_|]*)';
 my $regex_direct_end_default = 'nr_reclaimed=([0-9]*)';
 my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)';
 my $regex_kswapd_sleep_default = 'nid=([0-9]*)';
-my $regex_wakeup_kswapd_default = 'nid=([0-9]*) order=([0-9]*) gfp_flags=([A-Z_|]*)';
+my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*) gfp_flags=([A-Z_|]*)';
-my $regex_lru_isolate_default = 'classzone=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_skipped=([0-9]*) nr_taken=([0-9]*) lru=([a-z_]*)';
+my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) classzone_idx=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_skipped=([0-9]*) nr_taken=([0-9]*) lru=([a-z_]*)';
 my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) nr_dirty=([0-9]*) nr_writeback=([0-9]*) nr_congested=([0-9]*) nr_immediate=([0-9]*) nr_activate_anon=([0-9]*) nr_activate_file=([0-9]*) nr_ref_keep=([0-9]*) nr_unmap_fail=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)';
-my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_taken=([0-9]*) nr_active=([0-9]*) nr_deactivated=([0-9]*) nr_referenced=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)' ;
+my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)';
 my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)';
 # Dyanically discovered regex
@ -184,7 +184,8 @@ sub generate_traceevent_regex {
 $regex_direct_begin = generate_traceevent_regex(
 			"vmscan/mm_vmscan_direct_reclaim_begin",
 			$regex_direct_begin_default,
-			"order", "gfp_flags");
+			"order", "may_writepage",
 			"gfp_flags");
 $regex_direct_end = generate_traceevent_regex(
 			"vmscan/mm_vmscan_direct_reclaim_end",
 			$regex_direct_end_default,
@ -200,11 +201,11 @@ $regex_kswapd_sleep = generate_traceevent_regex(
 $regex_wakeup_kswapd = generate_traceevent_regex(
 			"vmscan/mm_vmscan_wakeup_kswapd",
 			$regex_wakeup_kswapd_default,
-			"nid", "order", "gfp_flags");
+			"nid", "zid", "order", "gfp_flags");
 $regex_lru_isolate = generate_traceevent_regex(
 			"vmscan/mm_vmscan_lru_isolate",
 			$regex_lru_isolate_default,
-			"classzone", "order",
+			"isolate_mode", "classzone_idx", "order",
 			"nr_requested", "nr_scanned", "nr_skipped", "nr_taken",
 			"lru");
 $regex_lru_shrink_inactive = generate_traceevent_regex(
@ -217,10 +218,11 @@ $regex_lru_shrink_inactive = generate_traceevent_regex(
 $regex_lru_shrink_active = generate_traceevent_regex(
 			"vmscan/mm_vmscan_lru_shrink_active",
 			$regex_lru_shrink_active_default,
-			"nid", "nr_taken", "nr_active", "nr_deactivated", "nr_referenced",
+			"nid", "zid",
-			"priority", "flags");
+			"lru",
 			"nr_scanned", "nr_rotated", "priority");
 $regex_writepage = generate_traceevent_regex(
-			"vmscan/mm_vmscan_write_folio",
+			"vmscan/mm_vmscan_writepage",
 			$regex_writepage_default,
 			"page", "pfn", "flags");
@ -369,7 +371,7 @@ EVENT_PROCESS:
 				print "         $regex_wakeup_kswapd\n";
 				next;
 			}
-			my $order = $2;
+			my $order = $3;
 			$perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order]++;
 		} elsif ($tracepoint eq "mm_vmscan_lru_isolate") {
 			$details = $6;
@ -379,14 +381,18 @@ EVENT_PROCESS:
 				print "         $regex_lru_isolate/o\n";
 				next;
 			}
-			my $nr_scanned = $4;
+			my $isolate_mode = $1;
-			my $lru = $7;
+			my $nr_scanned = $5;
 			my $file = $8;
-			# To closer match vmstat scanning statistics, only count
+			# To closer match vmstat scanning statistics, only count isolate_both
-			# inactive lru as scanning
+			# and isolate_inactive as scanning. isolate_active is rotation
-			if ($lru =~ /inactive_/) {
+			# isolate_inactive == 1
 			# isolate_active   == 2
 			# isolate_both     == 3
 			if ($isolate_mode != 2) {
 				$perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned;
-				if ($lru =~ /_file/) {
+				if ($file =~ /_file/) {
 					$perprocesspid{$process_pid}->{HIGH_NR_FILE_SCANNED} += $nr_scanned;
 				} else {
 					$perprocesspid{$process_pid}->{HIGH_NR_ANON_SCANNED} += $nr_scanned;
--- a/Documentation/translations/zh_CN/scheduler/schedutil.rst
+++ b/Documentation/translations/zh_CN/scheduler/schedutil.rst
@ -89,15 +89,16 @@ r_cpu被定义为当前CPU的最高性能水平与系统中任何其它CPU的最
 - Documentation/translations/zh_CN/scheduler/sched-capacity.rst:"1. CPU Capacity + 2. Task utilization"
-UTIL_EST
+UTIL_EST / UTIL_EST_FASTUP
-========
+==========================
 由于周期性任务的平均数在睡眠时会衰减，而在运行时其预期利用率会和睡眠前相同，
 因此它们在再次运行后会面临（DVFS）的上涨。
 为了缓解这个问题，（一个默认使能的编译选项）UTIL_EST驱动一个无限脉冲响应
 （Infinite Impulse Response，IIR）的EWMA，“运行”值在出队时是最高的。
-UTIL_EST滤波使其在遇到更高值时立刻增加，而遇到低值时会缓慢衰减。
+另一个默认使能的编译选项UTIL_EST_FASTUP修改了IIR滤波器，使其允许立即增加，
 仅在利用率下降时衰减。
 进一步，运行队列的（可运行任务的）利用率之和由下式计算：
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@ -137,7 +137,6 @@ Code  Seq#    Include File                                           Comments
 'F'   DD     video/sstfb.h                                           conflict!
 'G'   00-3F  drivers/misc/sgi-gru/grulib.h                           conflict!
 'G'   00-0F  xen/gntalloc.h, xen/gntdev.h                            conflict!
 'G'   00-0F  linux/gunyah.h                                          conflict!
 'H'   00-7F  linux/hiddev.h                                          conflict!
 'H'   00-0F  linux/hidraw.h                                          conflict!
 'H'   01     linux/mei.h                                             conflict!
--- a/Documentation/userspace-api/media/v4l/buffer.rst
+++ b/Documentation/userspace-api/media/v4l/buffer.rst
@ -602,17 +602,6 @@ Buffer Flags
 	the format. Any subsequent call to the
 	:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
 	but return an ``EPIPE`` error code.
    * .. _`V4L2-BUF-FLAG-HEADERS-ONLY`:
      - ``V4L2_BUF_FLAG_HEADERS_ONLY``
      - 0x00200000
      - This flag may be set when the buffer only contains codec
 	header, but does not contain any frame data. Usually the codec
 	header is merged to the next idr frame, with the flag
 	``V4L2_BUF_FLAG_KEYFRAME``, but there is still some scenes that will
 	split the header and queue it separately. This flag can set only when
 	codec support V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE,
 	and the header mode is set to V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE
    * .. _`V4L2-BUF-FLAG-REQUEST-FD`:
      - ``V4L2_BUF_FLAG_REQUEST_FD``
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@ -1386,12 +1386,8 @@ enum v4l2_mpeg_video_intra_refresh_period_type -
    (enum)
 enum v4l2_mpeg_video_header_mode -
-    Determines whether the header is returned as the first buffer
+    Determines whether the header is returned as the first buffer or is
-    with flag V4L2_BUF_FLAG_HEADERS_ONLY or is
+    it returned together with the first frame. Applicable to encoders.
    it returned together with the first frame.
    Applicable to encoders and decoders.
    If it's not implemented in a driver,
    V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME is to be assumed,
    Possible values are:
 .. raw:: latex
@ -1405,7 +1401,7 @@ enum v4l2_mpeg_video_header_mode -
    :stub-columns: 0
    * - ``V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE``
-      - The stream header is returned separately in the first buffer with the flag V4L2_BUF_FLAG_HEADERS_ONLY.
+      - The stream header is returned separately in the first buffer.
    * - ``V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME``
      - The stream header is returned together with the first encoded
 	frame.
--- a/Documentation/virt/geniezone/introduction.rst
+++ b/Documentation/virt/geniezone/introduction.rst
@ -1,87 +0,0 @@
 .. SPDX-License-Identifier: GPL-2.0
 ======================
 GenieZone Introduction
 ======================
 Overview
 ========
 GenieZone hypervisor (gzvm) is a type-I hypervisor that supports various virtual
 machine types and provides security features such as TEE-like scenarios and
 secure boot. It can create guest VMs for security use cases and has
 virtualization capabilities for both platform and interrupt. Although the
 hypervisor can be booted independently, it requires the assistance of GenieZone
 hypervisor kernel driver (also named gzvm) to leverage the ability of Linux
 kernel for vCPU scheduling, memory management, inter-VM communication and virtio
 backend support.
 Supported Architecture
 ======================
 GenieZone now only supports MediaTek ARM64 SoC.
 Features
 ========
 - vCPU Management
  VM manager aims to provide vCPUs on the basis of time sharing on physical
  CPUs. It requires Linux kernel in host VM for vCPU scheduling and VM power
  management.
 - Memory Management
  Direct use of physical memory from VMs is forbidden and designed to be
  dictated to the privilege models managed by GenieZone hypervisor for security
  reason. With the help of the gzvm module, the hypervisor is able to manipulate
  memory as objects.
 - Virtual Platform
  The gzvm hypervisor emulates a virtual mobile platform for guest OS running on
  guest VM. The platform supports various architecture-defined devices, such as
  virtual arch timer, GIC, MMIO, PSCI, and exception watching...etc.
 - Inter-VM Communication
  Communication among guest VMs is provided mainly on RPC. More communication
  mechanisms will be provided in the future based on VirtIO-vsock.
 - Device Virtualization
  The solution is provided using the well-known VirtIO. The gzvm module redirects
  MMIO traps back to VMM where the virtual devices are mostly emulated.
  Ioeventfd is implemented using eventfd for signaling host VM that some IO
  events in guest VMs need to be processed.
 - Interrupt virtualization
  All interrupts during some guest VMs running are handled by GenieZone
  hypervisor with the help of gzvm module, both virtual and physical ones.
  In case there's no guest VM running, physical interrupts are handled by host
  VM directly for performance reason. Irqfd is also implemented using eventfd
  for accepting vIRQ requests in gzvm module.
 Platform architecture component
 ===============================
 - vm
  The vm component is responsible for setting up the capability and memory
  management for the protected VMs. The capability is mainly about the lifecycle
  control and boot context initialization. And the memory management is highly
  integrated with ARM 2-stage translation tables to convert VA to IPA to PA
  under proper security measures required by protected VMs.
 - vcpu
  The vcpu component is the core of virtualizing an aarch64 physical CPU, and it
  controls the vCPU lifecycle including creating, running and destroying.
  With self-defined exit handler, the vm component is able to act accordingly
  before termination.
 - vgic
  The vgic component exposes control interfaces to Linux kernel via irqchip, and
  we intend to support all SPI, PPI, and SGI. When it comes to virtual
  interrupts, the GenieZone hypervisor writes to list registers and triggers
  vIRQ injection in guest VMs via GIC.
--- a/Documentation/virt/gunyah/index.rst
+++ b/Documentation/virt/gunyah/index.rst
@ -1,135 +0,0 @@
 .. SPDX-License-Identifier: GPL-2.0
 =================
 Gunyah Hypervisor
 =================
 .. toctree::
   :maxdepth: 1
   message-queue
 Gunyah is a Type-1 hypervisor which is independent of any OS kernel, and runs in
 a more privileged CPU level (EL2 on Aarch64). It does not depend on a less
 privileged operating system for its core functionality. This increases its
 security and can support a much smaller trusted computing base than a Type-2
 hypervisor.
 Gunyah is an open source hypervisor. The source repository is available at
 https://github.com/quic/gunyah-hypervisor.
 Gunyah provides these following features.
 - Scheduling:
  A scheduler for virtual CPUs (vCPUs) on physical CPUs enables time-sharing
  of the CPUs. Gunyah supports two models of scheduling which can coexist on
  a running system:
    1. Hypervisor vCPU scheduling in which Gunyah hypervisor schedules vCPUS on
       its own. The default is a real-time priority with round-robin scheduler.
    2. "Proxy" scheduling in which an owner-VM can donate the remainder of its
       own vCPU's time slice to an owned-VM's vCPU via a hypercall.
 - Memory Management:
  APIs handling memory, abstracted as objects, limiting direct use of physical
  addresses. Memory ownership and usage tracking of all memory under its control.
  Memory partitioning between VMs is a fundamental security feature.
 - Interrupt Virtualization:
  Interrupt ownership is tracked and interrupt delivery is directly to the
  assigned VM. Gunyah makes use of hardware interrupt virtualization where
  possible.
 - Inter-VM Communication:
  There are several different mechanisms provided for communicating between VMs.
    1. Message queues
    2. Doorbells
    3. Virtio MMIO transport
    4. Shared memory
 - Virtual platform:
  Architectural devices such as interrupt controllers and CPU timers are
  directly provided by the hypervisor as well as core virtual platform devices
  and system APIs such as ARM PSCI.
 - Device Virtualization:
  Para-virtualization of devices is supported using inter-VM communication and
  virtio transport support. Select stage 2 faults by virtual machines that use
  proxy-scheduled vCPUs can be handled directly by Linux to provide Type-2
  hypervisor style on-demand paging and/or device emulation.
 Architectures supported
 =======================
 AArch64 with a GICv3 or GICv4.1
 Resources and Capabilities
 ==========================
 Services/resources provided by the Gunyah hypervisor are accessible to a
 virtual machine through capabilities. A capability is an access control
 token granting the holder a set of permissions to operate on a specific
 hypervisor object (conceptually similar to a file-descriptor).
 For example, inter-VM communication using Gunyah doorbells and message queues
 is performed using hypercalls taking Capability ID arguments for the required
 IPC objects. These resources are described in Linux as a struct gunyah_resource.
 Unlike UNIX file descriptors, there is no path-based or similar lookup of
 an object to create a new Capability, meaning simpler security analysis.
 Creation of a new Capability requires the holding of a set of privileged
 Capabilities which are typically never given out by the Resource Manager (RM).
 Gunyah itself provides no APIs for Capability ID discovery. Enumeration of
 Capability IDs is provided by RM as a higher level service to VMs.
 Resource Manager
 ================
 The Gunyah Resource Manager (RM) is a privileged application VM supporting the
 Gunyah Hypervisor. It provides policy enforcement aspects of the virtualization
 system. The resource manager can be treated as an extension of the Hypervisor
 but is separated to its own partition to ensure that the hypervisor layer itself
 remains small and secure and to maintain a separation of policy and mechanism in
 the platform. The resource manager runs at arm64 NS-EL1, similar to other
 virtual machines.
 Communication with the resource manager from other virtual machines happens as
 described in message-queue.rst. Details about the specific messages can be found
 in drivers/virt/gunyah/rsc_mgr.c
 ::
  +-------+   +--------+   +--------+
  |  RM   |   |  VM_A  |   |  VM_B  |
  +-.-.-.-+   +---.----+   +---.----+
    | |           |            |
  +-.-.-----------.------------.----+
  | | \==========/             |    |
  |  \========================/     |
  |            Gunyah               |
  +---------------------------------+
 The source for the resource manager is available at
 https://github.com/quic/gunyah-resource-manager.
 The resource manager provides the following features:
 - VM lifecycle management: allocating a VM, starting VMs, destruction of VMs
 - VM access control policy, including memory sharing and lending
 - Interrupt routing configuration
 - Forwarding of system-level events (e.g. VM shutdown) to owner VM
 - Resource (capability) discovery
 A VM requires boot configuration to establish communication with the resource
 manager. This is provided to VMs via a 'hypervisor' device tree node which is
 overlaid to the VMs DT by the RM. This node lets guests know they are running
 as a Gunyah guest VM, how to communicate with resource manager, and basic
 description and capabilities of this VM. See
 Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml for a
 description of this node.
--- a/Documentation/virt/gunyah/message-queue.rst
+++ b/Documentation/virt/gunyah/message-queue.rst
@ -1,68 +0,0 @@
 .. SPDX-License-Identifier: GPL-2.0
 Message Queues
 ==============
 Message queue is a simple low-capacity IPC channel between two virtual machines.
 It is intended for sending small control and configuration messages. Each
 message queue is unidirectional and buffered in the hypervisor. A full-duplex
 IPC channel requires a pair of queues.
 The size of the queue and the maximum size of the message that can be passed is
 fixed at creation of the message queue. Resource manager is presently the only
 use case for message queues, and creates messages queues between itself and VMs
 with a fixed maximum message size of 240 bytes. Longer messages require a
 further protocol on top of the message queue messages themselves. For instance,
 communication with the resource manager adds a header field for sending longer
 messages which are split into smaller fragments.
 The diagram below shows how message queue works. A typical configuration
 involves 2 message queues. Message queue 1 allows VM_A to send messages to VM_B.
 Message queue 2 allows VM_B to send messages to VM_A.
 1. VM_A sends a message of up to 240 bytes in length. It makes a hypercall
   with the message to request the hypervisor to add the message to
   message queue 1's queue. The hypervisor copies memory into the internal
   message queue buffer; the memory doesn't need to be shared between
   VM_A and VM_B.
 2. Gunyah raises the corresponding interrupt for VM_B (Rx vIRQ) when any of
   these happens:
   a. gunyah_msgq_send() has PUSH flag. This is a typical case when the message
      queue is being used to implement an RPC-like interface.
   b. Explicitly with gunyah_msgq_push hypercall from VM_A.
   c. Message queue has reached a threshold depth. Typically, this threshold
      depth is the size of the queue (in other words: when queue is full, Rx
      vIRQ is raised).
 3. VM_B calls gunyah_msgq_recv() and Gunyah copies message to requested buffer.
 4. Gunyah raises the corresponding interrupt for VM_A (Tx vIRQ) when the message
   queue falls below a watermark depth. Typically, this is when the queue is
   drained. Note the watermark depth and the threshold depth for the Rx vIRQ are
   independent values. Coincidentally, this signal is conceptually similar to
   Clear-to-Send.
 For VM_B to send a message to VM_A, the process is identical, except that
 hypercalls reference message queue 2's capability ID. The IRQ will be different
 for the second message queue.
 ::
      +-------------------+         +-----------------+         +-------------------+
      |        VM_A       |         |Gunyah hypervisor|         |        VM_B       |
      |                   |         |                 |         |                   |
      |                   |         |                 |         |                   |
      |                   |   Tx    |                 |         |                   |
      |                   |-------->|                 | Rx vIRQ |                   |
      |gunyah_msgq_send() | Tx vIRQ |Message queue 1  |-------->|gunyah_msgq_recv() |
      |                   |<------- |                 |         |                   |
      |                   |         |                 |         |                   |
      |                   |         |                 |         |                   |
      |                   |         |                 |   Tx    |                   |
      |                   | Rx vIRQ |                 |<--------|                   |
      |gunyah_msgq_recv() |<--------|Message queue 2  | Tx vIRQ |gunyah_msgq_send() |
      |                   |         |                 |-------->|                   |
      |                   |         |                 |         |                   |
      |                   |         |                 |         |                   |
      +-------------------+         +-----------------+         +---------------+
--- a/Documentation/virt/index.rst
+++ b/Documentation/virt/index.rst
@ -16,8 +16,6 @@ Virtualization Support
   coco/sev-guest
   coco/tdx-guest
   hyperv/index
   geniezone/introduction
   gunyah/index
 .. only:: html and subproject
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@ -6612,13 +6612,6 @@ 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 */
--- a/Documentation/virt/kvm/arm/fw-pseudo-registers.rst
+++ b/Documentation/virt/kvm/arm/fw-pseudo-registers.rst
@ -1,138 +0,0 @@
 .. 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
--- a/Documentation/virt/kvm/arm/hypercalls.rst
+++ b/Documentation/virt/kvm/arm/hypercalls.rst
@ -1,190 +1,138 @@
 .. SPDX-License-Identifier: GPL-2.0
-===============================================
+=======================
-KVM/arm64-specific hypercalls exposed to guests
+ARM Hypercall Interface
-===============================================
+=======================
-This file documents the KVM/arm64-specific hypercalls which may be
+KVM handles the hypercall services as requested by the guests. New hypercall
-exposed by KVM/arm64 to guest operating systems. These hypercalls are
+services are regularly made available by the ARM specification or by KVM (as
-issued using the HVC instruction according to version 1.1 of the Arm SMC
+vendor services) if they make sense from a virtualization point of view.
 Calling Convention (DEN0028/C):
-https://developer.arm.com/docs/den0028/c
+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.
-All KVM/arm64-specific hypercalls are allocated within the "Vendor
+In order to remedy this situation, KVM exposes a set of "firmware
-Specific Hypervisor Service Call" range with a UID of
+pseudo-registers" that can be manipulated using the GET/SET_ONE_REG
-``28b46fb6-2ec5-11e9-a9ca-4b564d003a74``. This UID should be queried by the
+interface. These registers can be saved/restored by userspace, and set
-guest using the standard "Call UID" function for the service range in
+to a convenient value as required.
 order to determine that the KVM/arm64-specific hypercalls are available.
-``ARM_SMCCC_KVM_FUNC_FEATURES``
+The following registers are defined:
 ---------------------------------------------
-Provides a discovery mechanism for other KVM/arm64 hypercalls.
+* KVM_REG_ARM_PSCI_VERSION:
-+---------------------+-------------------------------------------------------------+
+  KVM implements the PSCI (Power State Coordination Interface)
-| Presence:           | Mandatory for the KVM/arm64 UID                             |
+  specification in order to provide services such as CPU on/off, reset
-+---------------------+-------------------------------------------------------------+
+  and power-off to the guest.
 | 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_KVM_FUNC_PTP``
+  - 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)
-See ptp_kvm.rst
+* 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].
-``ARM_SMCCC_KVM_FUNC_HYP_MEMINFO``
+  Accepted values are:
 ----------------------------------
-Query the memory protection parameters for a protected virtual machine.
+    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:
-| Presence:           | Optional; protected guests only.                            |
+    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
-| Calling convention: | HVC64                                                       |
+    under SMCCC_ARCH_WORKAROUND_2 in [1]_.
 +---------------------+----------+--------------------------------------------------+
 | Function ID:        | (uint32) | 0xC6000002                                       |
 +---------------------+----------+----+---------------------------------------------+
 | Arguments:          | (uint64) | R1 | Reserved / Must be zero                     |
 |                     +----------+----+---------------------------------------------+
 |                     | (uint64) | R2 | Reserved / Must be zero                     |
 |                     +----------+----+---------------------------------------------+
 |                     | (uint64) | R3 | Reserved / Must be zero                     |
 +---------------------+----------+----+---------------------------------------------+
 | Return Values:      | (int64)  | R0 | ``INVALID_PARAMETER (-3)`` on error, else   |
 |                     |          |    | memory protection granule in bytes          |
 |                     +----------+----+---------------------------------------------+
 |                     | (int64)  | R1 | ``KVM_FUNC_HAS_RANGE (1)`` if MEM_SHARE and |
 |                     |          |    | MEM_UNSHARE take a range argument.          |
 +---------------------+----------+----+---------------------------------------------+
-``ARM_SMCCC_KVM_FUNC_MEM_SHARE``
+  Accepted values are:
 --------------------------------
-Share a region of memory with the KVM host, granting it read, write and execute
+    KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
-permissions. The size of the region is equal to the memory protection granule
+      A workaround is not
-advertised by ``ARM_SMCCC_KVM_FUNC_HYP_MEMINFO`` times the number of granules
+      available. KVM does not offer firmware support for the workaround.
-set in R2. See the ``KVM_FUNC_HAS_RANGE`` paragraph for more details about this
+    KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
-argument.
+      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.
 +---------------------+-------------------------------------------------------------+
 | Presence:           | Optional; protected guests only.                            |
 +---------------------+-------------------------------------------------------------+
 | Calling convention: | HVC64                                                       |
 +---------------------+----------+--------------------------------------------------+
 | Function ID:        | (uint32) | 0xC6000003                                       |
 +---------------------+----------+----+---------------------------------------------+
 | Arguments:          | (uint64) | R1 | Base IPA of memory region to share          |
 |                     +----------+----+---------------------------------------------+
 |                     | (uint64) | R2 | Number of granules to share                 |
 |                     +----------+----+---------------------------------------------+
 |                     | (uint64) | R3 | Reserved / Must be zero                     |
 +---------------------+----------+----+---------------------------------------------+
 | Return Values:      | (int64)  | R0 | ``SUCCESS (0)``                             |
 |                     |          |    +---------------------------------------------+
 |                     |          |    | ``INVALID_PARAMETER (-3)``                  |
 |                     +----------+----+---------------------------------------------+
 |                     | (uint64) | R1 | Number of shared granules                   |
 +---------------------+----------+----+---------------------------------------------+
-``ARM_SMCCC_KVM_FUNC_MEM_UNSHARE``
+Bitmap Feature Firmware Registers
----------------------------------
+---------------------------------
-Revoke access permission from the KVM host to a memory region previously shared
+Contrary to the above registers, the following registers exposes the
-with ``ARM_SMCCC_KVM_FUNC_MEM_SHARE``. The size of the region is equal to the
+hypercall services in the form of a feature-bitmap to the userspace. This
-memory protection granule advertised by ``ARM_SMCCC_KVM_FUNC_HYP_MEMINFO`` times
+bitmap is translated to the services that are available to the guest.
-the number of granules set in R2. See the ``KVM_FUNC_HAS_RANGE`` paragraph for
+There is a register defined per service call owner and can be accessed via
-more details about this argument.
+GET/SET_ONE_REG interface.
-+---------------------+-------------------------------------------------------------+
+By default, these registers are set with the upper limit of the features
-| Presence:           | Optional; protected guests only.                            |
+that are supported. This way userspace can discover all the usable
-+---------------------+-------------------------------------------------------------+
+hypercall services via GET_ONE_REG. The user-space can write-back the
-| Calling convention: | HVC64                                                       |
+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
-| Function ID:        | (uint32) | 0xC6000004                                       |
+exposed as is to the guest.
 +---------------------+----------+----+---------------------------------------------+
 | Arguments:          | (uint64) | R1 | Base IPA of memory region to unshare        |
 |                     +----------+----+---------------------------------------------+
 |                     | (uint64) | R2 | Number of granules to unshare               |
 |                     +----------+----+---------------------------------------------+
 |                     | (uint64) | R3 | Reserved / Must be zero                     |
 +---------------------+----------+----+---------------------------------------------+
 | Return Values:      | (int64)  | R0 | ``SUCCESS (0)``                             |
 |                     |          |    +---------------------------------------------+
 |                     |          |    | ``INVALID_PARAMETER (-3)``                  |
 |                     +----------+----+---------------------------------------------+
 |                     | (uint64) | R1 | Number of unshared granules                 |
 +---------------------+----------+----+---------------------------------------------+
-``ARM_SMCCC_KVM_FUNC_MEM_RELINQUISH``
+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.
-Cooperatively relinquish ownership of a memory region. The size of the
+The pseudo-firmware bitmap register are as follows:
 region is equal to the memory protection granule advertised by
 ``ARM_SMCCC_KVM_FUNC_HYP_MEMINFO``. If this hypercall is advertised
 then it is mandatory to call it before freeing memory via, for
 example, virtio balloon. If the caller is a protected VM, it is
 guaranteed that the memory region will be completely cleared before
 becoming visible to another VM.
-+---------------------+-------------------------------------------------------------+
+* KVM_REG_ARM_STD_BMAP:
-| Presence:           | Optional.                                                   |
+    Controls the bitmap of the ARM Standard Secure Service Calls.
 +---------------------+-------------------------------------------------------------+
 | Calling convention: | HVC64                                                       |
 +---------------------+----------+--------------------------------------------------+
 | Function ID:        | (uint32) | 0xC6000009                                       |
 +---------------------+----------+----+---------------------------------------------+
 | Arguments:          | (uint64) | R1 | Base IPA of memory region to relinquish     |
 |                     +----------+----+---------------------------------------------+
 |                     | (uint64) | R2 | Reserved / Must be zero                     |
 |                     +----------+----+---------------------------------------------+
 |                     | (uint64) | R3 | Reserved / Must be zero                     |
 +---------------------+----------+----+---------------------------------------------+
 | Return Values:      | (int64)  | R0 | ``SUCCESS (0)``                             |
 |                     |          |    +---------------------------------------------+
 |                     |          |    | ``INVALID_PARAMETER (-3)``                  |
 +---------------------+----------+----+---------------------------------------------+
-``ARM_SMCCC_KVM_FUNC_MMIO_GUARD_*``
+  The following bits are accepted:
 -----------------------------------
-See mmio-guard.rst
+    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_FUNC_HAS_RANGE``
+* KVM_REG_ARM_STD_HYP_BMAP:
----------------------
+    Controls the bitmap of the ARM Standard Hypervisor Service Calls.
-This flag, when set in ARM_SMCCC_KVM_FUNC_HYP_MEMINFO, indicates the guest can
+  The following bits are accepted:
 pass a number of granules as an argument to:
-  * ARM_SMCCC_KVM_FUNC_MEM_SHARE
+    Bit-0: KVM_REG_ARM_STD_HYP_BIT_PV_TIME:
-  * ARM_SMCCC_KVM_FUNC_MEM_UNSHARE
+      The bit represents the Paravirtualized Time service as represented by
      ARM DEN0057A.
-In order to support legacy guests, the kernel still accepts ``0`` as a value. In
+* KVM_REG_ARM_VENDOR_HYP_BMAP:
-that case a single granule is shared/unshared.
+    Controls the bitmap of the Vendor specific Hypervisor Service Calls.
-When set in ARM_SMCCC_KVM_FUNC_MMIO_GUARD_INFO, indicates the guest can call the
+  The following bits are accepted:
 HVCs:
-  * ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_MAP
+    Bit-0: KVM_REG_ARM_VENDOR_HYP_BIT_FUNC_FEAT
-  * ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_UNMAP
+      The bit represents the ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID
      and ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID function-ids.
-For all those HVCs, the hypervisor is free to stop the process at any time
+    Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_PTP:
-either because the range isn't physically contiguous or to limit the time spent
+      The bit represents the Precision Time Protocol KVM service.
 at EL2. In a such case, the number of actually shared granules is returned (R1)
 and the caller can start again where it stopped, that is, the base IPA + (Number
 of processed granules * protection granule size).
-If the number of processed granules returned is zero (R1), an error (R0) will be
+Errors:
-set.
+
    =======  =============================================================
    -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
--- a/Documentation/virt/kvm/arm/index.rst
+++ b/Documentation/virt/kvm/arm/index.rst
@ -7,10 +7,7 @@ ARM
 .. toctree::
   :maxdepth: 2
   fw-pseudo-registers
   hyp-abi
   hypercalls
   pkvm
   pvtime
   ptp_kvm
   mmio-guard
--- a/Documentation/virt/kvm/arm/mmio-guard.rst
+++ b/Documentation/virt/kvm/arm/mmio-guard.rst
@ -1,114 +0,0 @@
 .. SPDX-License-Identifier: GPL-2.0
 ==============
 KVM MMIO guard
 ==============
 KVM implements device emulation by handling translation faults to any
 IPA range that is not contained in a memory slot. Such a translation
 fault is in most cases passed on to userspace (or in rare cases to the
 host kernel) with the address, size and possibly data of the access
 for emulation.
 Should the guest exit with an address that is not one that corresponds
 to an emulatable device, userspace may take measures that are not the
 most graceful as far as the guest is concerned (such as terminating it
 or delivering a fatal exception).
 There is also an element of trust: by forwarding the request to
 userspace, the kernel assumes that the guest trusts userspace to do
 the right thing.
 The KVM MMIO guard offers a way to mitigate this last point: a guest
 can request that only certain regions of the IPA space are valid as
 MMIO. Only these regions will be handled as an MMIO, and any other
 will result in an exception being delivered to the guest.
 This relies on a set of hypercalls defined in the KVM-specific range,
 using the HVC64 calling convention.
 When operating on a range of contiguous IPA space, it is recommended
 to use ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_MAP and
 ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_UNMAP. Those HVCs take a number of
 granules as an argument. See ``KVM_FUNC_HAS_RANGE`` in hypercalls.rst
 for a complete description.
 * ARM_SMCCC_KVM_FUNC_MMIO_GUARD_INFO
    ==============    ========    ================================
    Function ID:      (uint32)    0xC6000005
    Arguments:        r1-r3       Reserved / Must be zero
    Return Values:    (int64)     NOT_SUPPORTED(-1) on error, or
                      (uint64)    Protection Granule (PG) size in
                                  bytes (r0). KVM_FUNC_HAS_RANGE(1)
                                  is set (r1) if RGUARD_MAP and
                                  RGUARD_UNMAP HVCs are available.
    ==============    ========    ================================
 * ARM_SMCCC_KVM_FUNC_MMIO_GUARD_ENROLL
    ==============    ========    ==============================
    Function ID:      (uint32)    0xC6000006
    Arguments:        none
    Return Values:    (int64)     NOT_SUPPORTED(-1) on error, or
                                  RET_SUCCESS(0) (r0)
    ==============    ========    ==============================
 * ARM_SMCCC_KVM_FUNC_MMIO_GUARD_MAP
    ==============    ========    ====================================
    Function ID:      (uint32)    0xC6000007
    Arguments:        (uint64)    The base of the PG-sized IPA range
                                  that is allowed to be accessed as
                                  MMIO. Must be aligned to the PG size
                                  (r1)
                      (uint64)    Index in the MAIR_EL1 register
 		                  providing the memory attribute that
 				  is used by the guest (r2)
    Return Values:    (int64)     NOT_SUPPORTED(-1) on error, or
                                  RET_SUCCESS(0) (r0)
    ==============    ========    ====================================
 * ARM_SMCCC_KVM_FUNC_MMIO_GUARD_UNMAP
    ==============    ========    ======================================
    Function ID:      (uint32)    0xC6000008
    Arguments:        (uint64)    PG-sized IPA range aligned to the PG
                                  size which has been previously mapped.
                                  Must be aligned to the PG size and
                                  have been previously mapped (r1)
    Return Values:    (int64)     NOT_SUPPORTED(-1) on error, or
                                  RET_SUCCESS(0) (r0)
    ==============    ========    ======================================
 * ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_MAP
    ==============    ========    ====================================
    Function ID:      (uint32)    0xC600000A
    Arguments:        (uint64)    The base of the PG-sized IPA range
                                  that is allowed to be accessed as
                                  MMIO. Must be aligned to the PG size
                                  (r1)
                      (uint64)    Number of granules to guard (r2). See
                                  ``KVM_FUNC_HAS_RANGE`` in
                                  hypercalls.rst for more details
    Return Values:    (int64)     NOT_SUPPORTED(-1) on error, or
                                  RET_SUCCESS(0) (r0)
                      (uint64)     Number of shared granules (r1)
    ==============    ========    ====================================
 * ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_UNMAP
    ==============    ========    ======================================
    Function ID:      (uint32)    0xC600000B
    Arguments:        (uint64)    PG-sized IPA range aligned to the PG
                                  size which has been previously mapped.
                                  Must be aligned to the PG size and
                                  have been previously mapped (r1)
                      (uint64)    Number of granules to unguard (r2). See
                                  ``KVM_FUNC_HAS_RANGE`` in
                                  hypercalls.rst for more details
    Return Values:    (int64)     NOT_SUPPORTED(-1) on error, or
                                  RET_SUCCESS(0) (r0)
                      (uint64)     Number of shared granules (r1)
    ==============    ========    ======================================
--- a/Documentation/virt/kvm/arm/pkvm.rst
+++ b/Documentation/virt/kvm/arm/pkvm.rst
@ -1,96 +0,0 @@
 .. SPDX-License-Identifier: GPL-2.0
 Protected virtual machines (pKVM)
 =================================
 Introduction
 ------------
 Protected KVM (pKVM) is a KVM/arm64 extension which uses the two-stage
 translation capability of the Armv8 MMU to isolate guest memory from the host
 system. This allows for the creation of a confidential computing environment
 without relying on whizz-bang features in hardware, but still allowing room for
 complementary technologies such as memory encryption and hardware-backed
 attestation.
 The major implementation change brought about by pKVM is that the hypervisor
 code running at EL2 is now largely independent of (and isolated from) the rest
 of the host kernel running at EL1 and therefore additional hypercalls are
 introduced to manage manipulation of guest stage-2 page tables, creation of VM
 data structures and reclamation of memory on teardown. An immediate consequence
 of this change is that the host itself runs with an identity mapping enabled
 at stage-2, providing the hypervisor code with a mechanism to restrict host
 access to an arbitrary physical page.
 Enabling pKVM
 -------------
 The pKVM hypervisor is enabled by booting the host kernel at EL2 with
 "``kvm-arm.mode=protected``" on the command-line. Once enabled, VMs can be spawned
 in either protected or non-protected state, although the hypervisor is still
 responsible for managing most of the VM metadata in either case.
 Limitations
 -----------
 Enabling pKVM places some significant limitations on KVM guests, regardless of
 whether they are spawned in protected state. It is therefore recommended only
 to enable pKVM if protected VMs are required, with non-protected state acting
 primarily as a debug and development aid.
 If you're still keen, then here is an incomplete list of caveats that apply
 to all VMs running under pKVM:
 - Guest memory cannot be file-backed (with the exception of shmem/memfd) and is
  pinned as it is mapped into the guest. This prevents the host from
  swapping-out, migrating, merging or generally doing anything useful with the
  guest pages. It also requires that the VMM has either ``CAP_IPC_LOCK`` or
  sufficient ``RLIMIT_MEMLOCK`` to account for this pinned memory.
 - GICv2 is not supported and therefore GICv3 hardware is required in order
  to expose a virtual GICv3 to the guest.
 - Read-only memslots are unsupported and therefore dirty logging cannot be
  enabled.
 - Memslot configuration is fixed once a VM has started running, with subsequent
  move or deletion requests being rejected with ``-EPERM``.
 - There are probably many others.
 Since the host is unable to tear down the hypervisor when pKVM is enabled,
 hibernation (``CONFIG_HIBERNATION``) and kexec (``CONFIG_KEXEC``) will fail
 with ``-EBUSY``.
 If you are not happy with these limitations, then please don't enable pKVM :)
 VM creation
 -----------
 When pKVM is enabled, protected VMs can be created by specifying the
 ``KVM_VM_TYPE_ARM_PROTECTED`` flag in the machine type identifier parameter
 passed to ``KVM_CREATE_VM``.
 Protected VMs are instantiated according to a fixed vCPU configuration
 described by the ID register definitions in
 ``arch/arm64/include/asm/kvm_pkvm.h``. Only a subset of the architectural
 features that may be available to the host are exposed to the guest and the
 capabilities advertised by ``KVM_CHECK_EXTENSION`` are limited accordingly,
 with the vCPU registers being initialised to their architecturally-defined
 values.
 Where not defined by the architecture, the registers of a protected vCPU
 are reset to zero with the exception of the PC and X0 which can be set
 either by the ``KVM_SET_ONE_REG`` interface or by a call to PSCI ``CPU_ON``.
 VM runtime
 ----------
 By default, memory pages mapped into a protected guest are inaccessible to the
 host and any attempt by the host to access such a page will result in the
 injection of an abort at EL1 by the hypervisor. For accesses originating from
 EL0, the host will then terminate the current task with a ``SIGSEGV``.
 pKVM exposes additional hypercalls to protected guests, primarily for the
 purpose of establishing shared-memory regions with the host for communication
 and I/O. These hypercalls are documented in hypercalls.rst.
--- a/Documentation/virt/kvm/arm/ptp_kvm.rst
+++ b/Documentation/virt/kvm/arm/ptp_kvm.rst
@ -7,29 +7,19 @@ 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_KVM_FUNC_PTP``
+* ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID: 0x86000001
 ----------------------------------------
-Retrieve current time information for the specific counter. There are no
+This hypercall uses the SMC32/HVC32 calling convention:
 endianness restrictions.
-+---------------------+-------------------------------------------------------+
+ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID
-| Presence:           | Optional                                              |
+    ==============    ========    =====================================
-+---------------------+-------------------------------------------------------+
+    Function ID:      (uint32)    0x86000001
-| Calling convention: | HVC32                                                 |
+    Arguments:        (uint32)    KVM_PTP_VIRT_COUNTER(0)
-+---------------------+----------+--------------------------------------------+
+                                  KVM_PTP_PHYS_COUNTER(1)
-| Function ID:        | (uint32) | 0x86000001                                 |
+    Return Values:    (int32)     NOT_SUPPORTED(-1) on error, or
-+---------------------+----------+----+---------------------------------------+
+                      (uint32)    Upper 32 bits of wall clock time (r0)
-| Arguments:          | (uint32) | R1 | ``KVM_PTP_VIRT_COUNTER (0)``          |
+                      (uint32)    Lower 32 bits of wall clock time (r1)
-|                     |          |    +---------------------------------------+
+                      (uint32)    Upper 32 bits of counter (r2)
-|                     |          |    | ``KVM_PTP_PHYS_COUNTER (1)``          |
+                      (uint32)    Lower 32 bits of counter (r3)
-+---------------------+----------+----+---------------------------------------+
+    Endianness:                   No Restrictions.
-| 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              |
 +---------------------+----------+----+---------------------------------------+
--- a/Documentation/virt/kvm/locking.rst
+++ b/Documentation/virt/kvm/locking.rst
@ -9,7 +9,7 @@ KVM Lock Overview
 The acquisition orders for mutexes are as follows:
- cpus_read_lock() is taken outside kvm_lock and kvm_usage_lock
+- cpus_read_lock() is taken outside kvm_lock
 - kvm->lock is taken outside vcpu->mutex
@ -24,13 +24,6 @@ The acquisition orders for mutexes are as follows:
  are taken on the waiting side when modifying memslots, so MMU notifiers
  must not take either kvm->slots_lock or kvm->slots_arch_lock.
 cpus_read_lock() vs kvm_lock:
 - Taking cpus_read_lock() outside of kvm_lock is problematic, despite that
  being the official ordering, as it is quite easy to unknowingly trigger
  cpus_read_lock() while holding kvm_lock.  Use caution when walking vm_list,
  e.g. avoid complex operations when possible.
 For SRCU:
 - ``synchronize_srcu(&kvm->srcu)`` is called inside critical sections
@ -235,17 +228,10 @@ time it will be set using the Dirty tracking mechanism described above.
 :Type:		mutex
 :Arch:		any
 :Protects:	- vm_list
-
+		- kvm_usage_count
 ``kvm_usage_lock``
 ^^^^^^^^^^^^^^^^^^
 :Type:		mutex
 :Arch:		any
 :Protects:	- kvm_usage_count
 		- hardware virtualization enable/disable
-:Comment:	Exists because using kvm_lock leads to deadlock (see earlier comment
+:Comment:	KVM also disables CPU hotplug via cpus_read_lock() during
-		on cpus_read_lock() vs kvm_lock).  Note, KVM also disables CPU hotplug via
+		enable/disable.
 		cpus_read_lock() when enabling/disabling virtualization.
 ``kvm->mn_invalidate_lock``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -305,12 +291,11 @@ time it will be set using the Dirty tracking mechanism described above.
 		wakeup.
 ``vendor_module_lock``
-^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 :Type:		mutex
 :Arch:		x86
 :Protects:	loading a vendor module (kvm_amd or kvm_intel)
-:Comment:	Exists because using kvm_lock leads to deadlock.  kvm_lock is taken
+:Comment:	Exists because using kvm_lock leads to deadlock.  cpu_hotplug_lock is
-    in notifiers, e.g. __kvmclock_cpufreq_notifier(), that may be invoked while
+    taken outside of kvm_lock, e.g. in KVM's CPU online/offline callbacks, and
-    cpu_hotplug_lock is held, e.g. from cpufreq_boost_trigger_state(), and many
+    many operations need to take cpu_hotplug_lock when loading a vendor module,
-    operations need to take cpu_hotplug_lock when loading a vendor module, e.g.
+    e.g. updating static calls.
    updating static calls.
--- a/3
+++ b/3
@ -30,6 +30,3 @@ source "lib/Kconfig"
 source "lib/Kconfig.debug"
 source "Documentation/Kconfig"
 # ANDROID: Set KCONFIG_EXT_PREFIX to decend into an external project.
 source "$(KCONFIG_EXT_PREFIX)Kconfig.ext"
--- a/Kconfig.ext
+++ b/Kconfig.ext
@ -1,3 +0,0 @@
 # SPDX-License-Identifier: GPL-2.0
 # This file is intentionally empty. It's used as a placeholder for when
 # KCONFIG_EXT_PREFIX isn't defined.
--- a/44
+++ b/44
@ -5053,13 +5053,6 @@ F:	scripts/Makefile.clang
 F:	scripts/clang-tools/
 K:	\b(?i:clang|llvm)\b
 CLEANCACHE API
 M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
 L:	linux-kernel@vger.kernel.org
 S:	Maintained
 F:	include/linux/cleancache.h
 F:	mm/cleancache.c
 CLK API
 M:	Russell King <linux@armlinux.org.uk>
 L:	linux-clk@vger.kernel.org
@ -8801,17 +8794,6 @@ F:	include/vdso/
 F:	kernel/time/vsyscall.c
 F:	lib/vdso/
 GENIEZONE HYPERVISOR DRIVER
 M:	Yingshiuan Pan <yingshiuan.pan@mediatek.com>
 M:	Ze-Yu Wang <ze-yu.wang@mediatek.com>
 M:	Liju Chen <liju-clr.chen@mediatek.com>
 F:	Documentation/devicetree/bindings/firmware/mediatek,geniezone.yaml
 F:	Documentation/virt/geniezone/
 F:	arch/arm64/geniezone/
 F:	drivers/virt/geniezone/
 F:	include/linux/soc/mediatek/gzvm_drv.h
 F:	include/uapi/linux/gzvm.h
 GENWQE (IBM Generic Workqueue Card)
 M:	Frank Haverkamp <haver@linux.ibm.com>
 S:	Supported
@ -9101,18 +9083,6 @@ L:	linux-efi@vger.kernel.org
 S:	Maintained
 F:	block/partitions/efi.*
 GUNYAH HYPERVISOR DRIVER
 M:	Elliot Berman <quic_eberman@quicinc.com>
 M:	Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
 L:	linux-arm-msm@vger.kernel.org
 S:	Supported
 F:	Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
 F:	Documentation/virt/gunyah/
 F:	arch/arm64/gunyah/
 F:	drivers/virt/gunyah/
 F:	include/linux/gunyah*.h
 K:	gunyah
 HABANALABS PCI DRIVER
 M:	Oded Gabbay <ogabbay@kernel.org>
 L:	dri-devel@lists.freedesktop.org
@ -10313,13 +10283,6 @@ F:	Documentation/hwmon/ina2xx.rst
 F:	drivers/hwmon/ina2xx.c
 F:	include/linux/platform_data/ina2xx.h
 INCREMENTAL FILE SYSTEM
 M:	Paul Lawrence <paullawrence@google.com>
 L:	linux-unionfs@vger.kernel.org
 S:	Supported
 F:	fs/incfs/
 F:	tools/testing/selftests/filesystems/incfs/
 INDEX OF FURTHER KERNEL DOCUMENTATION
 M:	Carlos Bilbao <carlos.bilbao@amd.com>
 S:	Maintained
@ -20984,6 +20947,13 @@ F:	include/linux/sc[mp]i_protocol.h
 F:	include/trace/events/scmi.h
 F:	include/uapi/linux/virtio_scmi.h
 PINCTRL DRIVER FOR SYSTEM CONTROL MANAGEMENT INTERFACE (SCMI)
 M:	Oleksii Moisieiev <oleksii_moisieiev@epam.com>
 L:	linux-arm-kernel@lists.infradead.org
 S:	Maintained
 F:	drivers/firmware/arm_scmi/pinctrl.c
 F:	drivers/pinctrl/pinctrl-scmi.c
 SYSTEM RESET/SHUTDOWN DRIVERS
 M:	Sebastian Reichel <sre@kernel.org>
 L:	linux-pm@vger.kernel.org
--- a/115
+++ b/115
@ -1,9 +1,9 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 6
 PATCHLEVEL = 6
-SUBLEVEL = 58
+SUBLEVEL = 52
 EXTRAVERSION =
-NAME = Pinguïn Aangedreven
+NAME = Hurr durr I'ma ninja sloth
 # *DOCUMENTATION*
 # To see a list of typical targets execute "make help"
@ -155,24 +155,6 @@ endif
 export KBUILD_EXTMOD
 # ANDROID: set up mixed-build support. mixed-build allows device kernel modules
 # to be compiled against a GKI kernel. This approach still uses the headers and
 # Kbuild from device kernel, so care must be taken to ensure that those headers match.
 ifdef KBUILD_MIXED_TREE
 # Need vmlinux.symvers for modpost and System.map for depmod, check whether they exist in KBUILD_MIXED_TREE
 required_mixed_files=vmlinux.symvers System.map
 $(if $(filter-out $(words $(required_mixed_files)), \
 		$(words $(wildcard $(add-prefix $(KBUILD_MIXED_TREE)/,$(required_mixed_files))))),,\
 	$(error KBUILD_MIXED_TREE=$(KBUILD_MIXED_TREE) doesn't contain $(required_mixed_files)))
 endif
 mixed-build-prefix = $(if $(KBUILD_MIXED_TREE),$(KBUILD_MIXED_TREE)/)
 export KBUILD_MIXED_TREE
 # This is a hack for kleaf to set mixed-build-prefix within the execution of a make rule, e.g.
 # within __modinst_pre.
 # TODO(b/205893923): Revert this hack once it is properly handled.
 export mixed-build-prefix
 # Kbuild will save output files in the current working directory.
 # This does not need to match to the root of the kernel source tree.
 #
@ -536,7 +518,7 @@ KGZIP		= gzip
 KBZIP2		= bzip2
 KLZOP		= lzop
 LZMA		= lzma
-LZ4		= lz4
+LZ4		= lz4c
 XZ		= xz
 ZSTD		= zstd
@ -766,13 +748,11 @@ drivers-y	:=
 libs-y		:= lib/
 endif # KBUILD_EXTMOD
 ifndef KBUILD_MIXED_TREE
 # The all: target is the default when no target is given on the
 # command line.
 # This allow a user to issue only 'make' to build a kernel including modules
 # Defaults to vmlinux, but the arch makefile usually adds further targets
 all: vmlinux
 endif
 CFLAGS_GCOV	:= -fprofile-arcs -ftest-coverage
 ifdef CONFIG_CC_IS_GCC
@ -974,13 +954,7 @@ CC_FLAGS_LTO	:= -flto=thin -fsplit-lto-unit
 else
 CC_FLAGS_LTO	:= -flto
 endif
 ifeq ($(SRCARCH),x86)
 # Workaround for compiler / linker bug
 CC_FLAGS_LTO	+= -fvisibility=hidden
 else
 CC_FLAGS_LTO	+= -fvisibility=default
 endif
 # Limit inlining across translation units to reduce binary size
 KBUILD_LDFLAGS += -mllvm -import-instr-limit=5
@ -1002,9 +976,6 @@ endif
 ifdef CONFIG_CFI_CLANG
 CC_FLAGS_CFI	:= -fsanitize=kcfi
 ifdef CONFIG_RUST
 $(error "Enabling Rust and CFI silently changes the KMI.")
 endif
 KBUILD_CFLAGS	+= $(CC_FLAGS_CFI)
 export CC_FLAGS_CFI
 endif
@ -1129,40 +1100,6 @@ export extmod_prefix = $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/)
 export MODORDER := $(extmod_prefix)modules.order
 export MODULES_NSDEPS := $(extmod_prefix)modules.nsdeps
 # ---------------------------------------------------------------------------
 # Kernel headers
 PHONY += headers
 #Default location for installed headers
 ifeq ($(KBUILD_EXTMOD),)
 PHONY += archheaders archscripts
 hdr-inst := -f $(srctree)/scripts/Makefile.headersinst obj
 headers: $(version_h) scripts_unifdef uapi-asm-generic archheaders archscripts
 else
 hdr-prefix = $(KBUILD_EXTMOD)/
 hdr-inst := -f $(srctree)/scripts/Makefile.headersinst dst=$(KBUILD_EXTMOD)/usr/include objtree=$(objtree)/$(KBUILD_EXTMOD) obj
 endif
 export INSTALL_HDR_PATH = $(objtree)/$(hdr-prefix)usr
 quiet_cmd_headers_install = INSTALL $(INSTALL_HDR_PATH)/include
      cmd_headers_install = \
 	mkdir -p $(INSTALL_HDR_PATH); \
 	rsync -mrl --include='*/' --include='*\.h' --exclude='*' \
 	$(hdr-prefix)usr/include $(INSTALL_HDR_PATH);
 PHONY += headers_install
 headers_install: headers
 	$(call cmd,headers_install)
 headers:
 ifeq ($(KBUILD_EXTMOD),)
 	$(if $(filter um, $(SRCARCH)), $(error Headers not exportable for UML))
 endif
 	$(Q)$(MAKE) $(hdr-inst)=$(hdr-prefix)include/uapi
 	$(Q)$(MAKE) $(hdr-inst)=$(hdr-prefix)arch/$(SRCARCH)/include/uapi
 ifeq ($(KBUILD_EXTMOD),)
 build-dir	:= .
@ -1203,7 +1140,6 @@ targets += vmlinux.a
 vmlinux.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt FORCE
 	$(call if_changed,ar_vmlinux.a)
 ifndef KBUILD_MIXED_TREE
 PHONY += vmlinux_o
 vmlinux_o: vmlinux.a $(KBUILD_VMLINUX_LIBS)
 	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux_o
@ -1226,7 +1162,6 @@ vmlinux: private _LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
 vmlinux: export LDFLAGS_vmlinux = $(_LDFLAGS_vmlinux)
 vmlinux: vmlinux.o $(KBUILD_LDS) modpost
 	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux
 endif
 # The actual objects are generated when descending,
 # make sure no implicit rule kicks in
@ -1336,6 +1271,32 @@ headerdep:
 	$(Q)find $(srctree)/include/ -name '*.h' | xargs --max-args 1 \
 	$(srctree)/scripts/headerdep.pl -I$(srctree)/include
 # ---------------------------------------------------------------------------
 # Kernel headers
 #Default location for installed headers
 export INSTALL_HDR_PATH = $(objtree)/usr
 quiet_cmd_headers_install = INSTALL $(INSTALL_HDR_PATH)/include
      cmd_headers_install = \
 	mkdir -p $(INSTALL_HDR_PATH); \
 	rsync -mrl --include='*/' --include='*\.h' --exclude='*' \
 	usr/include $(INSTALL_HDR_PATH)
 PHONY += headers_install
 headers_install: headers
 	$(call cmd,headers_install)
 PHONY += archheaders archscripts
 hdr-inst := -f $(srctree)/scripts/Makefile.headersinst obj
 PHONY += headers
 headers: $(version_h) scripts_unifdef uapi-asm-generic archheaders archscripts
 	$(if $(filter um, $(SRCARCH)), $(error Headers not exportable for UML))
 	$(Q)$(MAKE) $(hdr-inst)=include/uapi
 	$(Q)$(MAKE) $(hdr-inst)=arch/$(SRCARCH)/include/uapi
 ifdef CONFIG_HEADERS_INSTALL
 prepare: headers
 endif
@ -1421,9 +1382,7 @@ kselftest-merge:
 # Devicetree files
 ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
-# ANDROID: allow this to be overridden by the build environment. This allows
+dtstree := arch/$(SRCARCH)/boot/dts
 # one to compile a device tree that is located out-of-tree.
 dtstree ?= arch/$(SRCARCH)/boot/dts
 endif
 ifneq ($(dtstree),)
@ -1501,7 +1460,7 @@ endif
 # is an exception.
 ifdef CONFIG_DEBUG_INFO_BTF_MODULES
 KBUILD_BUILTIN := 1
-modules: $(mixed-build-prefix)vmlinux
+modules: vmlinux
 endif
 modules: modules_prepare
@ -1845,8 +1804,6 @@ help:
 	@echo  ''
 	@echo  '  modules         - default target, build the module(s)'
 	@echo  '  modules_install - install the module'
 	@echo  '  headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH'
 	@echo  '                    (default: $(abspath $(INSTALL_HDR_PATH)))'
 	@echo  '  clean           - remove generated files in module directory only'
 	@echo  '  rust-analyzer	  - generate rust-project.json rust-analyzer support file'
 	@echo  ''
@ -1911,7 +1868,7 @@ KBUILD_MODULES :=
 endif # CONFIG_MODULES
 PHONY += modpost
-modpost: $(if $(single-build),, $(if $(KBUILD_MIXED_TREE),,$(if $(KBUILD_BUILTIN), vmlinux.o))) \
+modpost: $(if $(single-build),, $(if $(KBUILD_BUILTIN), vmlinux.o)) \
 	 $(if $(KBUILD_MODULES), modules_check)
 	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
@ -1961,7 +1918,7 @@ endif
 # Error messages still appears in the original language
 PHONY += $(build-dir)
 $(build-dir): prepare
-	$(Q)$(MAKE) $(build)=$@ $(if $(KBUILD_MIXED_TREE),,need-builtin=1) need-modorder=1 $(single-goals)
+	$(Q)$(MAKE) $(build)=$@ need-builtin=1 need-modorder=1 $(single-goals)
 clean-dirs := $(addprefix _clean_, $(clean-dirs))
 PHONY += $(clean-dirs) clean
@ -1970,9 +1927,7 @@ $(clean-dirs):
 clean: $(clean-dirs)
 	$(call cmd,rmfiles)
-	@find $(or $(KBUILD_EXTMOD), .) \
+	@find $(or $(KBUILD_EXTMOD), .) $(RCS_FIND_IGNORE) \
 		$(if $(filter-out arch/$(SRCARCH)/boot/dts, $(dtstree)), $(dtstree)) \
 		$(RCS_FIND_IGNORE) \
 		\( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
 		-o -name '*.ko.*' \
 		-o -name '*.dtb' -o -name '*.dtbo' \
@ -2019,7 +1974,7 @@ quiet_cmd_gen_compile_commands = GEN     $@
      cmd_gen_compile_commands = $(PYTHON3) $< -a $(AR) -o $@ $(filter-out $<, $(real-prereqs))
 $(extmod_prefix)compile_commands.json: scripts/clang-tools/gen_compile_commands.py \
-	$(if $(KBUILD_EXTMOD)$(KBUILD_MIXED_TREE),, vmlinux.a $(KBUILD_VMLINUX_LIBS)) \
+	$(if $(KBUILD_EXTMOD),, vmlinux.a $(KBUILD_VMLINUX_LIBS)) \
 	$(if $(CONFIG_MODULES), $(MODORDER)) FORCE
 	$(call if_changed,gen_compile_commands)
--- a/12
+++ b/12
@ -1,12 +0,0 @@
 set noparent
 # GKI Dr. No Enforcement is active on this branch. Approval of one of the Dr.
 # No reviewers is required following a regular CodeReview+2 vote of a code
 # reviewer.
 #
 # See the GKI release documentation (go/gki-dr-no) for further details.
 #
 # The expanded list of reviewers can be found at:
 # https://android.googlesource.com/kernel/common/+/android-mainline/OWNERS_DrNo
 include kernel/common:android-mainline:/OWNERS_DrNo
--- a/PREUPLOAD.cfg
+++ b/PREUPLOAD.cfg
@ -1,7 +0,0 @@
 [Builtin Hooks]
 checkpatch = true
 commit_msg_bug_field = true
 commit_msg_changeid_field = true
 [Builtin Hooks Options]
 checkpatch = --ignore=FILE_PATH_CHANGES,GERRIT_CHANGE_ID
--- a/README.md
+++ b/README.md
@ -1,150 +0,0 @@
 # How do I submit patches to Android Common Kernels
 1. BEST: Make all of your changes to upstream Linux. If appropriate, backport to the stable releases.
   These patches will be merged automatically in the corresponding common kernels. If the patch is already
   in upstream Linux, post a backport of the patch that conforms to the patch requirements below.
   - Do not send patches upstream that contain only symbol exports. To be considered for upstream Linux,
 additions of `EXPORT_SYMBOL_GPL()` require an in-tree modular driver that uses the symbol -- so include
 the new driver or changes to an existing driver in the same patchset as the export.
   - When sending patches upstream, the commit message must contain a clear case for why the patch
 is needed and beneficial to the community. Enabling out-of-tree drivers or functionality is not
 a persuasive case.
 2. LESS GOOD: Develop your patches out-of-tree (from an upstream Linux point-of-view). Unless these are
   fixing an Android-specific bug, these are very unlikely to be accepted unless they have been
   coordinated with kernel-team@android.com. If you want to proceed, post a patch that conforms to the
   patch requirements below.
 # Common Kernel patch requirements
 - All patches must conform to the Linux kernel coding standards and pass `scripts/checkpatch.pl`
 - Patches shall not break gki_defconfig or allmodconfig builds for arm, arm64, x86, x86_64 architectures
 (see  https://source.android.com/setup/build/building-kernels)
 - If the patch is not merged from an upstream branch, the subject must be tagged with the type of patch:
 `UPSTREAM:`, `BACKPORT:`, `FROMGIT:`, `FROMLIST:`, or `ANDROID:`.
 - All patches must have a `Change-Id:` tag (see https://gerrit-review.googlesource.com/Documentation/user-changeid.html)
 - If an Android bug has been assigned, there must be a `Bug:` tag.
 - All patches must have a `Signed-off-by:` tag by the author and the submitter
 Additional requirements are listed below based on patch type
 ## Requirements for backports from mainline Linux: `UPSTREAM:`, `BACKPORT:`
 - If the patch is a cherry-pick from Linux mainline with no changes at all
    - tag the patch subject with `UPSTREAM:`.
    - add upstream commit information with a `(cherry picked from commit ...)` line
    - Example:
        - if the upstream commit message is
 ```
        important patch from upstream
        This is the detailed description of the important patch
        Signed-off-by: Fred Jones <fred.jones@foo.org>
 ```
 >- then Joe Smith would upload the patch for the common kernel as
 ```
        UPSTREAM: important patch from upstream
        This is the detailed description of the important patch
        Signed-off-by: Fred Jones <fred.jones@foo.org>
        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry picked from commit c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        Signed-off-by: Joe Smith <joe.smith@foo.org>
 ```
 - If the patch requires any changes from the upstream version, tag the patch with `BACKPORT:`
 instead of `UPSTREAM:`.
    - use the same tags as `UPSTREAM:`
    - add comments about the changes under the `(cherry picked from commit ...)` line
    - Example:
 ```
        BACKPORT: important patch from upstream
        This is the detailed description of the important patch
        Signed-off-by: Fred Jones <fred.jones@foo.org>
        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry picked from commit c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        [joe: Resolved minor conflict in drivers/foo/bar.c ]
        Signed-off-by: Joe Smith <joe.smith@foo.org>
 ```
 ## Requirements for other backports: `FROMGIT:`, `FROMLIST:`,
 - If the patch has been merged into an upstream maintainer tree, but has not yet
 been merged into Linux mainline
    - tag the patch subject with `FROMGIT:`
    - add info on where the patch came from as `(cherry picked from commit <sha1> <repo> <branch>)`. This
 must be a stable maintainer branch (not rebased, so don't use `linux-next` for example).
    - if changes were required, use `BACKPORT: FROMGIT:`
    - Example:
        - if the commit message in the maintainer tree is
 ```
        important patch from upstream
        This is the detailed description of the important patch
        Signed-off-by: Fred Jones <fred.jones@foo.org>
 ```
 >- then Joe Smith would upload the patch for the common kernel as
 ```
        FROMGIT: important patch from upstream
        This is the detailed description of the important patch
        Signed-off-by: Fred Jones <fred.jones@foo.org>
        Bug: 135791357
        (cherry picked from commit 878a2fd9de10b03d11d2f622250285c7e63deace
         https://git.kernel.org/pub/scm/linux/kernel/git/foo/bar.git test-branch)
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>
 ```
 - If the patch has been submitted to LKML, but not accepted into any maintainer tree
    - tag the patch subject with `FROMLIST:`
    - add a `Link:` tag with a link to the submittal on lore.kernel.org
    - add a `Bug:` tag with the Android bug (required for patches not accepted into
 a maintainer tree)
    - if changes were required, use `BACKPORT: FROMLIST:`
    - Example:
 ```
        FROMLIST: important patch from upstream
        This is the detailed description of the important patch
        Signed-off-by: Fred Jones <fred.jones@foo.org>
        Bug: 135791357
        Link: https://lore.kernel.org/lkml/20190619171517.GA17557@someone.com/
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>
 ```
 ## Requirements for Android-specific patches: `ANDROID:`
 - If the patch is fixing a bug to Android-specific code
    - tag the patch subject with `ANDROID:`
    - add a `Fixes:` tag that cites the patch with the bug
    - Example:
 ```
        ANDROID: fix android-specific bug in foobar.c
        This is the detailed description of the important fix
        Fixes: 1234abcd2468 ("foobar: add cool feature")
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>
 ```
 - If the patch is a new feature
    - tag the patch subject with `ANDROID:`
    - add a `Bug:` tag with the Android bug (required for android-specific features)
--- a/abi.bzl
+++ b/abi.bzl
@ -1,136 +0,0 @@
 # SPDX-License-Identifier: GPL-2.0 OR Apache-2.0
 # Copyright (C) 2023 The Android Open Source Project
 """
 ABI aware build rules.
 """
 load("@bazel_skylib//lib:paths.bzl", "paths")
 load("@bazel_skylib//rules:copy_file.bzl", "copy_file")
 load("@bazel_skylib//rules:native_binary.bzl", "native_binary")
 visibility("private")
 _ALL_ABIS = ["arm", "arm64", "x86", "x86_64"]
 def _copy_with_abi(
        name,
        visibility = None,
        path_prefix = None,
        abis = None,
        out = None):
    if not path_prefix:
        path_prefix = ""
    if not abis:
        abis = _ALL_ABIS
    if not out:
        out = name
    for abi in abis:
        copy_file(
            name = "{name}_{abi}".format(name = name, abi = abi),
            src = ":{name}".format(name = name),
            out = paths.join(path_prefix, abi, out),
            allow_symlink = True,
            visibility = visibility,
        )
 def cc_binary_with_abi(
        name,
        path_prefix = None,
        abis = None,
        visibility = None,
        out = None,
        **kwargs):
    """A cc_binary replacement that generates output in each subdirectory named by abi.
    For example:
    ```
      cc_binary_with_abi(
        name = "a_binary",
        abis = ["x86_64", "arm64"],
        path_prefix = "my/path",
      )
    ```
    generates 2 rules:
    * Rule a_binary_x86_64: Builds the cc_binary and put output in my/path/x86_64/a_binary.
    * Rule a_binary_arm64: Builds the cc_binary and put output in my/path/arm64/a_binary.
    Args:
        name: the name of the build rule.
        path_prefix: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
          The path prefix to attach to output.
        abis: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
          The intended abis to generate. Default is arm64 & x86_64.
        visibility: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
          The visibility attribute on a target controls whether the target can be used in other packages.
        out: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
          The output filename. Default is `name`.
        **kwargs: the rest args that cc_binary uses.
    """
    native.cc_binary(
        name = name,
        visibility = visibility,
        **kwargs
    )
    _copy_with_abi(
        name = name,
        path_prefix = path_prefix,
        abis = abis,
        visibility = visibility,
        out = out,
    )
 def sh_binary_with_abi(
        name,
        path_prefix = None,
        abis = None,
        visibility = None,
        out = None,
        **kwargs):
    """A sh_binary replacement that generates output in each subdirectory named by abi.
    For example:
    ```
      sh_binary_with_abi(
        name = "a_binary",
        abis = ["x86_64", "arm64"],
        path_prefix = "my/path",
      )
    ```
    generates 2 rules:
    * Rule a_binary_x86_64: Copies a_binary and put output in my/path/x86_64/a_binary.
    * Rule a_binary_arm64: Copies a_binary and put output in my/path/arm64/a_binary.
    Args:
        name: the name of the build rule.
        path_prefix: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
          The path prefix to attach to output.
        abis: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
          The intended abis to generate. Default is arm64 & x86_64.
        visibility: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
          The visibility attribute on a target controls whether the target can be used in other packages.
        out: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
          The output filename. Default is `name`.
        **kwargs: the rest args that native_binary uses.
    """
    if not out:
        out = name
    # Uses native_binary instead of sh_binary because sh_binary is not
    # compatible with copy_file (sh_binary generates more than 1 outs).
    native_binary(
        name = name,
        visibility = visibility,
        out = out,
        **kwargs
    )
    _copy_with_abi(
        name = name,
        path_prefix = path_prefix,
        abis = abis,
        visibility = visibility,
        out = out,
    )
--- a/android/abi_gki_aarch64
+++ b/android/abi_gki_aarch64
@ -1,5 +0,0 @@
 [abi_symbol_list]
 # commonly used symbols
  module_layout
  __put_task_struct
  utf8_data_table
--- a/android/abi_gki_aarch64.stg
+++ b/android/abi_gki_aarch64.stg
--- a/android/abi_gki_aarch64.stg.allowed_breaks
+++ b/android/abi_gki_aarch64.stg.allowed_breaks
@ -1,103 +0,0 @@
 # How to use this file: http://go/approve-abi-break
 # ABI freeze commit: 666cbbfe5c567ca79da30dccad8b5257ca88f02c
 type 'struct shash_alg' changed
  member 'u64 android_backport_reserved1' was removed
  member 'u64 android_backport_reserved2' was removed
  member 'union { int(* finup_mb)(struct shash_desc*, const u8* const*, unsigned int, u8* const*, unsigned int); struct { u64 android_backport_reserved1; }; union { }; }' was added
  member 'union { unsigned int mb_max_msgs; struct { u64 android_backport_reserved2; }; union { }; }' was added
 type 'struct fsverity_info' changed
  byte size changed from 272 to 264
  member 'spinlock_t hash_page_init_lock' was removed
 type 'enum binder_work_type' changed
  enumerator 'BINDER_WORK_FROZEN_BINDER' (10) was added
  ... 1 other enumerator(s) added
 type 'struct ufs_clk_scaling' changed
  member 'bool suspend_on_no_request' was added
 type 'struct tty_operations' changed
  member 'u64 android_kabi_reserved1' was removed
  member 'union { int(* ldisc_ok)(struct tty_struct*, int); struct { u64 android_kabi_reserved1; }; union { }; }' was added
 type 'struct kvm_hyp_iommu' changed
  member changed from 'hyp_spinlock_t lock' to 'u32 lock'
    type changed from 'hyp_spinlock_t' = 'union hyp_spinlock' to 'u32' = '__u32' = 'unsigned int'
      resolved type changed from 'union hyp_spinlock' to 'unsigned int'
 type 'struct fsverity_hash_alg' changed
  member 'int mb_max_msgs' was added
 type 'struct pkvm_module_ops' changed
  member 'u64 android_kabi_reserved1' was removed
  member 'u64 android_kabi_reserved2' was removed
  member 'u64 android_kabi_reserved3' was removed
  member 'union { void(* iommu_flush_unmap_cache)(struct kvm_iommu_paddr_cache*); struct { u64 android_kabi_reserved1; }; union { }; }' was added
  member 'union { int(* host_stage2_enable_lazy_pte)(u64, u64); struct { u64 android_kabi_reserved2; }; union { }; }' was added
  member 'union { int(* host_stage2_disable_lazy_pte)(u64, u64); struct { u64 android_kabi_reserved3; }; union { }; }' was added
 type 'struct kvm_hyp_iommu' changed
  member 'u32 unused' was removed
  member 'u32 lock' was added
 type 'struct pkvm_module_ops' changed
  member 'u64 android_kabi_reserved2' was removed
  member 'u64 android_kabi_reserved3' was removed
  member 'union { int(* host_stage2_enable_lazy_pte)(u64, u64); struct { u64 android_kabi_reserved2; }; union { }; }' was added
  member 'union { int(* host_stage2_disable_lazy_pte)(u64, u64); struct { u64 android_kabi_reserved3; }; union { }; }' was added
 11 function symbol(s) removed
  'int __traceiter_android_rvh_ogki_hiview_hievent_create(void*, unsigned int, void**)'
  'int __traceiter_android_rvh_ogki_hiview_hievent_destroy(void*, void*)'
  'int __traceiter_android_rvh_ogki_hiview_hievent_put_integral(void*, void*, const char*, long long, int*)'
  'int __traceiter_android_rvh_ogki_hiview_hievent_put_string(void*, void*, const char*, const char*, int*)'
  'int __traceiter_android_rvh_ogki_hiview_hievent_report(void*, void*, int*)'
  'int __traceiter_android_rvh_ogki_security_audit_log_module_sign(void*, int)'
  'int __traceiter_android_rvh_ogki_security_audit_log_usercopy(void*, bool, const char*, unsigned long)'
  'int __traceiter_android_vh_ogki_security_audit_log_cfi(void*, unsigned long, unsigned long*)'
  'int __traceiter_android_vh_ogki_security_audit_log_setid(void*, u32, u32, u32)'
  'int __traceiter_android_vh_ogki_tcp_rcv_established_fast_path(void*, struct sock*)'
  'int __traceiter_android_vh_ogki_tcp_rcv_established_slow_path(void*, struct sock*)'
 11 variable symbol(s) removed
  'struct tracepoint __tracepoint_android_rvh_ogki_hiview_hievent_create'
  'struct tracepoint __tracepoint_android_rvh_ogki_hiview_hievent_destroy'
  'struct tracepoint __tracepoint_android_rvh_ogki_hiview_hievent_put_integral'
  'struct tracepoint __tracepoint_android_rvh_ogki_hiview_hievent_put_string'
  'struct tracepoint __tracepoint_android_rvh_ogki_hiview_hievent_report'
  'struct tracepoint __tracepoint_android_rvh_ogki_security_audit_log_module_sign'
  'struct tracepoint __tracepoint_android_rvh_ogki_security_audit_log_usercopy'
  'struct tracepoint __tracepoint_android_vh_ogki_security_audit_log_cfi'
  'struct tracepoint __tracepoint_android_vh_ogki_security_audit_log_setid'
  'struct tracepoint __tracepoint_android_vh_ogki_tcp_rcv_established_fast_path'
  'struct tracepoint __tracepoint_android_vh_ogki_tcp_rcv_established_slow_path'
 type 'enum ftrace_dump_mode' changed
  enumerator 'DUMP_PARAM' (3) was added
 1 function symbol(s) removed
  'int __traceiter_android_vh_suitable_migration_target_bypass(void*, struct page*, bool*)'
 1 variable symbol(s) removed
  'struct tracepoint __tracepoint_android_vh_suitable_migration_target_bypass'
 type 'struct cgroup_root' changed
  member 'u8 android_backport_reserved1[28]' was removed
  member 'union { struct callback_head rcu; struct { u8 android_backport_reserved1[28]; }; union { }; }' was added
 1 function symbol(s) removed
  'int __traceiter_android_vh_mutex_unlock_slowpath_before_wakeq(void*, struct mutex*)'
 1 variable symbol(s) removed
  'struct tracepoint __tracepoint_android_vh_mutex_unlock_slowpath_before_wakeq'
 2 function symbol(s) removed
  'int __traceiter_android_vh_mutex_unlock_slowpath_before_wakeq(void*, struct mutex*)'
  'int __traceiter_android_vh_suitable_migration_target_bypass(void*, struct page*, bool*)'
 2 variable symbol(s) removed
  'struct tracepoint __tracepoint_android_vh_mutex_unlock_slowpath_before_wakeq'
  'struct tracepoint __tracepoint_android_vh_suitable_migration_target_bypass'
--- a/android/abi_gki_aarch64_amlogic
+++ b/android/abi_gki_aarch64_amlogic
--- a/android/abi_gki_aarch64_asr
+++ b/android/abi_gki_aarch64_asr
@ -1,74 +0,0 @@
 [abi_symbol_list]
 # required by asr5803.ko
  sdhci_enable_sdio_irq
 # required by asr_serial.ko
  uart_get_divisor
  uart_handle_cts_change
  uart_handle_dcd_change
  uart_insert_char
 # required by ehci-asr-ci.ko
  ehci_init_driver
  ehci_setup
 # required by phy-asr-ci-usb2.ko
  usb_add_phy_dev
  usb_remove_phy
 # required by pvrsrvkm.ko
  call_rcu
  devm_devfreq_remove_device
  dev_pm_opp_remove
  dma_fence_array_ops
  dma_fence_enable_sw_signaling
  idr_replace
  kthread_freezable_should_stop
  rcu_barrier
 # required by sdhci_asr.ko
  sdhci_resume_host
  sdhci_send_tuning
  sdhci_set_clock
  sdhci_set_uhs_signaling
  sdhci_suspend_host
 # required by vh_sched.ko
  __traceiter_android_vh_map_util_freq
  __tracepoint_android_vh_map_util_freq
 # required by asr_drm.ko
  clk_set_rate_exclusive
  clk_rate_exclusive_put
 # required by mercury.ko
  media_device_register_entity
  media_device_unregister_entity
  v4l2_ctrl_get_menu
  v4l2_ctrl_type_op_equal
  v4l2_ctrl_type_op_init
  v4l2_ctrl_type_op_log
  v4l2_m2m_buf_done_and_job_finish
  v4l2_m2m_last_buf
  v4l2_type_names
  devm_devfreq_register_opp_notifier
 # required by jpu_heap.ko
  kmem_cache_size
  memset16
 # required by dwc3.ko
  extcon_find_edev_by_node
  phy_pm_runtime_put_sync
  usb_get_maximum_ssp_rate
 # required by xhci-asr.ko
  extcon_find_edev_by_node
 # required by clk-asr.ko
  clk_register_mux_table
 # required by keypad-asr.ko
  input_device_enabled
  fwnode_create_software_node
--- a/android/abi_gki_aarch64_asus
+++ b/android/abi_gki_aarch64_asus
@ -1,11 +0,0 @@
 [abi_symbol_list]
 # aura sync
  hid_unregister_driver
  hid_hw_raw_request
  hid_open_report
  hid_hw_start
  hid_hw_stop
  __hid_register_driver
  hid_hw_output_report
  hid_hw_open
  hid_hw_close
--- a/android/abi_gki_aarch64_db845c
+++ b/android/abi_gki_aarch64_db845c
--- a/android/abi_gki_aarch64_exynos
+++ b/android/abi_gki_aarch64_exynos
--- a/android/abi_gki_aarch64_exynosauto
+++ b/android/abi_gki_aarch64_exynosauto
--- a/android/abi_gki_aarch64_fips140
+++ b/android/abi_gki_aarch64_fips140
@ -1,146 +0,0 @@
 [abi_symbol_list]
 # commonly used symbols
  module_layout
  __put_task_struct
 # required by fips140.ko
  aead_register_instance
  ahash_register_instance
  arch_timer_read_counter
  bcmp
  complete_all
  completion_done
  cpu_have_feature
  crypto_aead_decrypt
  crypto_aead_encrypt
  crypto_aead_setauthsize
  crypto_aead_setkey
  crypto_ahash_finup
  crypto_ahash_setkey
  crypto_alg_list
  crypto_alg_sem
  crypto_alloc_aead
  crypto_alloc_rng
  crypto_alloc_shash
  crypto_alloc_skcipher
  crypto_attr_alg_name
  crypto_check_attr_type
  crypto_cipher_encrypt_one
  crypto_cipher_setkey
  crypto_clone_cipher
  crypto_clone_shash
  crypto_destroy_tfm
  crypto_drop_spawn
  crypto_get_default_null_skcipher
  crypto_grab_aead
  crypto_grab_ahash
  crypto_grab_shash
  crypto_grab_skcipher
  crypto_grab_spawn
  crypto_inst_setname
  crypto_put_default_null_skcipher
  crypto_register_aead
  crypto_register_aeads
  crypto_register_ahash
  crypto_register_ahashes
  crypto_register_alg
  crypto_register_algs
  crypto_register_rng
  crypto_register_rngs
  crypto_register_shash
  crypto_register_shashes
  crypto_register_skcipher
  crypto_register_skciphers
  crypto_register_template
  crypto_register_templates
  crypto_remove_spawns
  crypto_req_done
  crypto_rng_reset
  crypto_shash_digest
  crypto_shash_final
  crypto_shash_finup
  crypto_shash_setkey
  crypto_shash_tfm_digest
  crypto_shash_update
  crypto_skcipher_decrypt
  crypto_skcipher_encrypt
  crypto_skcipher_setkey
  crypto_spawn_tfm
  crypto_spawn_tfm2
  crypto_unregister_aeads
  crypto_unregister_alg
  crypto_unregister_rng
  crypto_unregister_rngs
  crypto_unregister_shash
  crypto_unregister_shashes
  crypto_unregister_skciphers
  crypto_unregister_template
  crypto_unregister_templates
  down_read
  down_write
  fortify_panic
  fpsimd_context_busy
  get_random_bytes
  __init_swait_queue_head
  irq_stat
  jiffies
  kasan_flag_enabled
  kernel_neon_begin
  kernel_neon_end
  kfree
  kfree_sensitive
  __kmalloc
  kmalloc_caches
  kmalloc_trace
  kmemdup
  ktime_get
  __list_add_valid_or_report
  __list_del_entry_valid_or_report
  memcpy
  memset
  __mutex_init
  mutex_lock
  mutex_unlock
  panic
  preempt_schedule_notrace
  _printk
  ___ratelimit
  _raw_spin_lock
  _raw_spin_unlock
  refcount_warn_saturate
  rng_is_initialized
  scatterwalk_ffwd
  scatterwalk_map_and_copy
  sg_init_one
  sg_init_table
  sg_next
  shash_free_singlespawn_instance
  shash_no_setkey
  shash_register_instance
  skcipher_alloc_instance_simple
  skcipher_register_instance
  skcipher_walk_aead_decrypt
  skcipher_walk_aead_encrypt
  skcipher_walk_done
  skcipher_walk_virt
  snprintf
  __stack_chk_fail
  strcmp
  strlen
  strncmp
  strnlen
  strscpy
  __traceiter_android_vh_aes_decrypt
  __traceiter_android_vh_aes_encrypt
  __traceiter_android_vh_aes_expandkey
  __traceiter_android_vh_sha256
  __tracepoint_android_vh_aes_decrypt
  __tracepoint_android_vh_aes_encrypt
  __tracepoint_android_vh_aes_expandkey
  __tracepoint_android_vh_sha256
  tracepoint_probe_register
  up_read
  up_write
  wait_for_completion
  xa_load
  xa_store
--- a/android/abi_gki_aarch64_galaxy
+++ b/android/abi_gki_aarch64_galaxy
@ -1,250 +0,0 @@
 [abi_symbol_list]
  blkcg_activate_policy
  blkcg_deactivate_policy
  blkcg_root
  blkdev_get_by_path
  blkdev_issue_flush
  blk_mq_sched_mark_restart_hctx
  blk_mq_sched_try_insert_merge
  blk_mq_sched_try_merge
  blk_queue_rq_timeout
  blk_req_needs_zone_write_lock
  __blk_req_zone_write_lock
  __blk_req_zone_write_unlock
  caches_clean_inval_pou
  cleancache_register_ops
  compact_node_async
  copy_page
  _dev_alert
  device_pm_wait_for_dev
  __devm_alloc_percpu
  dma_heap_try_get_pool_size_kb
  elv_bio_merge_ok
  elv_rb_add
  elv_rb_del
  elv_rb_find
  elv_rb_former_request
  elv_rb_latter_request
  elv_rqhash_add
  elv_rqhash_del
  free_hpage
  file_ra_state_init
  file_write_and_wait_range
  generic_perform_write
  getboottime64
  get_options
  __get_task_ioprio
  gpiochip_find
  gs_alloc_req
  gserial_free_line
  gserial_resume
  gserial_suspend
  gs_free_req
  kick_all_cpus_sync
  mas_walk
  mas_prev
  mas_next
  mm_access
  netlink_ack
  param_get_uint
  param_set_uint
  pidfd_get_pid
  prep_compound_page
  prep_new_hpage
  proc_set_size
  pstore_register
  pstore_unregister
  rfkill_find_type
  rfkill_get_led_trigger_name
  rfkill_pause_polling
  rfkill_set_led_trigger_name
  rfkill_set_states
  rfkill_soft_blocked
  scsi_device_quiesce
  scsi_device_resume
  smpboot_unregister_percpu_thread
  stack_trace_save_regs
  swp_swapcount
  __kfree_skb
  __traceiter_android_rvh_arm64_serror_panic
  __traceiter_android_rvh_die_kernel_fault
  __traceiter_android_rvh_do_el1_bti
  __traceiter_android_rvh_do_el1_fpac
  __traceiter_android_rvh_do_el1_undef
  __traceiter_android_rvh_do_sea
  __traceiter_android_rvh_do_sp_pc_abort
  __traceiter_android_rvh_ksys_umount
  __traceiter_android_rvh_panic_unhandled
  __traceiter_android_rvh_process_madvise_bypass
  __traceiter_android_rvh_report_bug
  __traceiter_android_rvh_try_alloc_pages
  __traceiter_android_rvh_try_alloc_pages_gfp
  __traceiter_android_rvh_usb_dev_suspend
  __traceiter_android_vh_alloc_contig_range_not_isolated
  __traceiter_android_vh_alloc_pages_slowpath_start
  __traceiter_android_vh_alloc_pages_slowpath_end
  __traceiter_android_vh_cache_show
  __traceiter_android_vh_cma_alloc_set_max_retries
  __traceiter_android_vh_cma_debug_show_areas
  __traceiter_android_vh_direct_reclaim_begin
  __traceiter_android_vh_direct_reclaim_end
  __traceiter_android_vh_dma_heap_buffer_alloc_start
  __traceiter_android_vh_dma_heap_buffer_alloc_end
  __traceiter_android_vh_dmabuf_page_pool_free_bypass
  __traceiter_android_vh_do_read_fault
  __traceiter_android_vh_dpm_wait_finish
  __traceiter_android_vh_dpm_wait_start
  __traceiter_android_vh_exit_mm
  __traceiter_android_vh_filemap_fault_start
  __traceiter_android_vh_filemap_fault_end
  __traceiter_android_vh_filemap_read
  __traceiter_android_vh_filemap_map_pages
  __traceiter_android_vh_flush_work_wait_finish
  __traceiter_android_vh_flush_work_wait_start
  __traceiter_android_vh_flush_wq_wait_finish
  __traceiter_android_vh_flush_wq_wait_start
  __traceiter_android_vh_free_pages_prepare_bypass
  __traceiter_android_vh_free_pages_ok_bypass
  __traceiter_android_vh_is_fpsimd_save
  __traceiter_android_vh_logbuf
  __traceiter_android_vh_logbuf_pr_cont
  __traceiter_android_vh_madvise_pageout_bypass
  __traceiter_android_vh_madvise_pageout_return_error
  __traceiter_android_vh_madvise_pageout_swap_entry
  __traceiter_android_vh_madvise_swapin_walk_pmd_entry
  __traceiter_android_vh_meminfo_proc_show
  __traceiter_android_vh_migration_target_bypass
  __traceiter_android_vh_mmc_update_mmc_queue
  __traceiter_android_vh_si_meminfo_adjust_shmem
  __traceiter_android_vh_shmem_mod_shmem
  __traceiter_android_vh_shmem_mod_swapped
  __traceiter_android_vh_page_cache_readahead_start
  __traceiter_android_vh_page_cache_readahead_end
  __traceiter_android_vh_print_slabinfo_header
  __traceiter_android_vh_process_madvise
  __traceiter_android_vh_process_madvise_return_error
  __traceiter_android_vh_psi_update_triggers
  __traceiter_android_vh_ptype_head
  __traceiter_android_vh_rebalance_anon_lru_bypass
  __traceiter_android_vh_rtmutex_wait_finish
  __traceiter_android_vh_show_mem
  __traceiter_android_vh_show_smap
  __traceiter_android_vh_smaps_pte_entry
  __traceiter_android_vh_smaps_swap_shared
  __traceiter_android_vh_show_smap_swap_shared
  __traceiter_android_vh_split_large_folio_bypass
  __traceiter_android_vh_sync_irq_wait_finish
  __traceiter_android_vh_sync_irq_wait_start
  __traceiter_android_vh_try_to_freeze_todo
  __traceiter_android_vh_try_to_freeze_todo_unfrozen
  __traceiter_android_vh_tune_scan_control
  __traceiter_android_vh_usb_dev_resume
  __traceiter_android_vh_usb_new_device_added
  __traceiter_android_vh_use_vm_swappiness
  __traceiter_android_vh_warn_alloc_tune_ratelimit
  __traceiter_android_vh_warn_alloc_show_mem_bypass
  __traceiter_android_vh_watchdog_timer_softlockup
  __traceiter_android_vh_wq_lockup_pool
  __traceiter_android_vh_xhci_resume
  __traceiter_android_vh_xhci_suspend
  __traceiter_android_vh_zs_shrinker_adjust
  __traceiter_android_vh_zs_shrinker_bypass
  __traceiter_console
  __traceiter_consume_skb
  __traceiter_error_report_end
  __traceiter_vm_unmapped_area
  __traceiter_workqueue_execute_start
  __traceiter_kfree_skb
  __tracepoint_android_rvh_arm64_serror_panic
  __tracepoint_android_rvh_die_kernel_fault
  __tracepoint_android_rvh_do_el1_bti
  __tracepoint_android_rvh_do_el1_fpac
  __tracepoint_android_rvh_do_el1_undef
  __tracepoint_android_rvh_do_sea
  __tracepoint_android_rvh_do_sp_pc_abort
  __tracepoint_android_rvh_ksys_umount
  __tracepoint_android_rvh_panic_unhandled
  __tracepoint_android_rvh_process_madvise_bypass
  __tracepoint_android_rvh_report_bug
  __tracepoint_android_rvh_try_alloc_pages
  __tracepoint_android_rvh_try_alloc_pages_gfp
  __tracepoint_android_rvh_usb_dev_suspend
  __tracepoint_android_vh_alloc_contig_range_not_isolated
  __tracepoint_android_vh_alloc_pages_slowpath_start
  __tracepoint_android_vh_alloc_pages_slowpath_end
  __tracepoint_android_vh_cache_show
  __tracepoint_android_vh_cma_alloc_set_max_retries
  __tracepoint_android_vh_cma_debug_show_areas
  __tracepoint_android_vh_direct_reclaim_begin
  __tracepoint_android_vh_direct_reclaim_end
  __tracepoint_android_vh_dma_heap_buffer_alloc_start
  __tracepoint_android_vh_dma_heap_buffer_alloc_end
  __tracepoint_android_vh_dmabuf_page_pool_free_bypass
  __tracepoint_android_vh_do_read_fault
  __tracepoint_android_vh_dpm_wait_finish
  __tracepoint_android_vh_dpm_wait_start
  __tracepoint_android_vh_exit_mm
  __tracepoint_android_vh_filemap_fault_start
  __tracepoint_android_vh_filemap_fault_end
  __tracepoint_android_vh_filemap_read
  __tracepoint_android_vh_filemap_map_pages
  __tracepoint_android_vh_flush_work_wait_finish
  __tracepoint_android_vh_flush_work_wait_start
  __tracepoint_android_vh_flush_wq_wait_finish
  __tracepoint_android_vh_flush_wq_wait_start
  __tracepoint_android_vh_free_pages_prepare_bypass
  __tracepoint_android_vh_free_pages_ok_bypass
  __tracepoint_android_vh_is_fpsimd_save
  __tracepoint_android_vh_logbuf
  __tracepoint_android_vh_logbuf_pr_cont
  __tracepoint_android_vh_madvise_pageout_bypass
  __tracepoint_android_vh_madvise_pageout_return_error
  __tracepoint_android_vh_madvise_pageout_swap_entry
  __tracepoint_android_vh_madvise_swapin_walk_pmd_entry
  __tracepoint_android_vh_meminfo_proc_show
  __tracepoint_android_vh_migration_target_bypass
  __tracepoint_android_vh_mmc_update_mmc_queue
  __tracepoint_android_vh_si_meminfo_adjust_shmem
  __tracepoint_android_vh_shmem_mod_shmem
  __tracepoint_android_vh_shmem_mod_swapped
  __tracepoint_android_vh_page_cache_readahead_start
  __tracepoint_android_vh_page_cache_readahead_end
  __tracepoint_android_vh_print_slabinfo_header
  __tracepoint_android_vh_process_madvise
  __tracepoint_android_vh_process_madvise_return_error
  __tracepoint_android_vh_psi_update_triggers
  __tracepoint_android_vh_ptype_head
  __tracepoint_android_vh_rebalance_anon_lru_bypass
  __tracepoint_android_vh_rtmutex_wait_finish
  __tracepoint_android_vh_show_mem
  __tracepoint_android_vh_show_smap
  __tracepoint_android_vh_smaps_pte_entry
  __tracepoint_android_vh_smaps_swap_shared
  __tracepoint_android_vh_show_smap_swap_shared
  __tracepoint_android_vh_split_large_folio_bypass
  __tracepoint_android_vh_sync_irq_wait_finish
  __tracepoint_android_vh_sync_irq_wait_start
  __tracepoint_android_vh_try_to_freeze_todo
  __tracepoint_android_vh_try_to_freeze_todo_unfrozen
  __tracepoint_android_vh_tune_scan_control
  __tracepoint_android_vh_usb_dev_resume
  __tracepoint_android_vh_usb_new_device_added
  __tracepoint_android_vh_use_vm_swappiness
  __tracepoint_android_vh_warn_alloc_tune_ratelimit
  __tracepoint_android_vh_warn_alloc_show_mem_bypass
  __tracepoint_android_vh_watchdog_timer_softlockup
  __tracepoint_android_vh_wq_lockup_pool
  __tracepoint_android_vh_xhci_resume
  __tracepoint_android_vh_xhci_suspend
  __tracepoint_android_vh_zs_shrinker_adjust
  __tracepoint_android_vh_zs_shrinker_bypass
  __tracepoint_console
  __tracepoint_consume_skb
  __tracepoint_error_report_end
  __tracepoint_vm_unmapped_area
  __tracepoint_workqueue_execute_start
  __tracepoint_kfree_skb
  usb_set_device_state
  yield
  regulator_get_current_limit
  android_create_function_device
--- a/android/abi_gki_aarch64_honor
+++ b/android/abi_gki_aarch64_honor
@ -1,254 +0,0 @@
 [abi_symbol_list]
  is_vmalloc_or_module_addr
  kfree
  __kmalloc
  arch_vma_name
  anon_vma_name
  walk_page_range
  vm_normal_page
  pmd_clear_bad
  __pmd_trans_huge_lock
  __pte_offset_map_lock
  mod_node_page_state
  page_cache_sync_ra
  proc_create
  profile_event_register
  si_swapinfo
  single_open
  sock_from_file
  task_cputime_adjusted
  tcp_sync_mss
  netdev_get_name
  tcp_send_active_reset
  fwnode_usb_role_switch_get 
  usb_for_each_dev
  dev_valid_name
  sock_from_file
  tcp_done
  udp4_lib_lookup
  udp6_lib_lookup
  rtc_time64_to_tm
  proc_create_net_single
  proc_create_net_single_write
  snmp_fold_field
  call_usermodehelper
  pm_wakeup_irq
  nla_append
  skb_append
  sysctl_max_skb_frags
  __show_mem
  find_vm_area
  profile_event_unregister
  binder_alloc_copy_from_buffer
  ufshcd_query_descriptor_retry
  ufshcd_query_attr
  nvmem_device_find
  device_match_of_node
  drop_super
  filp_open_block
  mm_trace_rss_stat
  get_slabinfo
  xas_find
  contpte_ptep_test_and_clear_young
  tty_dev_name_to_number
  tty_kopen_exclusive
  tty_unlock
  tty_set_ldisc
  tty_kclose
  android_debug_per_cpu_symbol
  android_debug_symbol
  __traceiter_rpm_idle
  __tracepoint_rpm_idle
  __traceiter_rpm_suspend
  __tracepoint_rpm_suspend
  __traceiter_rpm_resume
  __tracepoint_rpm_resume
  __traceiter_rpm_return_int
  __tracepoint_rpm_return_int
  __kfifo_len_r
  __traceiter_android_vh_killed_process
  __tracepoint_android_vh_killed_process
  __traceiter_android_vh_rwsem_write_wait_finish
  __tracepoint_android_vh_rwsem_write_wait_finish
  __tracepoint_android_rvh_cpuinfo_c_show
  __traceiter_android_rvh_cpuinfo_c_show
  __tracepoint_android_vh_dc_send_copy
  __traceiter_android_vh_dc_send_copy
  __tracepoint_android_vh_dc_receive
  __traceiter_android_vh_dc_receive
  __traceiter_android_vh_inet_create
  __tracepoint_android_vh_inet_create
  __traceiter_android_vh_uplink_send_msg
  __tracepoint_android_vh_uplink_send_msg
  __traceiter_android_vh_sock_create
  __tracepoint_android_vh_sock_create
  __traceiter_android_vh_modify_scan_control
  __traceiter_android_vh_should_continue_reclaim
  __tracepoint_android_vh_process_madvise_begin
  __traceiter_android_vh_process_madvise_begin
  __tracepoint_android_vh_process_madvise_iter
  __traceiter_android_vh_process_madvise_iter
  __traceiter_android_vh_file_is_tiny_bypass
  __tracepoint_android_vh_modify_scan_control
  __tracepoint_android_vh_should_continue_reclaim
  __tracepoint_android_vh_file_is_tiny_bypass
  __tracepoint_android_vh_shrink_slab_bypass
  __traceiter_android_vh_shrink_slab_bypass
  __tracepoint_android_vh_do_shrink_slab
  __traceiter_android_vh_do_shrink_slab
  __tracepoint_android_vh_shrink_slab_bypass
  __traceiter_android_vh_shrink_slab_bypass
  __tracepoint_android_vh_slab_alloc_node
  __traceiter_android_vh_slab_alloc_node
  __tracepoint_android_vh_slab_free
  __traceiter_android_vh_slab_free
  __traceiter_android_vh_should_fault_around
  __tracepoint_android_vh_should_fault_around
  __traceiter_android_vh_mglru_should_abort_scan
  __tracepoint_android_vh_mglru_should_abort_scan
  __traceiter_android_vh_mglru_should_abort_scan_order
  __tracepoint_android_vh_mglru_should_abort_scan_order
  __traceiter_android_vh_tcp_connect
  __tracepoint_android_vh_tcp_connect
  __traceiter_android_vh_tcp_write_timeout_estab_retrans
  __tracepoint_android_vh_tcp_write_timeout_estab_retrans
  __traceiter_android_vh_inet_csk_clone_lock
  __tracepoint_android_vh_inet_csk_clone_lock
  __traceiter_android_vh_tcp_clean_rtx_queue
  __tracepoint_android_vh_tcp_clean_rtx_queue
  __traceiter_android_vh_tcp_rcv_synack
  __tracepoint_android_vh_tcp_rcv_synack
  __traceiter_android_vh_udp_unicast_rcv_skb
  __tracepoint_android_vh_udp_unicast_rcv_skb
  __traceiter_android_vh_udp6_unicast_rcv_skb
  __tracepoint_android_vh_udp6_unicast_rcv_skb
  __traceiter_android_vh_tcp_rcv_established_fast_path
  __tracepoint_android_vh_tcp_rcv_established_fast_path
  __traceiter_android_vh_tcp_rcv_established_slow_path
  __tracepoint_android_vh_tcp_rcv_established_slow_path
  __tracepoint_android_vh_si_mem_available_adjust
  __traceiter_android_vh_si_mem_available_adjust
  __tracepoint_android_vh_si_meminfo_adjust
  __traceiter_android_vh_si_meminfo_adjust
  __traceiter_android_vh_rwsem_write_finished
  __tracepoint_android_vh_rwsem_write_finished
  __traceiter_android_vh_tcp_v4_connect
  __tracepoint_android_vh_tcp_v4_connect
  __traceiter_android_vh_tcp_v6_connect
  __tracepoint_android_vh_tcp_v6_connect
  __traceiter_android_vh_udp_v4_connect
  __tracepoint_android_vh_udp_v4_connect
  __traceiter_android_vh_udp_v6_connect
  __tracepoint_android_vh_udp_v6_connect
  __traceiter_android_rvh_dma_buf_stats_teardown
  __tracepoint_android_rvh_dma_buf_stats_teardown
  __traceiter_android_rvh_hw_protection_shutdown
  __tracepoint_android_rvh_hw_protection_shutdown
  __traceiter_android_rvh_bpf_int_jit_compile_ro
  __tracepoint_android_rvh_bpf_int_jit_compile_ro
  __traceiter_android_vh_tcp_sock_error
  __tracepoint_android_vh_tcp_sock_error
  __traceiter_android_vh_tcp_select_window
  __tracepoint_android_vh_tcp_select_window
  __traceiter_android_vh_tcp_fastsyn
  __tracepoint_android_vh_tcp_fastsyn
  __traceiter_android_vh_tcp_state_change
  __tracepoint_android_vh_tcp_state_change
  __traceiter_android_vh_tcp_update_rtt
  __tracepoint_android_vh_tcp_update_rtt
  __traceiter_android_vh_sk_alloc
  __tracepoint_android_vh_sk_alloc
  __traceiter_android_vh_sk_free
  __tracepoint_android_vh_sk_free
  __traceiter_android_vh_sk_clone_lock
  __tracepoint_android_vh_sk_clone_lock
  __traceiter_android_rvh_f2fs_down_read
  __tracepoint_android_rvh_f2fs_down_read
  __traceiter_android_vh_f2fs_improve_priority
  __tracepoint_android_vh_f2fs_improve_priority
  __traceiter_android_vh_f2fs_restore_priority
  __tracepoint_android_vh_f2fs_restore_priority
  __traceiter_android_vh_cma_alloc_retry
  __tracepoint_android_vh_cma_alloc_retry
  __tracepoint_android_vh_should_memcg_bypass
  __traceiter_android_vh_should_memcg_bypass
  __traceiter_android_rvh_ogki_vfree_bypass
  __traceiter_android_rvh_ogki_vmalloc_node_bypass
  __traceiter_android_vh_ogki_async_psi_bypass
  __traceiter_android_vh_ogki_f2fs_dsm
  __traceiter_android_vh_ogki_f2fs_dsm_get
  __tracepoint_android_vh_ogki_f2fs_create
  __traceiter_android_vh_ogki_f2fs_create
  __tracepoint_android_vh_ogki_f2fs_submit_write_page
  __traceiter_android_vh_ogki_f2fs_submit_write_page
  __traceiter_android_vh_ogki_check_vip_status
  __traceiter_android_vh_ogki_cma_alloc_retry
  __traceiter_android_vh_ogki_ufs_dsm
  __tracepoint_android_rvh_ogki_vfree_bypass
  __tracepoint_android_rvh_ogki_vmalloc_node_bypass
  __tracepoint_android_vh_ogki_async_psi_bypass
  __tracepoint_android_vh_ogki_f2fs_dsm
  __tracepoint_android_vh_ogki_f2fs_dsm_get
  __tracepoint_android_vh_ogki_check_vip_status
  __tracepoint_android_vh_ogki_cma_alloc_retry
  __tracepoint_android_vh_ogki_ufs_dsm
  __tracepoint_scsi_dispatch_cmd_start
  __traceiter_scsi_dispatch_cmd_start
  __traceiter_android_vh_ogki_tcp_srtt_estimator
  __tracepoint_android_vh_ogki_tcp_srtt_estimator
  __traceiter_android_vh_ogki_tcp_rcv_estab_fastpath
  __tracepoint_android_vh_ogki_tcp_rcv_estab_fastpath
  __traceiter_android_vh_ogki_tcp_rcv_estab_slowpath
  __tracepoint_android_vh_ogki_tcp_rcv_estab_slowpath
  __traceiter_android_vh_ogki_tcp_rcv_rtt_update
  __tracepoint_android_vh_ogki_tcp_rcv_rtt_update
  __traceiter_android_vh_ogki_tcp_retransmit_timer
  __tracepoint_android_vh_ogki_tcp_retransmit_timer
  __traceiter_android_vh_ogki_udp_unicast_rcv_skb
  __tracepoint_android_vh_ogki_udp_unicast_rcv_skb
  __traceiter_android_vh_ogki_udp6_unicast_rcv_skb
  __tracepoint_android_vh_ogki_udp6_unicast_rcv_skb
  __tracepoint_android_rvh_ogki_task_util
  __traceiter_android_rvh_ogki_task_util
  __tracepoint_android_rvh_ogki_uclamp_task_util
  __traceiter_android_rvh_ogki_uclamp_task_util
  __tracepoint_android_rvh_ogki_get_task_tags
  __traceiter_android_rvh_ogki_get_task_tags
  __tracepoint_android_rvh_ogki_get_task_rsum
  __traceiter_android_rvh_ogki_get_task_rsum
  __tracepoint_android_rvh_ogki_check_task_tags
  __traceiter_android_rvh_ogki_check_task_tags
  __tracepoint_android_vh_ogki_audit_log_cfi
  __tracepoint_android_rvh_ogki_audit_log_usercopy
  __tracepoint_android_rvh_ogki_audit_log_module_sign
  __tracepoint_android_vh_ogki_audit_log_setid
  __traceiter_android_vh_ogki_audit_log_cfi
  __traceiter_android_rvh_ogki_audit_log_usercopy
  __traceiter_android_rvh_ogki_audit_log_module_sign
  __traceiter_android_vh_ogki_audit_log_setid
  __traceiter_android_vh_ogki_get_log_usertype
  __tracepoint_android_vh_ogki_get_log_usertype
  __traceiter_android_rvh_ogki_hievent_create
  __tracepoint_android_rvh_ogki_hievent_create
  __traceiter_android_rvh_ogki_hievent_put_string
  __tracepoint_android_rvh_ogki_hievent_put_string
  __traceiter_android_rvh_ogki_hievent_put_integral
  __tracepoint_android_rvh_ogki_hievent_put_integral
  __traceiter_android_rvh_ogki_hievent_report
  __tracepoint_android_rvh_ogki_hievent_report
  __traceiter_android_rvh_ogki_hievent_destroy
  __tracepoint_android_rvh_ogki_hievent_destroy
  __traceiter_android_vh_ogki_hievent_to_jank
  __tracepoint_android_vh_ogki_hievent_to_jank
  __tracepoint_android_vh_ogki_set_wifi_state_connect
  __traceiter_android_vh_ogki_set_wifi_state_connect
  __tracepoint_android_vh_ogki_set_wifi_state_disconnect
  __traceiter_android_vh_ogki_set_wifi_state_disconnect
  __traceiter_android_vh_ogki_kmem_cache_create_usercopy
  __tracepoint_android_vh_ogki_kmem_cache_create_usercopy
  __traceiter_android_vh_wq_queue_work
  __traceiter_android_vh_wq_wake_idle_worker
  __tracepoint_android_vh_wq_queue_work
  __tracepoint_android_vh_wq_wake_idle_worker
  __traceiter_android_vh_mutex_unlock_slowpath_bf_wakeq
  __tracepoint_android_vh_mutex_unlock_slowpath_bf_wakeq
--- a/android/abi_gki_aarch64_imx
+++ b/android/abi_gki_aarch64_imx
--- a/android/abi_gki_aarch64_kunit
+++ b/android/abi_gki_aarch64_kunit
@ -1,38 +0,0 @@
 [abi_symbol_list]
 # required by drivers
  kunit_hooks
  kunit_running
 # required by tests
  __kunit_abort
  __kunit_activate_static_stub
  kunit_add_action
  kunit_add_action_or_reset
  __kunit_add_resource
  kunit_assert_prologue
  kunit_binary_assert_format
  kunit_binary_ptr_assert_format
  kunit_binary_str_assert_format
  kunit_cleanup
  kunit_deactivate_static_stub
  kunit_destroy_resource
  __kunit_do_failed_assertion
  kunit_fail_assert_format
  kunit_init_test
  kunit_kfree
  kunit_kmalloc_array
  kunit_log_append
  kunit_mem_assert_format
  kunit_ptr_not_err_assert_format
  kunit_release_action
  kunit_remove_action
  kunit_remove_resource
  kunit_run_tests
  kunit_suite_has_succeeded
  kunit_suite_num_test_cases
  kunit_test_case_num
  __kunit_test_suites_exit
  __kunit_test_suites_init
  kunit_try_catch_run
  kunit_try_catch_throw
  kunit_unary_assert_format
--- a/android/abi_gki_aarch64_lenovo
+++ b/android/abi_gki_aarch64_lenovo
--- a/android/abi_gki_aarch64_mtk
+++ b/android/abi_gki_aarch64_mtk
--- a/android/abi_gki_aarch64_mtktv
+++ b/android/abi_gki_aarch64_mtktv
--- a/android/abi_gki_aarch64_nothing
+++ b/android/abi_gki_aarch64_nothing
@ -1,181 +0,0 @@
 [abi_symbol_list]
 # commonly used symbols
  module_layout
  __put_task_struct
 # required by ntfs3.ko
  balance_dirty_pages_ratelimited
  __bh_read
  bh_uptodate_or_lock
  bio_add_page
  bio_alloc_bioset
  bio_chain
  bio_put
  blkdev_issue_discard
  blkdev_issue_zeroout
  blk_finish_plug
  blk_start_plug
  __blockdev_direct_IO
  block_dirty_folio
  block_invalidate_folio
  block_truncate_page
  block_write_begin
  block_write_end
  __bread_gfp
  __brelse
  buffer_migrate_folio
  clean_bdev_aliases
  clear_inode
  clear_nlink
  copy_page_from_iter_atomic
  create_empty_buffers
  current_time
  current_umask
  dentry_path_raw
  d_find_alias
  d_instantiate
  discard_new_inode
  d_make_root
  d_obtain_alias
  down_write_trylock
  dput
  drop_nlink
  d_splice_alias
  errseq_set
  fault_in_iov_iter_readable
  fiemap_fill_next_extent
  fiemap_prep
  filemap_fdatawait_range
  filemap_fdatawrite
  filemap_fdatawrite_range
  __filemap_set_wb_err
  filemap_splice_read
  filemap_write_and_wait_range
  file_modified
  file_remove_privs
  file_update_time
  finish_no_open
  finish_open
  flush_dcache_page
  __folio_lock
  __folio_put
  folio_set_bh
  folio_unlock
  fs_bio_set
  fscrypt_file_open
  fs_param_is_string
  fs_param_is_u32
  __fs_parse
  fs_umode_to_dtype
  generic_block_bmap
  generic_fh_to_dentry
  generic_fh_to_parent
  generic_file_fsync
  generic_file_llseek
  generic_file_mmap
  generic_file_open
  generic_file_read_iter
  __generic_file_write_iter
  generic_fillattr
  generic_read_dir
  generic_write_checks
  generic_write_end
  __getblk_gfp
  get_fs_type
  get_inode_acl
  get_tree_bdev
  grab_cache_page_write_begin
  hex_asc
  iget5_locked
  iget_failed
  ihold
  ilookup
  inc_nlink
  __init_rwsem
  init_special_inode
  init_user_ns
  inode_dio_wait
  inode_get_bytes
  inode_init_once
  inode_init_owner
  inode_newsize_ok
  inode_nohighmem
  inode_set_bytes
  inode_set_ctime_current
  insert_inode_locked
  invalidate_bdev
  invalidate_inode_buffers
  iov_iter_zero
  iput
  is_bad_inode
  iterate_supers_type
  iter_file_splice_write
  kfree_link
  kill_block_super
  kmem_cache_alloc_lru
  load_nls
  load_nls_default
  __lock_buffer
  lockref_get
  logfc
  make_bad_inode
  mark_buffer_dirty
  __mark_inode_dirty
  mpage_readahead
  mpage_read_folio
  mpage_writepages
  names_cachep
  new_inode
  overflowgid
  overflowuid
  pagecache_get_page
  page_pinner_inited
  __page_pinner_put_page
  posix_acl_chmod
  posix_acl_create
  posix_acl_from_xattr
  posix_acl_to_xattr
  posix_acl_update_mode
  proc_create_data
  proc_mkdir
  rb_first
  rb_last
  rb_prev
  read_cache_page
  register_filesystem
  remove_proc_entry
  sb_set_blocksize
  setattr_copy
  setattr_prepare
  set_cached_acl
  set_nlink
  set_page_dirty
  simple_rename_timestamp
  submit_bio
  submit_bio_wait
  sync_blockdev
  sync_blockdev_nowait
  sync_dirty_buffer
  sync_filesystem
  sync_inode_metadata
  sync_mapping_buffers
  truncate_inode_pages_final
  truncate_pagecache
  truncate_setsize
  unload_nls
  unlock_buffer
  unlock_new_inode
  unlock_page
  unregister_filesystem
  utf16s_to_utf8s
  utf8_to_utf32
  vfs_fsync_range
  vm_zone_stat
  __wait_on_buffer
  write_cache_pages
  write_inode_now
 # required by thermal_core_skip_irq.ko
  __traceiter_android_vh_thermal_pm_notify_suspend
  __tracepoint_android_vh_thermal_pm_notify_suspend
  tracepoint_probe_register
--- a/Show More
+++ b/Show More
		`@ -1,2 +0,0 @@`
			`# include OWNERS from the top level trusty repo`
			`include trusty:refs/meta/config:/OWNERS`