commit dc3f4e75c54c19bad9a70419afae00ce6baf3ebf upstream.

qcom_scm_shm_bridge_enable() is used early in the SCM initialization
routine. It makes an SCM call and so expects the internal __scm pointer
in the SCM driver to be assigned. For this reason the tzmem memory pool
is allocated *after* this pointer is assigned. However, this can lead to
a crash if another consumer of the SCM API makes a call using the memory
pool between the assignment of the __scm pointer and the initialization
of the tzmem memory pool.

As qcom_scm_shm_bridge_enable() is a special case, not meant to be
called by ordinary users, pull it into the local SCM header. Make it
take struct device as argument. This is the device that will be used to
make the SCM call as opposed to the global __scm pointer. This will
allow us to move the tzmem initialization *before* the __scm assignment
in the core SCM driver.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250630-qcom-scm-race-v2-2-fa3851c98611@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23972da96e1eee7f10c8ef641d56202ab9af8ba7 upstream.

qcom_scm_shm_bridge_create() and qcom_scm_shm_bridge_delete() take
struct device as argument but don't use it. Remove it from these
functions' prototypes.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20250630-qcom-scm-race-v2-1-fa3851c98611@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Arm SCMI updates for v6.16

1. Quirk framework to handle buggy firmware

   With SCMI gaining broader adoption across arm64 platforms, it's
   increasingly important to address how we consistently manage out-of-spec
   SCMI firmware already deployed in the field. This change introduces a
   lightweight quirk framework built around static_keys, enabling developers to:
    - Define quirks and their match criteria, which can include:
       o A list of compatibles ({ comp, comp2, NULL })
       o Vendor ID / Sub-Vendor ID
       o Firmware implementation version ranges ([Min_Vers, Max_Vers])

   Matching proceeds from the most specific (longest match) to the least
   specific. NULL entries are treated as wildcards (i.e., match any value).
   This flexibility allows matching very specific combinations or just a
   general compatible string.

   The quirk code blocks/snippets implementing the workaround are placed near
   their intended usage and guarded by a static_key that's tied to the quirk.
   Once the SCMI core stack is initialized and retrieves platform info via the
   base protocol, any matching quirks will have their associated static_keys
   enabled.

2. Quirk for Qualcomm X1E platforms

   On some Qualcomm X1E platforms, such as the Lenovo ThinkPad T14s, the
   SCMI firmware fails to set the FastChannel support bit for PERF_LEVEL_GET,
   yet it crashes when the driver attempts to fall back to standard messaging
   which is clearly out-of-spec behavior.

   To work around this, the new SCMI quirk framework is used to
   unconditionally enable FC initialization for this firmware version.

   In the future, once the fixed firmware version is identified, an upper
   version bound can be added to the quirk match criteria. Alternatively,
   matching can be further restricted using a SoC-specific compatible string
   if always enabling FC proves problematic elsewhere.

3. Support for NXP i.MX LMM/CPU vendor protocol extensions

   The i.MX95 System Manager (SM) implements Logical Machine Management (LMM)
   and a CPU protocol to manage Logical Machines (LM) and CPUs (e.g., M7).

   These changes integrate the vendor-specific protocol extensions
   implementing the LMM and CPU protocols for the i.MX95, facilitating
   standardized communication between the operating system and the platform's
   firmware, which will be used by remoteproc drivers. The changes also
   include the necessary device tree bindings.

4. Miscellaneous cleanups/changes

   These mainly include polling support in SCMI raw mode. The cleanups
   centralize error logging for SCMI device creation into a single helper
   function, consolidate the device matching logic into a single function, and
   ensure that devices must have a name for registration—removing support for
   unnamed devices when matching drivers and devices for probing. Transport
   devices are now excluded from bus matching, and the correct assignment of
   the parent device for the arm-scmi platform device is ensured in the
   transport drivers.

* tag 'scmi-updates-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  firmware: arm_scmi: quirk: Force perf level get fastchannel
  firmware: arm_scmi: quirk: Fix CLOCK_DESCRIBE_RATES triplet
  firmware: arm_scmi: Add common framework to handle firmware quirks
  firmware: arm_scmi: Ensure that the message-id supports fastchannel
  MAINTAINERS: add entry for i.MX SCMI extensions
  firmware: imx: Add i.MX95 SCMI CPU driver
  firmware: imx: Add i.MX95 SCMI LMM driver
  firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
  firmware: arm_scmi: imx: Add i.MX95 LMM protocol
  dt-bindings: firmware: Add i.MX95 SCMI LMM and CPU protocol
  firmware: arm_scmi: imx: Add LMM and CPU documentation
  firmware: arm_scmi: Add polling support to raw mode
  firmware: arm_scmi: Exclude transport devices from bus matching
  firmware: arm_scmi: Assign correct parent to arm-scmi platform device
  firmware: arm_scmi: Refactor error logging from SCMI device creation to single helper
  firmware: arm_scmi: Refactor device matching logic to eliminate duplication
  firmware: arm_scmi: Ensure scmi_devices are always matched by name as well

Link: https://lore.kernel.org/r/20250507134713.49039-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Samsung SoC drivers for v6.16

Several improvements to Exynos ACPM (Alive Clock and Power Manager)
driver:
1. Handle communication timeous better.
2. Avoid sleeping, so users (PMIC) can still transfer during system
   shutdown.
3. Fix reading longer messages from them firmware.
4. Deferred probe improvements.
5. Model the user of ACPM - PMIC - a as child device and export
   devm_acpm_get_by_node() for such use case.

* tag 'samsung-drivers-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
  firmware: exynos-acpm: Correct kerneldoc and use typical np argument name
  firmware: exynos-acpm: introduce devm_acpm_get_by_node()
  firmware: exynos-acpm: populate devices from device tree data
  firmware: exynos-acpm: silence EPROBE_DEFER error on boot
  firmware: exynos-acpm: fix reading longer results
  dt-bindings: firmware: google,gs101-acpm-ipc: add PMIC child node
  firmware: exynos-acpm: allow use during system shutdown
  firmware: exynos-acpm: use ktime APIs for timeout detection

Link: https://lore.kernel.org/r/20250501103541.13795-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

To allow ACPM clients to simply be children of the ACPM node in DT,
they need to be able to get the ACPM handle based on that ACPM node
directly.

Add an API to allow them to do so, devm_acpm_get_by_node().

At the same time, the previous approach of acquiring the ACPM handle
via a DT phandle is now obsolete and we can remove
devm_acpm_get_by_phandle(), which was there to facilitate that. There
are no existing or anticipated upcoming users of that API, because all
clients should be children of the ACPM node going forward.

Note that no DTs have been merged that use the old approach, so doing
this API change in this driver now will not affect any existing DTs or
client drivers.

Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://lore.kernel.org/r/20250327-acpm-children-v1-2-0afe15ee2ff7@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

The i.MX95 System manager exports SCMI CPU protocol for linux to manage
cpu cores. The driver is to use the cpu Protocol interface to
start, stop a cpu cores (eg, M7).

Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Message-Id: <20250408-imx-lmm-cpu-v4-6-4c5f4a456e49@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

The i.MX95 System manager exports SCMI LMM protocol for linux to manage
Logical Machines. The driver is to use the LMM Protocol interface to
boot, shutdown a LM.

Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Message-Id: <20250408-imx-lmm-cpu-v4-5-4c5f4a456e49@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Call cs_dsp_mock_xm_header_get_fw_version() to get the firmware version
from the dummy XM header data in cs_dsp_bin_err_test_common_init().

Make the same change to cs_dsp_bin_test_common_init() and remove the
cs_dsp_mock_xm_header_get_fw_version_from_regmap() function.

The code in cs_dsp_test_bin.c was correctly calling
cs_dsp_mock_xm_header_get_fw_version_from_regmap() to fetch the fw version
from a dummy header it wrote to XM registers. However in
cs_dsp_test_bin_error.c the test doesn't stuff a dummy header into XM, it
populates it the normal way using a wmfw file. It should have called
cs_dsp_mock_xm_header_get_fw_version() to get the data from its blob
buffer, but was calling cs_dsp_mock_xm_header_get_fw_version_from_regmap().
As nothing had been written to the registers this returned the value of
uninitialized data.

The only other use of cs_dsp_mock_xm_header_get_fw_version_from_regmap()
was cs_dsp_test_bin.c, but it doesn't need to use it. It already has a
blob buffer containing the dummy XM header so it can use
cs_dsp_mock_xm_header_get_fw_version() to read from that.

Fixes: cd8c058499b6 ("firmware: cs_dsp: Add KUnit testing of bin error cases")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20250410132129.1312541-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Pull SoC driver updates from Arnd Bergmann:
 "These are the updates for SoC specific drivers and related subsystems:

   - Firmware driver updates for SCMI, FF-A and SMCCC firmware
     interfaces, adding support for additional firmware features
     including SoC identification and FF-A SRI callbacks as well as
     various bugfixes

   - Memory controller updates for Nvidia and Mediatek

   - Reset controller support for microchip sam9x7 and imx8qxp/imx8qm

   - New hardware support for multiple Mediatek, Renesas and Samsung
     Exynos chips

   - Minor updates on Zynq, Qualcomm, Amlogic, TI, Samsung, Nvidia and
     Apple chips

  There will be a follow up with a few more driver updates that are
  still causing build regressions at the moment"

* tag 'soc-drivers-6.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (97 commits)
  irqchip: Add support for Amlogic A4 and A5 SoCs
  dt-bindings: interrupt-controller: Add support for Amlogic A4 and A5 SoCs
  reset: imx: fix incorrect module device table
  dt-bindings: power: qcom,kpss-acc-v2: add qcom,msm8916-acc compatible
  bus: qcom-ssc-block-bus: Fix the error handling path of qcom_ssc_block_bus_probe()
  bus: qcom-ssc-block-bus: Remove some duplicated iounmap() calls
  soc: qcom: pd-mapper: Add support for SDM630/636
  reset: imx: Add SCU reset driver for i.MX8QXP and i.MX8QM
  dt-bindings: firmware: imx: add property reset-controller
  dt-bindings: reset: atmel,at91sam9260-reset: add sam9x7
  memory: mtk-smi: Add ostd setting for mt8192
  dt-bindings: soc: samsung: exynos-usi: Drop unnecessary status from example
  firmware: tegra: bpmp: Fix typo in bpmp-abi.h
  soc/tegra: pmc: Use str_enable_disable-like helpers
  soc: samsung: include linux/array_size.h where needed
  firmware: arm_scmi: use ioread64() instead of ioread64_hi_lo()
  soc: mediatek: mtk-socinfo: Add extra entry for MT8395AV/ZA Genio 1200
  soc: mediatek: mt8188-mmsys: Add support for DSC on VDO0
  soc: mediatek: mmsys: Migrate all tables to MMSYS_ROUTE() macro
  soc: mediatek: mt8365-mmsys: Fix routing table masks and values
  ...

The T-Head TH1520 SoC uses an E902 co-processor running Always-On (AON)
firmware to manage power, clock, and other system resources [1]. This
patch introduces a driver implementing the AON firmware protocol,
allowing the Linux kernel to communicate with the firmware via mailbox
channels.  Through an RPC-based interface, the kernel can initiate power
state transitions, update resource configurations, and perform other
AON-related tasks.

[1]
Link: https://openbeagle.org/beaglev-ahead/beaglev-ahead/-/blob/main/docs/TH1520%20System%20User%20Manual.pdf

Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Acked-by: Drew Fustini <drew@pdp7.com>
Link: https://lore.kernel.org/r/20250311171900.1549916-3-m.wilczynski@samsung.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>