Merge tag 'v6.11-rc1' into clk-meson-next

Linux 6.11-rc1

Author: jbrun3t

.clang-format

@@ -4,7 +4,7 @@
 #
 # For more information, see:
 #
-#   Documentation/process/clang-format.rst
+#   Documentation/dev-tools/clang-format.rst
 #   https://clang.llvm.org/docs/ClangFormat.html
 #   https://clang.llvm.org/docs/ClangFormatStyleOptions.html
 #

.editorconfig

@@ -5,15 +5,13 @@ root = true
 [{*.{awk,c,dts,dtsi,dtso,h,mk,s,S},Kconfig,Makefile,Makefile.*}]
 charset = utf-8
 end_of_line = lf
-trim_trailing_whitespace = true
 insert_final_newline = true
 indent_style = tab
 indent_size = 8
 
 [*.{json,py,rs}]
 charset = utf-8
 end_of_line = lf
-trim_trailing_whitespace = true
 insert_final_newline = true
 indent_style = space
 indent_size = 4
@@ -26,7 +24,6 @@ indent_size = 8
 [*.yaml]
 charset = utf-8
 end_of_line = lf
-trim_trailing_whitespace = unset
 insert_final_newline = true
 indent_style = space
 indent_size = 2

.gitignore

@@ -92,6 +92,12 @@ modules.order
 #
 /tar-install/
 
+#
+# pacman files (make pacman-pkg)
+#
+/PKGBUILD
+/pacman/
+
 #
 # We don't want to ignore the following even if they are dot-files
 #

.mailmap

@@ -72,6 +72,8 @@ Andrey Ryabinin <[email protected]> <[email protected]>
 Andrzej Hajda <[email protected]> <[email protected]>
 André Almeida <[email protected]> <[email protected]>
 Andy Adamson <[email protected]>
+Andy Shevchenko <[email protected]> <[email protected]>
+Andy Shevchenko <[email protected]> <[email protected]>
 Anilkumar Kolli <[email protected]> <[email protected]>
 Anirudh Ghayal <[email protected]> <[email protected]>
 Antoine Tenart <[email protected]> <[email protected]>
@@ -217,6 +219,7 @@ Geliang Tang <[email protected]> <[email protected]>
 Geliang Tang <[email protected]> <[email protected]>
 Geliang Tang <[email protected]> <[email protected]>
 Geliang Tang <[email protected]> <[email protected]>
+Geliang Tang <[email protected]> <[email protected]>
 Georgi Djakov <[email protected]> <[email protected]>
 Gerald Schaefer <[email protected]> <[email protected]>
 Gerald Schaefer <[email protected]> <[email protected]>
@@ -257,6 +260,7 @@ Jaegeuk Kim <[email protected]> <[email protected]>
 Jakub Kicinski <[email protected]> <[email protected]>
 James Bottomley <jejb@mulgrave.(none)>
 James Bottomley <[email protected]>
+James Clark <[email protected]> <[email protected]>
 James E Wilson <[email protected]>
 James Hogan <[email protected]> <[email protected]>
 James Hogan <[email protected]> <[email protected]>
@@ -337,10 +341,11 @@ Kalyan Thota <[email protected]> <[email protected]>
 Karthikeyan Periyasamy <[email protected]> <[email protected]>
 Kathiravan T <[email protected]> <[email protected]>
 Kay Sievers <[email protected]>
-Kees Cook <[email protected]> <[email protected]>
-Kees Cook <[email protected]> <[email protected]>
-Kees Cook <[email protected]> <[email protected]>
-Kees Cook <[email protected]> <[email protected]>
+Kees Cook <[email protected]> <[email protected]>
+Kees Cook <[email protected]> <[email protected]>
+Kees Cook <[email protected]> <[email protected]>
+Kees Cook <[email protected]> <[email protected]>
+Kees Cook <[email protected]> <[email protected]>
 Keith Busch <[email protected]> <[email protected]>
 Keith Busch <[email protected]> <[email protected]>
 Kenneth W Chen <[email protected]>
@@ -380,7 +385,9 @@ Li Yang <[email protected]> <[email protected]>
 Li Yang <[email protected]> <[email protected]>
 Lior David <[email protected]> <[email protected]>
 Lorenzo Pieralisi <[email protected]> <[email protected]>
+Lorenzo Stoakes <[email protected]> <[email protected]>
 Luca Ceresoli <[email protected]> <[email protected]>
+Luca Weiss <[email protected]> <[email protected]>
 Lukasz Luba <[email protected]> <[email protected]>
 Luo Jie <[email protected]> <[email protected]>
 Maciej W. Rozycki <[email protected]> <[email protected]>
@@ -468,6 +475,8 @@ Nadia Yvette Chambers <[email protected]> William Lee Irwin III <wli@holomorphy
 Naoya Horiguchi <[email protected]> <[email protected]>
 Naoya Horiguchi <[email protected]> <[email protected]>
 Nathan Chancellor <[email protected]> <[email protected]>
+Naveen N Rao <[email protected]> <[email protected]>
+Naveen N Rao <[email protected]> <[email protected]>
 Neeraj Upadhyay <[email protected]> <[email protected]>
 Neeraj Upadhyay <[email protected]> <[email protected]>
 Neil Armstrong <[email protected]> <[email protected]>
@@ -604,6 +613,7 @@ Simon Kelley <[email protected]>
 Sricharan Ramabadhran <[email protected]> <[email protected]>
 Srinivas Ramana <[email protected]> <[email protected]>
 Sriram R <[email protected]> <[email protected]>
+Stanislav Fomichev <[email protected]> <[email protected]>
 Stefan Wahren <[email protected]> <[email protected]>
 Stéphane Witzmann <[email protected]>
 Stephen Hemminger <[email protected]> <[email protected]>
@@ -684,6 +694,7 @@ Vivien Didelot <[email protected]> <[email protected]>
 Vlad Dogaru <[email protected]> <[email protected]>
 Vladimir Davydov <[email protected]> <[email protected]>
 Vladimir Davydov <[email protected]> <[email protected]>
+Weiwen Hu <[email protected]> <[email protected]>
 WeiXiong Liao <[email protected]> <[email protected]>
 Wen Gong <[email protected]> <[email protected]>
 Wesley Cheng <[email protected]> <[email protected]>

CREDITS

@@ -531,6 +531,13 @@ S: Kopmansg 2
 S: 411 13  Goteborg
 S: Sweden
 
+N: Daniel Bristot de Oliveira
+D: Scheduler contributions, notably: SCHED_DEADLINE
+D: Real-time Linux Analysis
+D: Runtime Verification
+D: OS Noise and Latency Tracers
+S: Brazil and Italy
+
 N: Paul Bristow
 E: [email protected]
 W: https://paulbristow.net/linux/idefloppy.html
@@ -796,6 +803,11 @@ E: [email protected]
 D: Ralink rt2x00 WLAN driver
 S: Belas, Portugal
 
+N: Benoît Cousson
+E: [email protected]
+D: TI OMAP Devicetree platforms
+D: TI OMAP HWMOD boards
+
 N: Alan Cox
 W: http://www.linux.org.uk/diary/
 D: Linux Networking (0.99.10->2.0.29)
@@ -1214,6 +1226,10 @@ D: UDF filesystem
 S: (ask for current address)
 S: USA
 
+N: Larry Finger
+E: [email protected]
+D: Maintainer of wireless drivers, too many to list here
+
 N: Jürgen Fischer
 E: [email protected]
 D: Author of Adaptec AHA-152x SCSI driver
@@ -3146,9 +3162,11 @@ S: Triftstra=DFe 55
 S: 13353 Berlin
 S: Germany
 
-N: Gustavo Pimental
+N: Gustavo Pimentel
 E: [email protected]
 D: PCI driver for Synopsys DesignWare
+D: Synopsys DesignWare eDMA driver
+D: Synopsys DesignWare xData traffic generator
 
 N: Emanuel Pirker
 E: [email protected]
@@ -4362,6 +4380,10 @@ N: Haojian Zhuang
 E: [email protected]
 D: MMP support
 
+N: Tsahee Zidenberg
+E: [email protected]
+D: Annapurna Labs Alpine Architecture
+
 N: Richard Zidlicky
 E: [email protected], [email protected]
 W: http://www.geocities.com/rdzidlic

Documentation/ABI/stable/sysfs-block

@@ -21,6 +21,59 @@ Description:
 		device is offset from the internal allocation unit's
 		natural alignment.
 
+What:		/sys/block/<disk>/atomic_write_max_bytes
+Date:		February 2024
+Contact:	Himanshu Madhani <[email protected]>
+Description:
+		[RO] This parameter specifies the maximum atomic write
+		size reported by the device. This parameter is relevant
+		for merging of writes, where a merged atomic write
+		operation must not exceed this number of bytes.
+		This parameter may be greater than the value in
+		atomic_write_unit_max_bytes as
+		atomic_write_unit_max_bytes will be rounded down to a
+		power-of-two and atomic_write_unit_max_bytes may also be
+		limited by some other queue limits, such as max_segments.
+		This parameter - along with atomic_write_unit_min_bytes
+		and atomic_write_unit_max_bytes - will not be larger than
+		max_hw_sectors_kb, but may be larger than max_sectors_kb.
+
+
+What:		/sys/block/<disk>/atomic_write_unit_min_bytes
+Date:		February 2024
+Contact:	Himanshu Madhani <[email protected]>
+Description:
+		[RO] This parameter specifies the smallest block which can
+		be written atomically with an atomic write operation. All
+		atomic write operations must begin at a
+		atomic_write_unit_min boundary and must be multiples of
+		atomic_write_unit_min. This value must be a power-of-two.
+
+
+What:		/sys/block/<disk>/atomic_write_unit_max_bytes
+Date:		February 2024
+Contact:	Himanshu Madhani <[email protected]>
+Description:
+		[RO] This parameter defines the largest block which can be
+		written atomically with an atomic write operation. This
+		value must be a multiple of atomic_write_unit_min and must
+		be a power-of-two. This value will not be larger than
+		atomic_write_max_bytes.
+
+
+What:		/sys/block/<disk>/atomic_write_boundary_bytes
+Date:		February 2024
+Contact:	Himanshu Madhani <[email protected]>
+Description:
+		[RO] A device may need to internally split an atomic write I/O
+		which straddles a given logical block address boundary. This
+		parameter specifies the size in bytes of the atomic boundary if
+		one is reported by the device. This value must be a
+		power-of-two and at least the size as in
+		atomic_write_unit_max_bytes.
+		Any attempt to merge atomic write I/Os must not result in a
+		merged I/O which crosses this boundary (if any).
+
 
 What:		/sys/block/<disk>/diskseq
 Date:		February 2021

Documentation/ABI/stable/sysfs-bus-nvmem

@@ -1,6 +1,23 @@
+What:		/sys/bus/nvmem/devices/.../force_ro
+Date:		June 2024
+KernelVersion:	6.11
+Contact:	Marek Vasut <[email protected]>
+Description:
+		This read/write attribute allows users to set read-write
+		devices as read-only and back to read-write from userspace.
+		This can be used to unlock and relock write-protection of
+		devices which are generally locked, except during sporadic
+		programming operation.
+		Read returns '0' or '1' for read-write or read-only modes
+		respectively.
+		Write parses one of 'YyTt1NnFf0', or [oO][NnFf] for "on"
+		and "off", i.e. what kstrbool() supports.
+		Note: This file is only present if CONFIG_NVMEM_SYSFS
+		is enabled.
+
 What:		/sys/bus/nvmem/devices/.../nvmem
 Date:		July 2015
-KernelVersion:  4.2
+KernelVersion:	4.2
 Contact:	Srinivas Kandagatla <[email protected]>
 Description:
 		This file allows user to read/write the raw NVMEM contents.
@@ -20,3 +37,14 @@ Description:
 		  ...
 		  *
 		  0001000
+
+What:		/sys/bus/nvmem/devices/.../type
+Date:		November 2018
+KernelVersion:	5.0
+Contact:	Alexandre Belloni <[email protected]>
+Description:
+		This read-only attribute allows user to read the NVMEM
+		device type. Supported types are "Unknown", "EEPROM",
+		"OTP", "Battery backed", "FRAM".
+		Note: This file is only present if CONFIG_NVMEM_SYSFS
+		is enabled.

Documentation/ABI/stable/sysfs-class-backlight

@@ -3,10 +3,11 @@ Date:		April 2005
 KernelVersion:	2.6.12
 Contact:	Richard Purdie <[email protected]>
 Description:
-		Control BACKLIGHT power, values are FB_BLANK_* from fb.h
+		Control BACKLIGHT power, values are compatible with
+		FB_BLANK_* from fb.h
 
-		 - FB_BLANK_UNBLANK (0)   : power on.
-		 - FB_BLANK_POWERDOWN (4) : power off
+		 - 0 (FB_BLANK_UNBLANK)   : power on.
+		 - 4 (FB_BLANK_POWERDOWN) : power off
 Users:		HAL
 
 What:		/sys/class/backlight/<backlight>/brightness

Documentation/ABI/stable/sysfs-driver-misc-cp500

@@ -0,0 +1,25 @@
+What:		/sys/devices/pciXXXX:XX/0000:XX:XX.X/0000:XX:XX.X/version
+Date:		June 2024
+KernelVersion:	6.11
+Contact:	Gerhard Engleder <[email protected]>
+Description:	Version of the FPGA configuration bitstream as printable string.
+		This file is read only.
+Users:		KEBA
+
+What:		/sys/devices/pciXXXX:XX/0000:XX:XX.X/0000:XX:XX.X/keep_cfg
+Date:		June 2024
+KernelVersion:	6.11
+Contact:	Gerhard Engleder <[email protected]>
+Description:	Flag which signals if FPGA shall keep or reload configuration
+		bitstream on reset. Normal FPGA behavior and default is to keep
+		configuration bitstream and to only reset the configured logic.
+
+		Reloading configuration on reset enables an update of the
+		configuration bitstream with a simple reboot. Otherwise it is
+		necessary to power cycle the device to reload the new
+		configuration bitstream.
+
+		This file is read/write. The values are as follows:
+		1 = keep configuration bitstream on reset, default
+		0 = reload configuration bitstream on reset
+Users:		KEBA

Documentation/ABI/testing/configfs-tsm

@@ -31,6 +31,18 @@ Description:
 		Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
 		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
 
+What:		/sys/kernel/config/tsm/report/$name/manifestblob
+Date:		January, 2024
+KernelVersion:	v6.10
+Contact:	[email protected]
+Description:
+		(RO) Optional supplemental data that a TSM may emit, visibility
+		of this attribute depends on TSM, and may be empty if no
+		manifest data is available.
+
+		See 'service_provider' for information on the format of the
+		manifest blob.
+
 What:		/sys/kernel/config/tsm/report/$name/provider
 Date:		September, 2023
 KernelVersion:	v6.7
@@ -80,3 +92,54 @@ Contact:	[email protected]
 Description:
 		(RO) Indicates the minimum permissible value that can be written
 		to @privlevel.
+
+What:		/sys/kernel/config/tsm/report/$name/service_provider
+Date:		January, 2024
+KernelVersion:	v6.10
+Contact:	[email protected]
+Description:
+		(WO) Attribute is visible if a TSM implementation provider
+		supports the concept of attestation reports from a service
+		provider for TVMs, like SEV-SNP running under an SVSM.
+		Specifying the service provider via this attribute will create
+		an attestation report as specified by the service provider.
+		The only currently supported service provider is "svsm".
+
+		For the "svsm" service provider, see the Secure VM Service Module
+		for SEV-SNP Guests v1.00 Section 7. For the doc, search for
+		"site:amd.com "Secure VM Service Module for SEV-SNP
+		Guests", docID: 58019"
+
+What:		/sys/kernel/config/tsm/report/$name/service_guid
+Date:		January, 2024
+KernelVersion:	v6.10
+Contact:	[email protected]
+Description:
+		(WO) Attribute is visible if a TSM implementation provider
+		supports the concept of attestation reports from a service
+		provider for TVMs, like SEV-SNP running under an SVSM.
+		Specifying an empty/null GUID (00000000-0000-0000-0000-000000)
+		requests all active services within the service provider be
+		part of the attestation report. Specifying a GUID request
+		an attestation report of just the specified service using the
+		manifest form specified by the service_manifest_version
+		attribute.
+
+		See 'service_provider' for information on the format of the
+		service guid.
+
+What:		/sys/kernel/config/tsm/report/$name/service_manifest_version
+Date:		January, 2024
+KernelVersion:	v6.10
+Contact:	[email protected]
+Description:
+		(WO) Attribute is visible if a TSM implementation provider
+		supports the concept of attestation reports from a service
+		provider for TVMs, like SEV-SNP running under an SVSM.
+		Indicates the service manifest version requested for the
+		attestation report (default 0). If this field is not set by
+		the user, the default manifest version of the service (the
+		service's initial/first manifest version) is returned.
+
+		See 'service_provider' for information on the format of the
+		service manifest version.