From: Nikita Travkin nikita@trvn.ru
[ Upstream commit 3cc9a8cadaf66e1a53e5fee48f8bcdb0a3fd5075 ]
When SHM bridge is enabled, assigning RMTFS memory causes the calling core to hang if the system is running in EL1.
Disable SHM bridge on sc7180 devices to avoid that hang.
Signed-off-by: Nikita Travkin nikita@trvn.ru Reviewed-by: Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com Link: https://lore.kernel.org/r/20250721-sc7180-shm-hang-v1-1-99ad9ffeb5b4@trvn.ru Signed-off-by: Bjorn Andersson andersson@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES – Disabling the SHM bridge for sc7180 is a focused bug fix that should be backported.
- `drivers/firmware/qcom/qcom_tzmem.c:79-86` keeps a blacklist of SoCs where SHM bridge must not be activated. Adding `"qcom,sc7180"` there makes the `for` loop in `qcom_tzmem_init()` bail out early (`drivers/firmware/qcom/qcom_tzmem.c:93-109`), leaving `qcom_tzmem_using_shm_bridge` false so the allocator stays in the safe generic mode. - Without this change, sc7180 boots with SHM bridge enabled (arm64 defconfig selects `CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y`, see `arch/arm64/configs/defconfig:265`), so `qcom_scm_shm_bridge_enable()` (`drivers/firmware/qcom/qcom_scm.c:1612-1636`) runs on every boot. On EL1-only firmware this causes the subsequent `qcom_scm_assign_mem()` from the RMTFS driver (`drivers/soc/qcom/rmtfs_mem.c:272-276`) to hang the CPU when it shares the modem buffer—an unrecoverable failure affecting common sc7180 Chromebooks and reference boards. - The fix is consistent with earlier stable backports that blacklisted other SoCs for the same hazard (e.g. commits `55751d3e9e96d`, `8342009efa2a5`, `db3de3ff2611f`), underscoring that the risk is real and the mitigation is accepted practice. - Impact is tightly scoped: only SHM-bridge builds on sc7180 change behaviour, falling back to the pre-existing generic allocator. No API, ABI, or architectural changes are involved, so regression risk is minimal while it prevents a hard hang. - The underlying bug dates back to the SHM-bridge enablement (`f86c61498a573`, in v6.11-rc1), so all stable lines derived from 6.11 (and newer) can be affected and benefit from the blacklist entry.
This satisfies stable-tree criteria: it fixes a severe runtime hang, the patch is tiny and self-contained, and it simply restores the proven-safe allocation mode on the affected hardware.
drivers/firmware/qcom/qcom_tzmem.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/qcom/qcom_tzmem.c b/drivers/firmware/qcom/qcom_tzmem.c index ea0a353556570..12e448669b8bd 100644 --- a/drivers/firmware/qcom/qcom_tzmem.c +++ b/drivers/firmware/qcom/qcom_tzmem.c @@ -77,6 +77,7 @@ static bool qcom_tzmem_using_shm_bridge;
/* List of machines that are known to not support SHM bridge correctly. */ static const char *const qcom_tzmem_blacklist[] = { + "qcom,sc7180", /* hang in rmtfs memory assignment */ "qcom,sc8180x", "qcom,sdm670", /* failure in GPU firmware loading */ "qcom,sdm845", /* reset in rmtfs memory assignment */