Pull remoteproc updates from Bjorn Andersson:

 - Add Qualcomm QMI Thermal Mitigation Device support for PAS-managed
   remote processors, with cooling device bindings and configurations
   for Hamoa, Kodiak, Lemans, Talos, Monaco, and Shikra CDSP and modem
   subsystems as applicable.

 - Add per-power-domain proxy performance states for Hawi CDSP and
   update Hawi, Maili, and SDX75 PAS compatible bindings and the SDX75
   device tree. Correct the Qualcomm ADSP startup timeout.

 - Fetch auto-boot firmware only once and synchronize boot work with
   device removal. Bound ELF section header accesses, improve trace
   diagnostics, and update coredump configuration documentation.

 - Set 48-bit DMA masks for TI K3 DSP and R5 remote processors, correct
   mailbox message types, and enable compile testing for more TI
   drivers. Fix i.MX address range boundary checks and DSP runtime PM
   ordering, and simplify mailbox notification handling.

 - Harden Xilinx mailbox setup and teardown and avoid sending
   notifications when the transmit queue is full. Propagate STM32
   optional IRQ lookup errors and correct the MediaTek MT8188 SCP
   register binding.

* tag 'rproc-v7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (33 commits)
  remoteproc: qcom_q6v5_pas: Add QMI TMD cooling support for Shikra
  remoteproc: virtio: Remove stray white space
  remoteproc: virtio: Replace kmemdup with kmemdup_array
  remoteproc: virtio: Add vdev_to_rsc() helper
  remoteproc: core: Fetch the auto-boot firmware only once
  remoteproc: xlnx: fix typecast warnings
  remoteproc: qcom_q6v5_pas: enable QMI TMD cooling support
  remoteproc: qcom: pas: add support for TMD thermal cooling devices
  soc: qcom: Add QMI TMD support for remote thermal mitigation
  dt-bindings: remoteproc: qcom,pas: add #cooling-cells property
  remoteproc: qcom_q6v5_pas: add per-PD proxy performance states for Hawi CDSP
  dt-bindings: remoteproc: qcom,sm8550-pas: make qcom,hawi-cdsp-pas standalone
  arm64: dts: qcom: sdx75: Use SM8650 MPSS as fallback compatible
  dt-bindings: remoteproc: qcom,sm8550-pas: Make SDX75 MPSS fallback to SM8650
  dt-bindings: remoteproc: qcom,sm8550-pas: Add Hawi and Maili MPSS as SM8650 fallback
  dt-bindings: remoteproc: Fix MT8188 SCP regs
  remoteproc: Use %p for pointer formatting
  remoteproc: Add compile testing for additional TI drivers
  remoteproc: k3-dsp: Fix usage of omap_mbox_message and mbox_msg_t
  remoteproc: k3: Include what we need and only what we need
  ...

Add QMI TMD instance IDs and cooling device name arrays for CDSP
and MPSS subsystems on Shikra to enable thermal mitigation support.

Signed-off-by: Dipa Ramesh Mantre <dipa.mantre@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260911-shikra_qmi_tmd-v1-1-96c1cca82f30@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

Pull vhost,virtio updates from Michael Tsirkin:
 "This adds CPR support for vhost.

  Plus some fixes, notably for a host of races we had when callback fire
  around device reset"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  tools/virtio: add missing device-id/virtio.h wrapper header
  vhost/vsock: add VHOST_RESET_OWNER ioctl
  vhost: synchronize with RCU readers when freeing workers
  vhost/vsock: re-scan TX virtqueue on device start
  vhost/vsock: suppress EHOSTUNREACH fast-fail during CPR pause
  vhost/vsock: split out vhost_vsock_drop_backends helper
  virtio_pci: drop callback sync on reset
  virtio_pci_modern: move avq cleanup from reset to del_vqs
  virtio: synchronize callbacks after device reset
  virtio_vdpa: implement synchronize_cbs()
  platform/mellanox: mlxbf-tmfifo: implement synchronize_cbs()
  um: virtio_uml: implement synchronize_cbs()
  remoteproc: implement synchronize_cbs() for virtio devices
  virtio_ccw: always take irq_lock in the classic interrupt handler
  virtio_ccw: fix synchronize_cbs() after interrupt fallback

Remove a stray white space in function definition. No functional
changes.

Signed-off-by: Francesco Valla <francesco@valla.it>
Link: https://lore.kernel.org/r/20261010-remoteproc_rework-v1-3-cc30dc34d866@valla.it
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

Let kmemdup_array take care of multiplication and overflows.

While at it, add blank lines in the same function for readability.

Signed-off-by: Francesco Valla <francesco@valla.it>
Link: https://lore.kernel.org/r/20261010-remoteproc_rework-v1-2-cc30dc34d866@valla.it
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

Instead of repeating the table+offset math in every function that needs
to access the resource linked to a vdev, add a simple helper function
for that to simplify the code a bit.

No functional changes.

Signed-off-by: Francesco Valla <francesco@valla.it>
Link: https://lore.kernel.org/r/20261010-remoteproc_rework-v1-1-cc30dc34d866@valla.it
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

Auto-boot for an always-on remote processor registers an asynchronous
request_firmware_nowait() whose callback, rproc_auto_boot_callback(),
calls rproc_boot() first and only releases the fetched image at the
very end of the callback.  rproc_boot() does not take this image as an
argument: it fetches the very same image again with a synchronous
request_firmware(), so every auto-boot reads the firmware image twice
and allocates the buffer twice; on kernels with the sysfs fallback
enabled, the uevent round-trip is repeated as well.

The asynchronous request exists only so that rproc_add() does not
block on the filesystem read; the image it fetches is never used.
The core already defers rproc_boot() to a worker for detached
processors (attach_work).  Reuse that worker for offline processors
too and drop the asynchronous firmware request: rproc_boot() fetches
the image exactly once and dispatches between a firmware boot and
an attach based on the processor state.  The work is renamed to
boot_work to match its widened role.

commit 400e64df6b23 ("remoteproc: add framework for controlling remote
processors") noted back in 2011 that "we must wait until it completes
before we try to unregister the device".  rproc_del() now does exactly
that: it waits for the boot work with cancel_work_sync(), which also
closes the theoretical window in which a pending attach work could
outlive the rproc instance.

The changed fallback behaviour only matters for legacy
configurations.  udev dropped its userspace firmware loader back in
2014, as recorded in
Documentation/driver-api/firmware/fallback-mechanisms.rst, and the
kernel has documented since commit 02c399306826 ("firmware_loader:
enhance Kconfig documentation over FW_LOADER") that "Linux no longer
relies on or uses a fallback mechanism in userspace".  Auto-boot now
uses the same synchronous fallback semantics as every other explicit
boot source (sysfs, cdev).

Signed-off-by: Yonghao Zhang <hyz3367@gmail.com>
Link: https://lore.kernel.org/r/20261001081056.38293-1-hyz3367@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

Fix following sparse warnings by using __force attribute:

sparse warnings: (new ones prefixed by >>)
   drivers/remoteproc/xlnx_r5_remoteproc.c:571:20: sparse: sparse:
cast removes address space '__iomem' of expression
   drivers/remoteproc/xlnx_r5_remoteproc.c:749:17: sparse: sparse:
cast removes address space '__iomem' of expression
   drivers/remoteproc/xlnx_r5_remoteproc.c:773:24: sparse: sparse:
cast removes address space '__iomem' of expression
   drivers/remoteproc/xlnx_r5_remoteproc.c:797:25: sparse: sparse:
cast removes address space '__iomem' of expression

>> drivers/remoteproc/xlnx_r5_remoteproc.c:837:49: sparse: sparse:
incorrect type in initializer (different address spaces) @@     expected
void *rsc_offset @@     got void [noderef] __iomem * @@
   drivers/remoteproc/xlnx_r5_remoteproc.c:837:49: sparse:
expected void *rsc_offset
   drivers/remoteproc/xlnx_r5_remoteproc.c:837:49: sparse:     got
void [noderef] __iomem *

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608190009.uCbYi1Y5-lkp@intel.com/
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260828155846.2883035-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

Enable Thermal Mitigation Device (TMD) support for PAS-managed CDSP and
modem remote processors on platforms that expose the QMI TMD service.

This adds per-platform TMD configuration in qcom_q6v5_pas for:
- Hamoa (X1E80100) CDSP
- Kodiak CDSP and modem
- Lemans (SA8775P) CDSP
- Talos CDSP
- Monaco CDSP

For each remoteproc, the configured TMD QMI instance ID is used to bind to
the TMD service running on that subsystem (e.g. CDSP: 0x43, modem: 0x0).
The driver then uses the corresponding TMD endpoint names ("cdsp_sw",
"pa", "modem") for cooling-device registration.

QMI TMD identifies mitigation endpoints by name, while DT thermal bindings
reference cooling devices by id. This change provides the mapping
between DT cooling indices and QMI TMD names, allowing remoteproc nodes
with #cooling-cells to act as cooling devices in the thermal framework.

With this in place, thermal policies can request mitigation from CDSP and
modem subsystems via QMI under thermal pressure.

Reviewed-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260809-b4-qmi-tmd-v8-4-b15d47adc379@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

Register Thermal Mitigation Devices (TMDs) for PAS-managed remote
processors to enable thermal throttling through QMI.

This allows the thermal framework to request mitigation when remote
subsystems such as modem and CDSP contribute to thermal pressure.

Reviewed-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260809-b4-qmi-tmd-v8-3-b15d47adc379@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>