linux-stable.git/drivers/char, branch linux-6.16.y Linux kernel stable tree ipmi: Fix strcpy source and destination the same 2025-08-20T16:41:31+00:00 Corey Minyard corey@minyard.net 2025-06-14T00:06:26+00:00 56f1caaeb6bccf84c70ecceed96d436b040231e0 [ Upstream commit 8ffcb7560b4a15faf821df95e3ab532b2b020f8c ] The source and destination of some strcpy operations was the same. Split out the part of the operations that needed to be done for those particular calls so the unnecessary copy wasn't done. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506140756.EFXXvIP4-lkp@intel.com/ Signed-off-by: Corey Minyard <corey@minyard.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8ffcb7560b4a15faf821df95e3ab532b2b020f8c ]

The source and destination of some strcpy operations was the same.
Split out the part of the operations that needed to be done for those
particular calls so the unnecessary copy wasn't done.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506140756.EFXXvIP4-lkp@intel.com/
Signed-off-by: Corey Minyard <corey@minyard.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ipmi: Use dev_warn_ratelimited() for incorrect message warnings 2025-08-20T16:41:30+00:00 Breno Leitao leitao@debian.org 2025-07-10T12:57:26+00:00 6059554eda29f6332aaa332719689e4b666f3b21 [ Upstream commit ec50ec378e3fd83bde9b3d622ceac3509a60b6b5 ] During BMC firmware upgrades on live systems, the ipmi_msghandler generates excessive "BMC returned incorrect response" warnings while the BMC is temporarily offline. This can flood system logs in large deployments. Replace dev_warn() with dev_warn_ratelimited() to throttle these warnings and prevent log spam during BMC maintenance operations. Signed-off-by: Breno Leitao <leitao@debian.org> Message-ID: <20250710-ipmi_ratelimit-v1-1-6d417015ebe9@debian.org> Signed-off-by: Corey Minyard <corey@minyard.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ec50ec378e3fd83bde9b3d622ceac3509a60b6b5 ]

During BMC firmware upgrades on live systems, the ipmi_msghandler
generates excessive "BMC returned incorrect response" warnings
while the BMC is temporarily offline. This can flood system logs
in large deployments.

Replace dev_warn() with dev_warn_ratelimited() to throttle these
warnings and prevent log spam during BMC maintenance operations.

Signed-off-by: Breno Leitao <leitao@debian.org>
Message-ID: <20250710-ipmi_ratelimit-v1-1-6d417015ebe9@debian.org>
Signed-off-by: Corey Minyard <corey@minyard.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
char: misc: Fix improper and inaccurate error code returned by misc_init() 2025-08-20T16:41:01+00:00 Zijun Hu zijun.hu@oss.qualcomm.com 2025-06-20T14:35:20+00:00 aba0d3f8845c5b101469fbca87032c909ce42955 [ Upstream commit 0ef1fe4bc38673db72e39b700b29c50dfcc5a415 ] misc_init() returns -EIO for __register_chrdev() invocation failure, but: - -EIO is for I/O error normally, but __register_chrdev() does not do I/O. - -EIO can not cover various error codes returned by __register_chrdev(). Fix by returning error code of __register_chrdev(). Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250620-fix_mischar-v1-3-6c2716bbf1fa@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 0ef1fe4bc38673db72e39b700b29c50dfcc5a415 ]

misc_init() returns -EIO for __register_chrdev() invocation failure, but:

- -EIO is for I/O error normally, but __register_chrdev() does not do I/O.
- -EIO can not cover various error codes returned by __register_chrdev().

Fix by returning error code of __register_chrdev().

Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250620-fix_mischar-v1-3-6c2716bbf1fa@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in 2025-08-20T16:40:53+00:00 Yeoreum Yun yeoreum.yun@arm.com 2025-07-19T10:27:46+00:00 ff49f24a32c89828a1b7241862ff5007ac542f37 [ Upstream commit 746d9e9f62a6e8ba0eba2b83fc61cfe7fa8797ce ] To generate the boot_aggregate log in the IMA subsystem using TPM PCR values, the TPM driver must be built as built-in and must be probed before the IMA subsystem is initialized. However, when the TPM device operates over the FF-A protocol using the CRB interface, probing fails and returns -EPROBE_DEFER if the tpm_crb_ffa device — an FF-A device that provides the communication interface to the tpm_crb driver — has not yet been probed. This issue occurs because both crb_acpi_driver_init() and tpm_crb_ffa_driver_init() are registered with device_initcall. As a result, crb_acpi_driver_init() may be invoked before tpm_crb_ffa_driver_init(), which is responsible for probing the tpm_crb_ffa device. When this happens, IMA fails to detect the TPM device and logs the following message: | ima: No TPM chip found, activating TPM-bypass! Consequently, it cannot generate the boot_aggregate log with the PCR values provided by the TPM. To resolve this issue, the tpm_crb_ffa_init() function explicitly attempts to probe the tpm_crb_ffa by register tpm_crb_ffa driver so that when tpm_crb_ffa device is created before tpm_crb_ffa_init(), probe the tpm_crb_ffa device in tpm_crb_ffa_init() to finish probe the TPM device completely. This ensures that the TPM device using CRB over FF-A can be successfully probed, even if crb_acpi_driver_init() is called first. [ jarkko: reformatted some of the paragraphs because they were going past the 75 character boundary. ] Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 746d9e9f62a6e8ba0eba2b83fc61cfe7fa8797ce ]

To generate the boot_aggregate log in the IMA subsystem using TPM PCR
values, the TPM driver must be built as built-in and must be probed
before the IMA subsystem is initialized.

However, when the TPM device operates over the FF-A protocol using the
CRB interface, probing fails and returns -EPROBE_DEFER if the
tpm_crb_ffa device — an FF-A device that provides the communication
interface to the tpm_crb driver — has not yet been probed.

This issue occurs because both crb_acpi_driver_init() and
tpm_crb_ffa_driver_init() are registered with device_initcall.  As a
result, crb_acpi_driver_init() may be invoked before
tpm_crb_ffa_driver_init(), which is responsible for probing the
tpm_crb_ffa device.

When this happens, IMA fails to detect the TPM device and logs the
following message:

  | ima: No TPM chip found, activating TPM-bypass!

Consequently, it cannot generate the boot_aggregate log with the PCR
values provided by the TPM.

To resolve this issue, the tpm_crb_ffa_init() function explicitly
attempts to probe the tpm_crb_ffa by register tpm_crb_ffa driver so that
when tpm_crb_ffa device is created before tpm_crb_ffa_init(), probe the
tpm_crb_ffa device in tpm_crb_ffa_init() to finish probe the TPM device
completely.

This ensures that the TPM device using CRB over FF-A can be successfully
probed, even if crb_acpi_driver_init() is called first.

[ jarkko: reformatted some of the paragraphs because they were going past
  the 75 character boundary. ]

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tpm: Check for completion after timeout 2025-08-20T16:40:53+00:00 Jarkko Sakkinen jarkko@kernel.org 2025-07-22T23:21:24+00:00 f141481a33849c73bd0e6ff790c0a5c1a1dc339a [ Upstream commit d4640c394f23b202a89512346cf28f6622a49031 ] The current implementation of timeout detection works in the following way: 1. Read completion status. If completed, return the data 2. Sleep for some time (usleep_range) 3. Check for timeout using current jiffies value. Return an error if timed out 4. Goto 1 usleep_range doesn't guarantee it's always going to wake up strictly in (min, max) range, so such a situation is possible: 1. Driver reads completion status. No completion yet 2. Process sleeps indefinitely. In the meantime, TPM responds 3. We check for timeout without checking for the completion again. Result is lost. Such a situation also happens for the guest VMs: if vCPU goes to sleep and doesn't get scheduled for some time, the guest TPM driver will timeout instantly after waking up without checking for the completion (which may already be in place). Perform the completion check once again after exiting the busy loop in order to give the device the last chance to send us some data. Since now we check for completion in two places, extract this check into a separate function. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Reviewed-by: Jonathan McDowell <noodles@meta.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d4640c394f23b202a89512346cf28f6622a49031 ]

The current implementation of timeout detection works in the following
way:

1. Read completion status. If completed, return the data
2. Sleep for some time (usleep_range)
3. Check for timeout using current jiffies value. Return an error if
   timed out
4. Goto 1

usleep_range doesn't guarantee it's always going to wake up strictly in
(min, max) range, so such a situation is possible:

1. Driver reads completion status. No completion yet
2. Process sleeps indefinitely. In the meantime, TPM responds
3. We check for timeout without checking for the completion again.
   Result is lost.

Such a situation also happens for the guest VMs: if vCPU goes to sleep
and doesn't get scheduled for some time, the guest TPM driver will
timeout instantly after waking up without checking for the completion
(which may already be in place).

Perform the completion check once again after exiting the busy loop in
order to give the device the last chance to send us some data.

Since now we check for completion in two places, extract this check into
a separate function.

Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
Reviewed-by: Jonathan McDowell <noodles@meta.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
hwrng: mtk - handle devm_pm_runtime_enable errors 2025-08-15T14:39:09+00:00 Ovidiu Panait ovidiu.panait.oss@gmail.com 2025-06-29T17:31:41+00:00 13f75a6bc9d2c191505f68f026729eae40d94bfb [ Upstream commit 522a242a18adc5c63a24836715dbeec4dc3faee1 ] Although unlikely, devm_pm_runtime_enable() call might fail, so handle the return value. Fixes: 78cb66caa6ab ("hwrng: mtk - Use devm_pm_runtime_enable") Signed-off-by: Ovidiu Panait <ovidiu.panait.oss@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 522a242a18adc5c63a24836715dbeec4dc3faee1 ]

Although unlikely, devm_pm_runtime_enable() call might fail, so handle
the return value.

Fixes: 78cb66caa6ab ("hwrng: mtk - Use devm_pm_runtime_enable")
Signed-off-by: Ovidiu Panait <ovidiu.panait.oss@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
agp/amd64: Check AGP Capability before binding to unsupported devices 2025-07-09T05:23:09+00:00 Lukas Wunner lukas@wunner.de 2025-07-02T05:02:15+00:00 d88dfb756d557e40e88406e8c962c0684bc9eb87 Since commit 172efbb40333 ("AGP: Try unsupported AGP chipsets on x86-64 by default"), the AGP driver for AMD Opteron/Athlon64 CPUs has attempted to bind to any PCI device possessing an AGP Capability. Commit 6fd024893911 ("amd64-agp: Probe unknown AGP devices the right way") subsequently reworked the driver to perform a bind attempt to any PCI device (regardless of AGP Capability) and reject a device in the driver's ->probe() hook if it lacks the AGP Capability. On modern CPUs exposing an AMD IOMMU, this subtle change results in an annoying message with KERN_CRIT severity: pci 0000:00:00.2: Resources present before probing The message is emitted by the driver core prior to invoking a driver's ->probe() hook. The check for an AGP Capability in the ->probe() hook happens too late to prevent the message. The message has appeared only recently with commit 3be5fa236649 (Revert "iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices"). Prior to the commit, no driver could bind to AMD IOMMUs. The reason for the message is that an MSI is requested early on for the AMD IOMMU, which results in a call from msi_sysfs_create_group() to devm_device_add_group(). A devres resource is thus attached to the driver-less AMD IOMMU, which is normally not allowed, but presumably cannot be avoided because requesting the MSI from a regular PCI driver might be too late. Avoid the message by once again checking for an AGP Capability *before* binding to an unsupported device. Achieve that by way of the PCI core's dynid functionality. pci_add_dynid() can fail only with -ENOMEM (on allocation failure) or -EINVAL (on bus_to_subsys() failure). It doesn't seem worth the extra code to propagate those error codes out of the for_each_pci_dev() loop, so simply error out with -ENODEV if there was no successful bind attempt. In the -ENOMEM case, a splat is emitted anyway, and the -EINVAL case can never happen because it requires failure of bus_register(&pci_bus_type), in which case there's no driver probing of PCI devices. Hans has voiced a preference to no longer probe unsupported devices by default (i.e. set agp_try_unsupported = 0). In fact, the help text for CONFIG_AGP_AMD64 pretends this to be the default. Alternatively, he proposes probing only devices with PCI_CLASS_BRIDGE_HOST. However these approaches risk regressing users who depend on the existing behavior. Fixes: 3be5fa236649 (Revert "iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices") Reported-by: Fedor Pchelkin <pchelkin@ispras.ru> Closes: https://lore.kernel.org/r/wpoivftgshz5b5aovxbkxl6ivvquinukqfvb5z6yi4mv7d25ew@edtzr2p74ckg/ Reported-by: Hans de Goede <hansg@kernel.org> Closes: https://lore.kernel.org/r/20250625112411.4123-1-hansg@kernel.org/ Tested-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/b29e7fbfc6d146f947603d0ebaef44cbd2f0d754.1751468802.git.lukas@wunner.de 
Since commit 172efbb40333 ("AGP: Try unsupported AGP chipsets on x86-64
by default"), the AGP driver for AMD Opteron/Athlon64 CPUs has attempted
to bind to any PCI device possessing an AGP Capability.

Commit 6fd024893911 ("amd64-agp: Probe unknown AGP devices the right
way") subsequently reworked the driver to perform a bind attempt to
any PCI device (regardless of AGP Capability) and reject a device in
the driver's ->probe() hook if it lacks the AGP Capability.

On modern CPUs exposing an AMD IOMMU, this subtle change results in an
annoying message with KERN_CRIT severity:

  pci 0000:00:00.2: Resources present before probing

The message is emitted by the driver core prior to invoking a driver's
->probe() hook.  The check for an AGP Capability in the ->probe() hook
happens too late to prevent the message.

The message has appeared only recently with commit 3be5fa236649 (Revert
"iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices").
Prior to the commit, no driver could bind to AMD IOMMUs.

The reason for the message is that an MSI is requested early on for the
AMD IOMMU, which results in a call from msi_sysfs_create_group() to
devm_device_add_group().  A devres resource is thus attached to the
driver-less AMD IOMMU, which is normally not allowed, but presumably
cannot be avoided because requesting the MSI from a regular PCI driver
might be too late.

Avoid the message by once again checking for an AGP Capability *before*
binding to an unsupported device.  Achieve that by way of the PCI core's
dynid functionality.

pci_add_dynid() can fail only with -ENOMEM (on allocation failure) or
-EINVAL (on bus_to_subsys() failure).  It doesn't seem worth the extra
code to propagate those error codes out of the for_each_pci_dev() loop,
so simply error out with -ENODEV if there was no successful bind attempt.
In the -ENOMEM case, a splat is emitted anyway, and the -EINVAL case can
never happen because it requires failure of bus_register(&pci_bus_type),
in which case there's no driver probing of PCI devices.

Hans has voiced a preference to no longer probe unsupported devices by
default (i.e. set agp_try_unsupported = 0).  In fact, the help text for
CONFIG_AGP_AMD64 pretends this to be the default.  Alternatively, he
proposes probing only devices with PCI_CLASS_BRIDGE_HOST.  However these
approaches risk regressing users who depend on the existing behavior.

Fixes: 3be5fa236649 (Revert "iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices")
Reported-by: Fedor Pchelkin <pchelkin@ispras.ru>
Closes: https://lore.kernel.org/r/wpoivftgshz5b5aovxbkxl6ivvquinukqfvb5z6yi4mv7d25ew@edtzr2p74ckg/
Reported-by: Hans de Goede <hansg@kernel.org>
Closes: https://lore.kernel.org/r/20250625112411.4123-1-hansg@kernel.org/
Tested-by: Hans de Goede <hansg@kernel.org>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Link: https://lore.kernel.org/r/b29e7fbfc6d146f947603d0ebaef44cbd2f0d754.1751468802.git.lukas@wunner.de
treewide, timers: Rename from_timer() to timer_container_of() 2025-06-08T07:07:37+00:00 Ingo Molnar mingo@kernel.org 2025-05-09T05:51:14+00:00 41cb08555c4164996d67c78b3bf1c658075b75f1 Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com 
Move this API to the canonical timer_*() namespace.

[ tglx: Redone against pre rc1 ]

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com
Merge tag 'char-misc-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc 2025-06-06T18:50:47+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-06-06T18:50:47+00:00 c26f4fbd58375bd6ef74f95eb73d61762ad97c59 Pull char / misc / iio driver updates from Greg KH: "Here is the big char/misc/iio and other small driver subsystem pull request for 6.16-rc1. Overall, a lot of individual changes, but nothing major, just the normal constant forward progress of new device support and cleanups to existing subsystems. Highlights in here are: - Large IIO driver updates and additions and device tree changes - Android binder bugfixes and logfile fixes - mhi driver updates - comedi driver updates - counter driver updates and additions - coresight driver updates and additions - echo driver removal as there are no in-kernel users of it - nvmem driver updates - spmi driver updates - new amd-sbi driver "subsystem" and drivers added - rust miscdriver binding documentation fix - other small driver fixes and updates (uio, w1, acrn, hpet, xillybus, cardreader drivers, fastrpc and others) All of these have been in linux-next for quite a while with no reported problems" * tag 'char-misc-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (390 commits) binder: fix yet another UAF in binder_devices counter: microchip-tcb-capture: Add watch validation support dt-bindings: iio: adc: Add ROHM BD79100G iio: adc: add support for Nuvoton NCT7201 dt-bindings: iio: adc: add NCT7201 ADCs iio: chemical: Add driver for SEN0322 dt-bindings: trivial-devices: Document SEN0322 iio: adc: ad7768-1: reorganize driver headers iio: bmp280: zero-init buffer iio: ssp_sensors: optimalize -> optimize HID: sensor-hub: Fix typo and improve documentation iio: admv1013: replace redundant ternary operator with just len iio: chemical: mhz19b: Fix error code in probe() iio: adc: at91-sama5d2: use IIO_DECLARE_BUFFER_WITH_TS iio: accel: sca3300: use IIO_DECLARE_BUFFER_WITH_TS iio: adc: ad7380: use IIO_DECLARE_DMA_BUFFER_WITH_TS iio: adc: ad4695: rename AD4695_MAX_VIN_CHANNELS iio: adc: ad4695: use IIO_DECLARE_DMA_BUFFER_WITH_TS iio: introduce IIO_DECLARE_BUFFER_WITH_TS macros iio: make IIO_DMA_MINALIGN minimum of 8 bytes ... 
Pull char / misc / iio driver updates from Greg KH:
 "Here is the big char/misc/iio and other small driver subsystem pull
  request for 6.16-rc1.

  Overall, a lot of individual changes, but nothing major, just the
  normal constant forward progress of new device support and cleanups to
  existing subsystems. Highlights in here are:

   - Large IIO driver updates and additions and device tree changes

   - Android binder bugfixes and logfile fixes

   - mhi driver updates

   - comedi driver updates

   - counter driver updates and additions

   - coresight driver updates and additions

   - echo driver removal as there are no in-kernel users of it

   - nvmem driver updates

   - spmi driver updates

   - new amd-sbi driver "subsystem" and drivers added

   - rust miscdriver binding documentation fix

   - other small driver fixes and updates (uio, w1, acrn, hpet,
     xillybus, cardreader drivers, fastrpc and others)

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

* tag 'char-misc-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (390 commits)
  binder: fix yet another UAF in binder_devices
  counter: microchip-tcb-capture: Add watch validation support
  dt-bindings: iio: adc: Add ROHM BD79100G
  iio: adc: add support for Nuvoton NCT7201
  dt-bindings: iio: adc: add NCT7201 ADCs
  iio: chemical: Add driver for SEN0322
  dt-bindings: trivial-devices: Document SEN0322
  iio: adc: ad7768-1: reorganize driver headers
  iio: bmp280: zero-init buffer
  iio: ssp_sensors: optimalize -> optimize
  HID: sensor-hub: Fix typo and improve documentation
  iio: admv1013: replace redundant ternary operator with just len
  iio: chemical: mhz19b: Fix error code in probe()
  iio: adc: at91-sama5d2: use IIO_DECLARE_BUFFER_WITH_TS
  iio: accel: sca3300: use IIO_DECLARE_BUFFER_WITH_TS
  iio: adc: ad7380: use IIO_DECLARE_DMA_BUFFER_WITH_TS
  iio: adc: ad4695: rename AD4695_MAX_VIN_CHANNELS
  iio: adc: ad4695: use IIO_DECLARE_DMA_BUFFER_WITH_TS
  iio: introduce IIO_DECLARE_BUFFER_WITH_TS macros
  iio: make IIO_DMA_MINALIGN minimum of 8 bytes
  ...
Merge tag 'for-linus-6.16-1' of https://github.com/cminyard/linux-ipmi 2025-05-30T04:37:11+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-05-30T04:37:11+00:00 02897f5e56b22e78d376faff1533ad800991650e Pull IPMI updates from Corey Minyard: "Restructure the IPMI driver. This is a restructure of the IPMI driver, mostly to remove SRCU. The locking had issues, and they were not going to be straightforward to fix. Plus it used tons of memory and was generally a pain. Most of this moves handling of messages out of bh and interrupt context and runs it in thread context. Then getting rid of SRCU is easy. This also has a minor cleanup to remove a warning on newer GCCs and to fix some documentation" * tag 'for-linus-6.16-1' of https://github.com/cminyard/linux-ipmi: (26 commits) docs: ipmi: fix spelling and grammar mistakes ipmi:msghandler: Fix potential memory corruption in ipmi_create_user() ipmi:watchdog: Use the new interface for panic messages ipmi:msghandler: Export and fix panic messaging capability Documentation:ipmi: Remove comments about interrupt level ipmi:ssif: Fix a shutdown race ipmi:msghandler: Don't deliver messages to deleted users ipmi:si: Rework startup of IPMI devices ipmi:msghandler: Add a error return from unhandle LAN cmds ipmi:msghandler: Shut down lower layer first at unregister ipmi:msghandler: Remove proc_fs.h ipmi:msghandler: Don't check for shutdown when returning responses ipmi:msghandler: Don't acquire a user refcount for queued messages ipmi:msghandler: Fix locking around users and interfaces ipmi:msghandler: Remove some user level processing in panic mode ipmi: Add a note about the pretimeout callback ipmi:watchdog: Change lock to mutex ipmi:msghandler: Remove srcu for the ipmi_interfaces list ipmi:msghandler: Remove srcu from the ipmi user structure ipmi:msghandler: Use the system_wq, not system_bh_wq ... 
Pull IPMI updates from Corey Minyard:
 "Restructure the IPMI driver.

  This is a restructure of the IPMI driver, mostly to remove SRCU. The
  locking had issues, and they were not going to be straightforward to
  fix. Plus it used tons of memory and was generally a pain.

  Most of this moves handling of messages out of bh and interrupt
  context and runs it in thread context. Then getting rid of SRCU is
  easy.

  This also has a minor cleanup to remove a warning on newer GCCs and to
  fix some documentation"

* tag 'for-linus-6.16-1' of https://github.com/cminyard/linux-ipmi: (26 commits)
  docs: ipmi: fix spelling and grammar mistakes
  ipmi:msghandler: Fix potential memory corruption in ipmi_create_user()
  ipmi:watchdog: Use the new interface for panic messages
  ipmi:msghandler: Export and fix panic messaging capability
  Documentation:ipmi: Remove comments about interrupt level
  ipmi:ssif: Fix a shutdown race
  ipmi:msghandler: Don't deliver messages to deleted users
  ipmi:si: Rework startup of IPMI devices
  ipmi:msghandler: Add a error return from unhandle LAN cmds
  ipmi:msghandler: Shut down lower layer first at unregister
  ipmi:msghandler: Remove proc_fs.h
  ipmi:msghandler: Don't check for shutdown when returning responses
  ipmi:msghandler: Don't acquire a user refcount for queued messages
  ipmi:msghandler: Fix locking around users and interfaces
  ipmi:msghandler: Remove some user level processing in panic mode
  ipmi: Add a note about the pretimeout callback
  ipmi:watchdog: Change lock to mutex
  ipmi:msghandler: Remove srcu for the ipmi_interfaces list
  ipmi:msghandler: Remove srcu from the ipmi user structure
  ipmi:msghandler: Use the system_wq, not system_bh_wq
  ...