linux-stable.git/Documentation, branch v6.16.2 Linux kernel stable tree sphinx: kernel_abi: fix performance regression with O=<dir> 2025-08-20T16:41:22+00:00 Mauro Carvalho Chehab mchehab+huawei@kernel.org 2025-07-17T11:37:19+00:00 0276f42f2bf8852b9b7e47cb00119b19ceb93e52 [ Upstream commit 2b16b71a05a7f056221751b906c13f8809656b1f ] The logic there which adds a dependency note to Sphinx cache is not taking into account that the build dir may not be the source dir. This causes a performance regression: $ time make O=/tmp/foo SPHINXDIRS=admin-guide htmldocs [OUTDATED] Added: set() Changed: {'abi-obsolete', 'abi-removed', 'abi-stable-files', 'abi-obsolete-files', 'abi-stable', 'abi', 'abi-removed-files', 'abi-testing-files', 'abi-testing', 'gpio/index', 'gpio/obsolete'} Removed: set() All docs count: 385 Found docs count: 385 real 0m11,324s user 0m15,783s sys 0m1,164s To get the root cause of the problem (ABI files reported as changed), I used this changeset: # diff --git a/Documentation/conf.py b/Documentation/conf.py # index e8766e689c1b..ab486623bd8b 100644 # --- a/Documentation/conf.py # +++ b/Documentation/conf.py # @@ -571,3 +571,16 @@ def setup(app): # """Patterns need to be updated at init time on older Sphinx versions""" # # app.connect('config-inited', update_patterns) # + app.connect('env-get-outdated', on_outdated) # + # +def on_outdated(app, env, added, changed, removed): # + """Track cache outdated due to added/changed/removed files""" # + print("\n[OUTDATED]") # + print(f"Added: {added}") # + print(f"Changed: {changed}") # + print(f"Removed: {removed}") # + print(f"All docs count: {len(env.all_docs)}") # + print(f"Found docs count: {len(env.found_docs)}") # + # + # Just return what we have # + return added | changed | removed Reported-by: Akira Yokosawa <akiyks@gmail.com> Closes: https://lore.kernel.org/linux-doc/c174f7c5-ec21-4eae-b1c3-f643cca90d9d@gmail.com/ Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Tested-by: Akira Yokosawa <akiyks@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/e25673d87357457bc54ee863e97ff8f75956580d.1752752211.git.mchehab+huawei@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2b16b71a05a7f056221751b906c13f8809656b1f ]

The logic there which adds a dependency note to Sphinx cache
is not taking into account that the build dir may not be
the source dir. This causes a performance regression:

$ time make O=/tmp/foo SPHINXDIRS=admin-guide htmldocs

	[OUTDATED]
	Added: set()
	Changed: {'abi-obsolete', 'abi-removed', 'abi-stable-files', 'abi-obsolete-files', 'abi-stable', 'abi', 'abi-removed-files', 'abi-testing-files', 'abi-testing', 'gpio/index', 'gpio/obsolete'}
	Removed: set()
	All docs count: 385
	Found docs count: 385

	real    0m11,324s
	user    0m15,783s
	sys     0m1,164s

To get the root cause of the problem (ABI files reported as changed),
I used this changeset:

#	diff --git a/Documentation/conf.py b/Documentation/conf.py
#	index e8766e689c1b..ab486623bd8b 100644
#	--- a/Documentation/conf.py
#	+++ b/Documentation/conf.py
#	@@ -571,3 +571,16 @@ def setup(app):
#	     """Patterns need to be updated at init time on older Sphinx versions"""
#
#	     app.connect('config-inited', update_patterns)
#	+    app.connect('env-get-outdated', on_outdated)
#	+
#	+def on_outdated(app, env, added, changed, removed):
#	+    """Track cache outdated due to added/changed/removed files"""
#	+    print("\n[OUTDATED]")
#	+    print(f"Added: {added}")
#	+    print(f"Changed: {changed}")
#	+    print(f"Removed: {removed}")
#	+    print(f"All docs count: {len(env.all_docs)}")
#	+    print(f"Found docs count: {len(env.found_docs)}")
#	+
#	+    # Just return what we have
#	+    return added | changed | removed

Reported-by: Akira Yokosawa <akiyks@gmail.com>
Closes: https://lore.kernel.org/linux-doc/c174f7c5-ec21-4eae-b1c3-f643cca90d9d@gmail.com/
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Tested-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/e25673d87357457bc54ee863e97ff8f75956580d.1752752211.git.mchehab+huawei@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Documentation: ACPI: Fix parent device references 2025-08-20T16:40:48+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2025-07-10T17:00:23+00:00 eaab52370693fd8c7c13b5e3eaaf982de6ec122a commit e65cb011349e653ded541dddd6469c2ca813edcf upstream. The _CRS resources in many cases want to have ResourceSource field to be a type of ACPI String. This means that to compile properly we need to enclosure the name path into double quotes. This will in practice defer the interpretation to a run-time stage, However, this may be interpreted differently on different OSes and ACPI interpreter implementations. In particular ACPICA might not correctly recognize the leading '^' (caret) character and will not resolve the relative name path properly. On top of that, this piece may be used in SSDTs which are loaded after the DSDT and on itself may also not resolve relative name paths outside of their own scopes. With this all said, fix documentation to use fully-qualified name paths always to avoid any misinterpretations, which is proven to work. Fixes: 8eb5c87a92c0 ("i2c: add ACPI support for I2C mux ports") Reported-by: Yevhen Kondrashyn <e.kondrashyn@gmail.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250710170225.961303-1-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e65cb011349e653ded541dddd6469c2ca813edcf upstream.

The _CRS resources in many cases want to have ResourceSource field
to be a type of ACPI String. This means that to compile properly
we need to enclosure the name path into double quotes. This will
in practice defer the interpretation to a run-time stage, However,
this may be interpreted differently on different OSes and ACPI
interpreter implementations. In particular ACPICA might not correctly
recognize the leading '^' (caret) character and will not resolve
the relative name path properly. On top of that, this piece may be
used in SSDTs which are loaded after the DSDT and on itself may also
not resolve relative name paths outside of their own scopes.
With this all said, fix documentation to use fully-qualified name
paths always to avoid any misinterpretations, which is proven to
work.

Fixes: 8eb5c87a92c0 ("i2c: add ACPI support for I2C mux ports")
Reported-by: Yevhen Kondrashyn <e.kondrashyn@gmail.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250710170225.961303-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fscrypt: Don't use problematic non-inline crypto engines 2025-08-20T16:40:48+00:00 Eric Biggers ebiggers@kernel.org 2025-07-04T07:03:22+00:00 d2465c6f3c98309dac118e2a9dcefa9ab53bd0a8 commit b41c1d8d07906786c60893980d52688f31d114a6 upstream. Make fscrypt no longer use Crypto API drivers for non-inline crypto engines, even when the Crypto API prioritizes them over CPU-based code (which unfortunately it often does). These drivers tend to be really problematic, especially for fscrypt's workload. This commit has no effect on inline crypto engines, which are different and do work well. Specifically, exclude drivers that have CRYPTO_ALG_KERN_DRIVER_ONLY or CRYPTO_ALG_ALLOCATES_MEMORY set. (Later, CRYPTO_ALG_ASYNC should be excluded too. That's omitted for now to keep this commit backportable, since until recently some CPU-based code had CRYPTO_ALG_ASYNC set.) There are two major issues with these drivers: bugs and performance. First, these drivers tend to be buggy. They're fundamentally much more error-prone and harder to test than the CPU-based code. They often don't get tested before kernel releases, and even if they do, the crypto self-tests don't properly test these drivers. Released drivers have en/decrypted or hashed data incorrectly. These bugs cause issues for fscrypt users who often didn't even want to use these drivers, e.g.: - https://github.com/google/fscryptctl/issues/32 - https://github.com/google/fscryptctl/issues/9 - https://lore.kernel.org/r/PH0PR02MB731916ECDB6C613665863B6CFFAA2@PH0PR02MB7319.namprd02.prod.outlook.com These drivers have also similarly caused issues for dm-crypt users, including data corruption and deadlocks. Since Linux v5.10, dm-crypt has disabled most of them by excluding CRYPTO_ALG_ALLOCATES_MEMORY. Second, these drivers tend to be *much* slower than the CPU-based code. This may seem counterintuitive, but benchmarks clearly show it. There's a *lot* of overhead associated with going to a hardware driver, off the CPU, and back again. To prove this, I gathered as many systems with this type of crypto engine as I could, and I measured synchronous encryption of 4096-byte messages (which matches fscrypt's workload): Intel Emerald Rapids server: AES-256-XTS: xts-aes-vaes-avx512 16171 MB/s [CPU-based, Vector AES] qat_aes_xts 289 MB/s [Offload, Intel QuickAssist] Qualcomm SM8650 HDK: AES-256-XTS: xts-aes-ce 4301 MB/s [CPU-based, ARMv8 Crypto Extensions] xts-aes-qce 73 MB/s [Offload, Qualcomm Crypto Engine] i.MX 8M Nano LPDDR4 EVK: AES-256-XTS: xts-aes-ce 647 MB/s [CPU-based, ARMv8 Crypto Extensions] xts(ecb-aes-caam) 20 MB/s [Offload, CAAM] AES-128-CBC-ESSIV: essiv(cbc-aes-caam,sha256-lib) 23 MB/s [Offload, CAAM] STM32MP157F-DK2: AES-256-XTS: xts-aes-neonbs 13.2 MB/s [CPU-based, ARM NEON] xts(stm32-ecb-aes) 3.1 MB/s [Offload, STM32 crypto engine] AES-128-CBC-ESSIV: essiv(cbc-aes-neonbs,sha256-lib) 14.7 MB/s [CPU-based, ARM NEON] essiv(stm32-cbc-aes,sha256-lib) 3.2 MB/s [Offload, STM32 crypto engine] Adiantum: adiantum(xchacha12-arm,aes-arm,nhpoly1305-neon) 52.8 MB/s [CPU-based, ARM scalar + NEON] So, there was no case in which the crypto engine was even *close* to being faster. On the first three, which have AES instructions in the CPU, the CPU was 30 to 55 times faster (!). Even on STM32MP157F-DK2 which has a Cortex-A7 CPU that doesn't have AES instructions, AES was over 4 times faster on the CPU. And Adiantum encryption, which is what actually should be used on CPUs like that, was over 17 times faster. Other justifications that have been given for these non-inline crypto engines (almost always coming from the hardware vendors, not actual users) don't seem very plausible either: - The crypto engine throughput could be improved by processing multiple requests concurrently. Currently irrelevant to fscrypt, since it doesn't do that. This would also be complex, and unhelpful in many cases. 2 of the 4 engines I tested even had only one queue. - Some of the engines, e.g. STM32, support hardware keys. Also currently irrelevant to fscrypt, since it doesn't support these. Interestingly, the STM32 driver itself doesn't support this either. - Free up CPU for other tasks and/or reduce energy usage. Not very plausible considering the "short" message length, driver overhead, and scheduling overhead. There's just very little time for the CPU to do something else like run another task or enter low-power state, before the message finishes and it's time to process the next one. - Some of these engines resist power analysis and electromagnetic attacks, while the CPU-based crypto generally does not. In theory, this sounds great. In practice, if this benefit requires the use of an off-CPU offload that massively regresses performance and has a low-quality, buggy driver, the price for this hardening (which is not relevant to most fscrypt users, and tends to be incomplete) is just too high. Inline crypto engines are much more promising here, as are on-CPU solutions like RISC-V High Assurance Cryptography. Fixes: b30ab0e03407 ("ext4 crypto: add ext4 encryption facilities") Cc: stable@vger.kernel.org Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b41c1d8d07906786c60893980d52688f31d114a6 upstream.

Make fscrypt no longer use Crypto API drivers for non-inline crypto
engines, even when the Crypto API prioritizes them over CPU-based code
(which unfortunately it often does).  These drivers tend to be really
problematic, especially for fscrypt's workload.  This commit has no
effect on inline crypto engines, which are different and do work well.

Specifically, exclude drivers that have CRYPTO_ALG_KERN_DRIVER_ONLY or
CRYPTO_ALG_ALLOCATES_MEMORY set.  (Later, CRYPTO_ALG_ASYNC should be
excluded too.  That's omitted for now to keep this commit backportable,
since until recently some CPU-based code had CRYPTO_ALG_ASYNC set.)

There are two major issues with these drivers: bugs and performance.

First, these drivers tend to be buggy.  They're fundamentally much more
error-prone and harder to test than the CPU-based code.  They often
don't get tested before kernel releases, and even if they do, the crypto
self-tests don't properly test these drivers.  Released drivers have
en/decrypted or hashed data incorrectly.  These bugs cause issues for
fscrypt users who often didn't even want to use these drivers, e.g.:

- https://github.com/google/fscryptctl/issues/32
- https://github.com/google/fscryptctl/issues/9
- https://lore.kernel.org/r/PH0PR02MB731916ECDB6C613665863B6CFFAA2@PH0PR02MB7319.namprd02.prod.outlook.com

These drivers have also similarly caused issues for dm-crypt users,
including data corruption and deadlocks.  Since Linux v5.10, dm-crypt
has disabled most of them by excluding CRYPTO_ALG_ALLOCATES_MEMORY.

Second, these drivers tend to be *much* slower than the CPU-based code.
This may seem counterintuitive, but benchmarks clearly show it.  There's
a *lot* of overhead associated with going to a hardware driver, off the
CPU, and back again.  To prove this, I gathered as many systems with
this type of crypto engine as I could, and I measured synchronous
encryption of 4096-byte messages (which matches fscrypt's workload):

Intel Emerald Rapids server:
   AES-256-XTS:
      xts-aes-vaes-avx512   16171 MB/s  [CPU-based, Vector AES]
      qat_aes_xts             289 MB/s  [Offload, Intel QuickAssist]

Qualcomm SM8650 HDK:
   AES-256-XTS:
      xts-aes-ce             4301 MB/s  [CPU-based, ARMv8 Crypto Extensions]
      xts-aes-qce              73 MB/s  [Offload, Qualcomm Crypto Engine]

i.MX 8M Nano LPDDR4 EVK:
   AES-256-XTS:
      xts-aes-ce              647 MB/s   [CPU-based, ARMv8 Crypto Extensions]
      xts(ecb-aes-caam)        20 MB/s   [Offload, CAAM]
   AES-128-CBC-ESSIV:
      essiv(cbc-aes-caam,sha256-lib) 23 MB/s   [Offload, CAAM]

STM32MP157F-DK2:
   AES-256-XTS:
      xts-aes-neonbs         13.2 MB/s   [CPU-based, ARM NEON]
      xts(stm32-ecb-aes)     3.1 MB/s    [Offload, STM32 crypto engine]
   AES-128-CBC-ESSIV:
      essiv(cbc-aes-neonbs,sha256-lib)
                             14.7 MB/s   [CPU-based, ARM NEON]
      essiv(stm32-cbc-aes,sha256-lib)
                             3.2 MB/s    [Offload, STM32 crypto engine]
   Adiantum:
      adiantum(xchacha12-arm,aes-arm,nhpoly1305-neon)
                             52.8 MB/s   [CPU-based, ARM scalar + NEON]

So, there was no case in which the crypto engine was even *close* to
being faster.  On the first three, which have AES instructions in the
CPU, the CPU was 30 to 55 times faster (!).  Even on STM32MP157F-DK2
which has a Cortex-A7 CPU that doesn't have AES instructions, AES was
over 4 times faster on the CPU.  And Adiantum encryption, which is what
actually should be used on CPUs like that, was over 17 times faster.

Other justifications that have been given for these non-inline crypto
engines (almost always coming from the hardware vendors, not actual
users) don't seem very plausible either:

  - The crypto engine throughput could be improved by processing
    multiple requests concurrently.  Currently irrelevant to fscrypt,
    since it doesn't do that.  This would also be complex, and unhelpful
    in many cases.  2 of the 4 engines I tested even had only one queue.

  - Some of the engines, e.g. STM32, support hardware keys.  Also
    currently irrelevant to fscrypt, since it doesn't support these.
    Interestingly, the STM32 driver itself doesn't support this either.

  - Free up CPU for other tasks and/or reduce energy usage.  Not very
    plausible considering the "short" message length, driver overhead,
    and scheduling overhead.  There's just very little time for the CPU
    to do something else like run another task or enter low-power state,
    before the message finishes and it's time to process the next one.

  - Some of these engines resist power analysis and electromagnetic
    attacks, while the CPU-based crypto generally does not.  In theory,
    this sounds great.  In practice, if this benefit requires the use of
    an off-CPU offload that massively regresses performance and has a
    low-quality, buggy driver, the price for this hardening (which is
    not relevant to most fscrypt users, and tends to be incomplete) is
    just too high.  Inline crypto engines are much more promising here,
    as are on-CPU solutions like RISC-V High Assurance Cryptography.

Fixes: b30ab0e03407 ("ext4 crypto: add ext4 encryption facilities")
Cc: stable@vger.kernel.org
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
netlink: specs: ethtool: fix module EEPROM input/output arguments 2025-08-15T14:39:24+00:00 Jakub Kicinski kuba@kernel.org 2025-07-30T17:21:37+00:00 8f702c589f4027ec2264111c548cc5835378f671 [ Upstream commit 01051012887329ea78eaca19b1d2eac4c9f601b5 ] Module (SFP) eeprom GET has a lot of input params, they are all mistakenly listed as output in the spec. Looks like kernel doesn't output them at all. Correct what are the inputs and what the outputs. Reported-by: Duo Yi <duo@meta.com> Fixes: a353318ebf24 ("tools: ynl: populate most of the ethtool spec") Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250730172137.1322351-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 01051012887329ea78eaca19b1d2eac4c9f601b5 ]

Module (SFP) eeprom GET has a lot of input params, they are all
mistakenly listed as output in the spec. Looks like kernel doesn't
output them at all. Correct what are the inputs and what the outputs.

Reported-by: Duo Yi <duo@meta.com>
Fixes: a353318ebf24 ("tools: ynl: populate most of the ethtool spec")
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20250730172137.1322351-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
f2fs: doc: fix wrong quota mount option description 2025-08-15T14:39:19+00:00 Chao Yu chao@kernel.org 2025-07-02T06:49:25+00:00 7e9d25c91f2ddc9fef165547bd4f8bc807e2f97e [ Upstream commit 81b6ecca2f15922e8d653dc037df5871e754be6e ] We should use "{usr,grp,prj}jquota=" to disable journaled quota, rather than using off{usr,grp,prj}jquota. Fixes: 4b2414d04e99 ("f2fs: support journalled quota") Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 81b6ecca2f15922e8d653dc037df5871e754be6e ]

We should use "{usr,grp,prj}jquota=" to disable journaled quota,
rather than using off{usr,grp,prj}jquota.

Fixes: 4b2414d04e99 ("f2fs: support journalled quota")
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
cgroup: Add compatibility option for content of /proc/cgroups 2025-08-15T14:39:10+00:00 Michal Koutný mkoutny@suse.com 2025-07-18T09:18:54+00:00 1e53f83deb8ebdf48527797f5b5b33cda9627a98 [ Upstream commit 646faf36d7271c597497ca547a59912fcab49be9 ] /proc/cgroups lists only v1 controllers by default, however, this is only enforced since the commit af000ce85293b ("cgroup: Do not report unavailable v1 controllers in /proc/cgroups") and there is software in the wild that uses content of /proc/cgroups to decide on availability of v2 (sic) controllers. Add a boottime param that can bring back the previous behavior for setups where the check in the software cannot be changed and it causes e.g. unintended OOMs. Also, this patch takes out cgrp_v1_visible from cgroup1_subsys_absent() guard since it's only important to check which hierarchy (v1 vs v2) the subsys is attached to. This has no effect on the printed message but the code is cleaner since cgrp_v1_visible is really about mounted hierarchies, not the content of /proc/cgroups. Link: https://lore.kernel.org/r/b26b60b7d0d2a5ecfd2f3c45f95f32922ed24686.camel@decadent.org.uk Fixes: af000ce85293b ("cgroup: Do not report unavailable v1 controllers in /proc/cgroups") Fixes: a0ab1453226d8 ("cgroup: Print message when /proc/cgroups is read on v2-only system") Signed-off-by: Michal Koutný <mkoutny@suse.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 646faf36d7271c597497ca547a59912fcab49be9 ]

/proc/cgroups lists only v1 controllers by default, however, this is
only enforced since the commit af000ce85293b ("cgroup: Do not report
unavailable v1 controllers in /proc/cgroups") and there is software in
the wild that uses content of /proc/cgroups to decide on availability of
v2 (sic) controllers.

Add a boottime param that can bring back the previous behavior for
setups where the check in the software cannot be changed and it causes
e.g. unintended OOMs.

Also, this patch takes out cgrp_v1_visible from cgroup1_subsys_absent()
guard since it's only important to check which hierarchy (v1 vs v2) the
subsys is attached to. This has no effect on the printed message but
the code is cleaner since cgrp_v1_visible is really about mounted
hierarchies, not the content of /proc/cgroups.

Link: https://lore.kernel.org/r/b26b60b7d0d2a5ecfd2f3c45f95f32922ed24686.camel@decadent.org.uk
Fixes: af000ce85293b ("cgroup: Do not report unavailable v1 controllers in /proc/cgroups")
Fixes: a0ab1453226d8 ("cgroup: Print message when /proc/cgroups is read on v2-only system")
Signed-off-by: Michal Koutný <mkoutny@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux 2025-07-26T20:26:33+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-07-26T20:26:33+00:00 874885990b18073213ff1797774c401df29676af Pull clk fixes from Stephen Boyd: "A few Allwinner clk driver fixes: - Mark Allwinner A523 MBUS clock as critical to avoid system stalls - Fix names of CSI related clocks on Allwinner V3s. This includes changes to the driver, DT bindings and DT files. - Fix parents of TCON clock on Allwinner V3s" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: sunxi-ng: v3s: Fix TCON clock parents clk: sunxi-ng: v3s: Fix CSI1 MCLK clock name clk: sunxi-ng: v3s: Fix CSI SCLK clock name clk: sunxi-ng: a523: Mark MBUS clock as critical 
Pull clk fixes from Stephen Boyd:
 "A few Allwinner clk driver fixes:

   - Mark Allwinner A523 MBUS clock as critical to avoid
     system stalls

   - Fix names of CSI related clocks on Allwinner V3s. This
     includes changes to the driver, DT bindings and DT files.

   - Fix parents of TCON clock on Allwinner V3s"

* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
  clk: sunxi-ng: v3s: Fix TCON clock parents
  clk: sunxi-ng: v3s: Fix CSI1 MCLK clock name
  clk: sunxi-ng: v3s: Fix CSI SCLK clock name
  clk: sunxi-ng: a523: Mark MBUS clock as critical
Merge tag 'sunxi-clk-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into clk-fixes 2025-07-21T17:17:51+00:00 Stephen Boyd sboyd@kernel.org 2025-07-21T17:17:51+00:00 e4b2a0c2b9be6d10b0e50a7485fe9f569a6f2436 Pull Allwinner clock fixes from Chen-Yu Tsai: - Mark A523 MBUS clock as critical - Fix names of CSI related clocks on V3s This includes changes to the driver, DT bindings and DT files. - Fix parents of TCON clock on V3s * tag 'sunxi-clk-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: clk: sunxi-ng: v3s: Fix TCON clock parents clk: sunxi-ng: v3s: Fix CSI1 MCLK clock name clk: sunxi-ng: v3s: Fix CSI SCLK clock name clk: sunxi-ng: a523: Mark MBUS clock as critical 
Pull Allwinner clock fixes from Chen-Yu Tsai:

 - Mark A523 MBUS clock as critical
 - Fix names of CSI related clocks on V3s
   This includes changes to the driver, DT bindings and DT files.
 - Fix parents of TCON clock on V3s

* tag 'sunxi-clk-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
  clk: sunxi-ng: v3s: Fix TCON clock parents
  clk: sunxi-ng: v3s: Fix CSI1 MCLK clock name
  clk: sunxi-ng: v3s: Fix CSI SCLK clock name
  clk: sunxi-ng: a523: Mark MBUS clock as critical
Merge tag 'char-misc-6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc 2025-07-20T16:03:41+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-07-20T16:03:41+00:00 ecf11d31bf5ccde62c91abe94d4edb867b64958f Pull char / misc / IIO fixes from Greg KH: "Here are some char/misc/iio and other driver fixes for 6.16-rc7. Included in here are: - IIO driver fixes for reported problems - Interconnect driver fixes for reported problems - nvmem driver fixes - bunch of comedi driver fixes for long-term bugs - Kconfig dependancy fixes for mux drivers - other small driver fixes for reported problems. All of these have been in linux-next for a while with no reported problems" * tag 'char-misc-6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (35 commits) nvmem: layouts: u-boot-env: remove crc32 endianness conversion misc: amd-sbi: Explicitly clear in/out arg "mb_in_out" misc: amd-sbi: Address copy_to/from_user() warning reported in smatch misc: amd-sbi: Address potential integer overflow issue reported in smatch comedi: comedi_test: Fix possible deletion of uninitialized timers comedi: Fix initialization of data for instructions that write to subdevice comedi: Fix use of uninitialized data in insn_rw_emulate_bits() comedi: das6402: Fix bit shift out of bounds comedi: aio_iiro_16: Fix bit shift out of bounds comedi: pcl812: Fix bit shift out of bounds comedi: das16m1: Fix bit shift out of bounds comedi: Fix some signed shift left operations comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large nvmem: imx-ocotp: fix MAC address byte length MAINTAINERS: add miscdevice Rust abstractions mux: mmio: Fix missing CONFIG_REGMAP_MMIO iio: dac: ad3530r: Fix incorrect masking for channels 4-7 in powerdown mode iio: adc: ad7380: fix adi,gain-milli property parsing iio: adc: ad7949: use spi_is_bpw_supported() iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush ... 
Pull char / misc / IIO fixes from Greg KH:
 "Here are some char/misc/iio and other driver fixes for 6.16-rc7.
  Included in here are:

   - IIO driver fixes for reported problems

   - Interconnect driver fixes for reported problems

   - nvmem driver fixes

   - bunch of comedi driver fixes for long-term bugs

   - Kconfig dependancy fixes for mux drivers

   - other small driver fixes for reported problems.

  All of these have been in linux-next for a while with no reported
  problems"

* tag 'char-misc-6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (35 commits)
  nvmem: layouts: u-boot-env: remove crc32 endianness conversion
  misc: amd-sbi: Explicitly clear in/out arg "mb_in_out"
  misc: amd-sbi: Address copy_to/from_user() warning reported in smatch
  misc: amd-sbi: Address potential integer overflow issue reported in smatch
  comedi: comedi_test: Fix possible deletion of uninitialized timers
  comedi: Fix initialization of data for instructions that write to subdevice
  comedi: Fix use of uninitialized data in insn_rw_emulate_bits()
  comedi: das6402: Fix bit shift out of bounds
  comedi: aio_iiro_16: Fix bit shift out of bounds
  comedi: pcl812: Fix bit shift out of bounds
  comedi: das16m1: Fix bit shift out of bounds
  comedi: Fix some signed shift left operations
  comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large
  nvmem: imx-ocotp: fix MAC address byte length
  MAINTAINERS: add miscdevice Rust abstractions
  mux: mmio: Fix missing CONFIG_REGMAP_MMIO
  iio: dac: ad3530r: Fix incorrect masking for channels 4-7 in powerdown mode
  iio: adc: ad7380: fix adi,gain-milli property parsing
  iio: adc: ad7949: use spi_is_bpw_supported()
  iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush
  ...
Merge tag 'hwmon-for-v6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging 2025-07-19T16:51:01+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-07-19T16:51:01+00:00 bd4a1567b6e3454eda1113ed3a537119208e9c7a Pull hwmon fixes from Guenter Roeck: - corsair-cpro: Validate the size of the received input buffer - ina238: Report energy in microjoules as expected by the ABI - pmbus/ucd9000: Fixed GPIO functionality * tag 'hwmon-for-v6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (pmbus/ucd9000) Fix error in ucd9000_gpio_set hwmon: (ina238) Report energy in microjoules hwmon: (corsair-cpro) Validate the size of the received input buffer 
Pull hwmon fixes from Guenter Roeck:

 - corsair-cpro: Validate the size of the received input buffer

 - ina238: Report energy in microjoules as expected by the ABI

 - pmbus/ucd9000: Fixed GPIO functionality

* tag 'hwmon-for-v6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (pmbus/ucd9000) Fix error in ucd9000_gpio_set
  hwmon: (ina238) Report energy in microjoules
  hwmon: (corsair-cpro) Validate the size of the received input buffer