Merge/sound upstream 20260828

.mailmap

@@ -171,6 +171,7 @@ Boris Brezillon <bbrezillon@kernel.org> <b.brezillon@overkiz.com>
 Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>
 Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@free-electrons.com>
 Brendan Higgins <brendan.higgins@linux.dev> <brendanhiggins@google.com>
+Brendan Jackman <brendan.jackman@linux.dev> <jackmanb@google.com>
 Brian Avery <b.avery@hp.com>
 Brian Cain <bcain@kernel.org> <brian.cain@oss.qualcomm.com>
 Brian Cain <bcain@kernel.org> <bcain@quicinc.com>
@@ -233,6 +234,8 @@ Daniel Lezcano <daniel.lezcano@kernel.org> <daniel.lezcano@linexp.org>
 Daniel Lezcano <daniel.lezcano@kernel.org> <dlezcano@fr.ibm.com>
 Daniel Thompson <danielt@kernel.org> <daniel.thompson@linaro.org>
 Daniele Alessandrelli <daniele.alessandrelli@gmail.com> <daniele.alessandrelli@intel.com>
+Danila Tikhonov <danila@mainlining.org> <danila@jiaxyga.com>
+Danila Tikhonov <danila@mainlining.org> <JIaxyga@protonmail.com>
 Danilo Krummrich <dakr@kernel.org> <dakr@redhat.com>
 David Brownell <david-b@pacbell.net>
 David Collins <quic_collinsd@quicinc.com> <collinsd@codeaurora.org>

Documentation/admin-guide/cgroup-v2.rst

@@ -2239,9 +2239,12 @@ IO Latency
 ~~~~~~~~~~
 
 This is a cgroup v2 controller for IO workload protection.  You provide a group
-with a latency target, and if the average latency exceeds that target the
-controller will throttle any peers that have a lower latency target than the
-protected workload.
+with a latency target, and if the group misses its target the controller will
+throttle any peers that have a lower latency target than the protected
+workload.  How a miss is detected depends on the device: on rotational devices
+the average latency over the window must exceed the target, while on
+non-rotational devices a miss is counted once enough of the IOs in the window
+individually exceed the target.
 
 The limits are only applied at the peer level in the hierarchy.  This means that
 in the diagram below, only groups A, B, and C will influence each other, and
@@ -2258,10 +2261,12 @@ So the ideal way to configure this is to set io.latency in groups A, B, and C.
 Generally you do not want to set a value lower than the latency your device
 supports.  Experiment to find the value that works best for your workload.
 Start at higher than the expected latency for your device and, with
-blkcg_debug_stats enabled, watch the avg_lat value in io.stat for your
-workload group to get an idea of the latency you see during normal operation.
-Use the avg_lat value as a basis for your real setting, setting at 10-15%
-higher than the value in io.stat.
+blkcg_debug_stats enabled, observe io.stat for your workload group to get an
+idea of the latency you see during normal operation.  On rotational devices,
+use the avg_lat value as a basis for your real setting, setting it 10-15%
+higher.  On non-rotational devices io.stat reports no average latency; set
+the target based on your device and use the missed/total fields to verify it
+is being met.
 
 How IO Latency Throttling Works
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2303,19 +2308,36 @@ IO Latency Interface Files
 	the blkcg_debug_stats module parameter is enabled (it is disabled by
 	default).
 
+	The reported latency fields depend on the device.  Rotational devices
+	report avg_lat and win; non-rotational devices report missed and total
+	instead.  missed and total are live counters for the current window and
+	may change between reads.
+
 	  depth
 		This is the current queue depth for the group.
 
 	  avg_lat
-		This is an exponential moving average with a decay rate of 1/exp
-		bound by the sampling interval.  The decay rate interval can be
-		calculated by multiplying the win value in io.stat by the
-		corresponding number of samples based on the win value.
+		(Rotational devices only.)  This is an exponential moving
+		average with a decay rate of 1/exp bound by the sampling
+		interval.  The decay rate interval can be calculated by
+		multiplying the win value in io.stat by the corresponding number
+		of samples based on the win value.
 
 	  win
-		The sampling window size in milliseconds.  This is the minimum
-		duration of time between evaluation events.  Windows only elapse
-		with IO activity.  Idle periods extend the most recent window.
+		(Rotational devices only.)  The sampling window size in
+		milliseconds.  This is the minimum duration of time between
+		evaluation events.  Windows only elapse with IO activity.  Idle
+		periods extend the most recent window.
+
+	  missed
+		(Non-rotational devices only.)  The number of IOs in the
+		current window whose latency exceeded the target.  A group is
+		considered to be missing its target once missed reaches a
+		certain ratio of total.
+
+	  total
+		(Non-rotational devices only.)  The total number of IOs
+		accounted in the current window.
 
 IO Priority
 ~~~~~~~~~~~

Documentation/admin-guide/kernel-parameters.txt

@@ -8169,6 +8169,11 @@ Kernel parameters
 				q = USB_QUIRK_FORCE_ONE_CONFIG (Device
 					claims zero configurations,
 					forcing to 1);
+				r = USB_QUIRK_WINDOWS_CONFIG_REQ_SIZE (Device
+					fails during initialization when asked for
+					9-bytes configuration descriptor request.
+					Ask for 255-bytes request instead to mirror
+					Windows' behavior);
 			Example: quirks=0781:5580:bk,0a5c:5834:gij
 
 	usbhid.mousepoll=

Documentation/devicetree/bindings/sound/everest,es8316.yaml

@@ -30,6 +30,18 @@ description: |
 
 allOf:
   - $ref: dai-common.yaml#
+  - if:
+      properties:
+        compatible:
+          not:
+            contains:
+              const: everest,es8316
+    then:
+      properties:
+        avdd-supply: false
+        cpvdd-supply: false
+        dvdd-supply: false
+        pvdd-supply: false
 
 properties:
   compatible:
@@ -49,6 +61,18 @@ properties:
     items:
       - const: mclk
 
+  avdd-supply:
+    description: Regulator providing the analog supply, from 2.0 V to 3.6 V
+
+  cpvdd-supply:
+    description: Regulator providing the charge pump supply, from 1.6 V to 2.0 V
+
+  dvdd-supply:
+    description: Regulator providing the digital core supply, from 1.6 V to 3.6 V
+
+  pvdd-supply:
+    description: Regulator providing the digital I/O supply, from 1.6 V to 3.6 V
+
   interrupts:
     maxItems: 1
     description: Headphone detect interrupt
@@ -77,6 +101,10 @@ examples:
         reg = <0x11>;
         clocks = <&clks 10>;
         clock-names = "mclk";
+        avdd-supply = <&reg_3p3v>;
+        cpvdd-supply = <&reg_1p8v>;
+        dvdd-supply = <&reg_1p8v>;
+        pvdd-supply = <&reg_1p8v>;
         #sound-dai-cells = <0>;
       };
     };

Documentation/devicetree/bindings/sound/qcom,sm8250.yaml

@@ -26,6 +26,7 @@ properties:
               - qcom,eliza-sndcard
               - qcom,hawi-sndcard
               - qcom,kaanapali-sndcard
+              - qcom,maili-sndcard
               - qcom,sm8475-sndcard
               - qcom,sm8550-sndcard
               - qcom,sm8650-sndcard

Documentation/netlink/specs/ovpn.yaml

@@ -118,12 +118,16 @@ attribute-sets:
         doc: >-
           The number of seconds after which a keep alive message is sent to the
           peer
+        checks:
+          max: 86400
       -
         name: keepalive-timeout
         type: u32
         doc: >-
           The number of seconds from the last activity after which the peer is
           assumed dead
+        checks:
+          max: 86400
       -
         name: del-reason
         type: u32

Documentation/process/coding-assistants.rst

@@ -57,3 +57,40 @@ Basic development tools (git, gcc, make, editors) should not be listed.
 Example::
 
   Assisted-by: Claude:claude-3-opus coccinelle sparse
+
+Procedure for finding and fixing bugs
+=====================================
+
+When an AI assistant is used to find and fix bugs, it **MUST** follow at least
+these steps:
+
+1. Before starting, read the whole process documentation listed above, as well
+   as any other document mentioned in the request. Do not rely on isolated
+   parts found by keyword search.
+2. Note the commit ID and Locate a bug as instructed.
+3. For any bug found that is not trivial, verify that it looks real by
+   attempting to create a reproducer to demonstrate it. Lacking it may cause
+   the report to be ignored, as many unverified bug reports sent to maintainers
+   happen to be invalid. Stop here if it finally looks wrong.
+4. Write a fix for the bug. This part is not optional: except in a few very
+   rare cases, an AI assistant able to find a bug is able to fix it. Note that
+   fixes written in the same session as used to find the bug will generally
+   lead to better and more accurate fixes as the LLM's reasoning context
+   remains present.
+5. Build and verify that the fix works either using the reproducer or by
+   re-running a complete analysis; drop any fix that doesn't work and try
+   another one. The fix must not add build warnings and must pass the
+   checkpatch.pl checks (see submitting-patches.rst).
+6. Commit the working fix with a detailed message describing the problem, the
+   solution and a Fixes tag. Do not add a Signed-off-by tag, and add an
+   Assisted-by tag, as described above.
+7. Identify the maintainers and lists using scripts/get_maintainer.pl.
+   Documentation/process/security-bugs.rst shows how to do that.
+8. Indicate what could not be done. If the fix could not be built or tested, or
+   if no reproducer could be produced, say so explicitly: maintainers currently
+   waste too much time analyzing unverified reports and untested fixes.
+9. Read Documentation/process/threat-model.rst to determine whether the bug is
+   a vulnerability or a regular bug, and leave the result to the reporter for
+   review (the assistant must never send anything itself). Regular bugs are
+   submitted as described in Documentation/process/submitting-patches.rst,
+   vulnerabilities as described in Documentation/process/security-bugs.rst.

Documentation/process/security-bugs.rst

@@ -18,6 +18,10 @@ information is helpful.  The following information are absolutely necessary in
 **any** security bug report:
 
   * **affected kernel version range**: with no version indication, your report
+    will not be processed.  Note that a time-dependent version such as "latest
+    mainline" is not acceptable.  A stable identifier such as a commit ID or an
+    exact version is required.  Versions designating kernels not coming from
+    kernel.org (such as distro kernels) are meaningless to maintainers and
     will not be processed.  A significant part of reports are for bugs that
     have already been fixed, so it is extremely important that vulnerabilities
     are verified on recent versions (development tree or latest stable
@@ -225,6 +229,28 @@ there is no need to consume a maintainer's time with an unimportant report. If
 the issue is clearly trivial and publicly discoverable, you should report it
 directly to the public mailing lists.
 
+At the very least, when using an AI assistant to find and report bugs, make the
+assistant read this file and threat-model.rst before proceeding, and have it
+follow the procedure described in coding-assistants.rst: work on an up-to-date
+mainline tree and note the commit ID, verify the bug is real, write a fix,
+build it warning-free and checkpatch-clean, commit it with a Fixes tag, and
+identify the maintainers with get_maintainer.pl.
+
+On top of that procedure, the AI assistant **MUST**:
+
+1. Prepare a plain-text report explaining the problem. It must contain the
+   four items listed at the top of this file as absolutely necessary: the
+   affected version or commit ID noted while following the procedure above,
+   the description of the problem, the reproducer or its status, and the
+   triggering conditions.
+2. Start the report with a temporary section listing the recipients' addresses
+   (maintainers+list for the patch, maintainers only for the report and
+   reproducer), and with instructions reminding the reporter to check that
+   their email client is properly setup (see email-clients.rst), and leave it
+   to the reporter to remove that temporary section.
+
+A more detailed process is covered at https://github.com/masoncl/kres.git.
+
 Sending the report
 ------------------
 

Documentation/process/threat-model.rst

@@ -98,11 +98,11 @@ measures whose purpose is to avoid crossing a security boundary when certain
 classes of bugs are found, but a failure of these extra protections do not
 constitute a vulnerability alone.
 
-What does not constitute a security bug
----------------------------------------
+What classes of problems are not considered vulnerabilities
+-----------------------------------------------------------
 
 In the Linux kernel's threat model, the following classes of problems are
-**NOT** considered as Linux Kernel security bugs. However, when it is believed
+**NOT** considered Linux Kernel vulnerabilities. However, when it is believed
 that the kernel could do better, they should be reported, so that they can be
 reviewed and fixed where reasonably possible, but they will be handled as any
 regular bug:
@@ -111,8 +111,8 @@ regular bug:
 
   * outdated kernels and particularly end-of-life branches are out of the scope
     of the kernel's threat model: administrators are responsible for keeping
-    their system up to date. For a bug to qualify as a security bug, it must be
-    demonstrated that it affects actively maintained versions.
+    their system up to date. For a bug to qualify as a vulnerability, it must
+    be demonstrated that it affects actively maintained versions.
 
   * build-level: changes to the kernel configuration that are explicitly
     documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or
@@ -178,9 +178,6 @@ regular bug:
     involving tens of millions of threads, tens of thousands of CPUs,
     unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds).
 
-  * issues whose reproduction requires hardware modification or emulation,
-    including fake USB devices that pretend to be another one.
-
   * as well as issues that can be triggered at a cost that is orders of
     magnitude higher than the expected benefits (e.g. fully functional keyboard
     emulator only to retrieve 7 uninitialized bytes in a structure, or
@@ -208,19 +205,27 @@ regular bug:
     messages.
 
   * Leaks of kernel memory addresses/pointers do not constitute an immediately
-    exploitable vector and are not security bugs, though they must be reported
-    and fixed.
+    exploitable vector and are not vulnerabilities, though they must be
+    reported and fixed.
 
-* **Crafted file system images**:
+* **Non-conforming devices and media**:
 
-  * bugs triggered by mounting a corrupted or maliciously crafted file system
-    image are generally not security bugs, as the kernel assumes the underlying
-    storage media is under the administrator's control, unless the filesystem
-    driver is specifically documented as being hardened against untrusted media.
+  Drivers are implemented against a specification. When a device or a storage
+  medium violates the specification its driver was written against, the
+  resulting misbehaviour is a regular bug to be fixed, not a vulnerability,
+  unless the driver is specifically documented as being hardened against
+  hostile inputs. The following are therefore not considered vulnerabilities:
 
-  * issues that are resolved, mitigated, or detected by running a filesystem
+  * bugs triggered by mounting a corrupted or maliciously crafted file system
+    image: mounting a block device is a privileged operation (see above), and
+    the administrator is responsible for the media they mount. This includes
+    issues that are resolved, mitigated, or detected by running a filesystem
     consistency check (fsck) on the image prior to mounting.
 
+  * bugs whose reproduction requires hardware modification or emulation,
+    including fake USB devices that pretend to be another one, or devices
+    reporting values outside their documented ranges.
+
 * **Physical access**:
 
   Issues that require physical access to the machine, hardware modification, or
@@ -232,4 +237,4 @@ regular bug:
 * **Functional and performance regressions**:
 
   Any issue that can be mitigated by setting proper permissions and limits
-  doesn't qualify as a security bug.
+  doesn't qualify as a vulnerability.

Documentation/sound/alsa-configuration.rst

@@ -2316,6 +2316,9 @@ quirk_flags
     applies the ``mixer_playback_min_mute`` flag and clears the
     ``ignore_ctl_error`` flag for the device 1234:abcd, and applies the
     ``skip_sample_rate`` flag for all devices.
+    New quirk flags may replace old ones by reusing the latter's bits, so the
+    new usage is preferred. Despite that, depending on the order of probing is
+    fragile, so it'd better migrate to the new usage anyway.
 
         * bit 0: ``get_sample_rate``
           Skip reading sample rate for devices
@@ -2389,23 +2392,21 @@ quirk_flags
           from snd_usb_handle_sync_urb. Instead fall through and enqueue a
           packet_info containing only size-0 packets, so the OUT ring keeps
           moving (emits silence). Needed by Behringer Flow 8 (1397:050c).
-        * bit 30: ``mixer_get_cur_broken``
-          Some mixers are sticky, which means that setting their current volume
-          is a no-op, and reading the current volume returns a constant value.
-          The sticky check disables these mixers to prevent confusing userspace.
-          However, some devices do have a tunable volume despite the reported
-          current volume being constant. As the sticky check can't distinguish
-          between the two categories, setting this flag tells that the device
-          should fall into the second category when GET_CUR returns a constant
-          value, resulting in the sticky check being non-fatal and only
-          disabling GET_CUR instead of the whole mixer. The current volume will
-          then be provided by the internal cache that stores the last set
-          volume
+        * bit 30: ``mixer_get_cur_ok``
+          On some devices, whether their GET_CUR being sticky depends on whether
+          hotpluggable components are present. When the hotpluggable components
+          are missing on probe, their GET_CUR behavior is classified as broken.
+          Set the flag to prevent the heuristics from gating GET_CUR.
         * bit 31: ``playback_urb_fixup``
           Some devices show the stuttering at playback, and this quirk
           works around it by enforcing the fixed max URBs (12) instead of
           the dynamic calculation from the buffer size, and passing the
           `URB_ISO_ASAP` URB flag.
+        * bit 32: ``always_set_rate``
+          Issue SET_CUR for the sample rate even when the clock already reports
+          the requested rate.  A device advertising a single rate is otherwise
+          never sent the request at all, and some require it before streaming
+          will start.
 
 This module supports multiple devices, autoprobe and hotplugging.
 

Documentation/sound/hd-audio/notes.rst

@@ -42,7 +42,7 @@ If you are interested in the deep debugging of HD-audio, read the
 HD-audio specification at first.  The specification is found on
 Intel's web page, for example:
 
-* https://www.intel.com/content/www/us/en/standards/high-definition-audio-specification.html
+* https://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/high-definition-audio-specification.pdf
 
 
 HD-Audio Controller