user/sven/linux.git/drivers/soc/qcom, branch v6.11.8

EDAC/qcom: Make irq configuration optional

2024-11-14T12:20:54Z

[ Upstream commit 0a97195d2181caced187acd7454464b8e37021d7 ] On most modern qualcomm SoCs, the configuration necessary to enable the Tag/Data RAM related irqs being propagated to the SoC irq controller is already done in firmware (in DSF or 'DDR System Firmware') On some like the x1e80100, these registers aren't even accesible to the kernel causing a crash when edac device is probed. Hence, make the irq configuration optional in the driver and mark x1e80100 as the SoC on which this should be avoided. Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") Reported-by: Bjorn Andersson Signed-off-by: Rajendra Nayak Reviewed-by: Manivannan Sadhasivam Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20240903101510.3452734-1-quic_rjendra@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

soc: qcom: pmic_glink: Handle GLINK intent allocation rejections

2024-11-08T15:30:56Z

commit f8c879192465d9f328cb0df07208ef077c560bb1 upstream. Some versions of the pmic_glink firmware does not allow dynamic GLINK intent allocations, attempting to send a message before the firmware has allocated its receive buffers and announced these intent allocations will fail. When this happens something like this showns up in the log: pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to send altmode request: 0x10 (-125) pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to request altmode notifications: -125 ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125 qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications GLINK has been updated to distinguish between the cases where the remote is going down (-ECANCELED) and the intent allocation being rejected (-EAGAIN). Retry the send until intent buffers becomes available, or an actual error occur. To avoid infinitely waiting for the firmware in the event that this misbehaves and no intents arrive, an arbitrary 5 second timeout is used. This patch was developed with input from Chris Lew. Reported-by: Johan Hovold Closes: https://lore.kernel.org/all/Zqet8iInnDhnxkT9@hovoldconsulting.com/#t Cc: stable@vger.kernel.org # rpmsg: glink: Handle rejected intent request better Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Tested-by: Johan Hovold Reviewed-by: Johan Hovold Signed-off-by: Bjorn Andersson Reviewed-by: Chris Lew Link: https://lore.kernel.org/r/20241023-pmic-glink-ecancelled-v2-2-ebc268129407@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

Revert "soc: qcom: smd-rpm: Match rpmsg channel instead of compatible"

2024-10-04T14:38:31Z

commit b17155133391d7f6dd18d3fb94a7d492fdec18fa upstream. The rpm_requests device nodes have the compatible node. As such the rpmsg core uses OF modalias instead of a native rpmsg modalias. Thus if smd-rpm is built as a module, it doesn't get autoloaded for the device. Revert the commit bcabe1e09135 ("soc: qcom: smd-rpm: Match rpmsg channel instead of compatible") Fixes: bcabe1e09135 ("soc: qcom: smd-rpm: Match rpmsg channel instead of compatible") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240729-fix-smd-rpm-v2-1-0776408a94c5@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

soc: qcom: pd-mapper: Fix singleton refcount

2024-08-21T14:50:48Z

The Qualcomm pd-mapper is a refcounted singleton, but the refcount is never incremented, which means the as soon as any remoteproc instance stops the count will hit 0. At this point the pd-mapper QMI service is stopped, leaving firmware without access to the PD information. Stopping any other remoteproc instances will result in a use-after-free, which best case manifest itself as a refcount underflow: refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 354 at lib/refcount.c:87 refcount_dec_and_mutex_lock+0xc4/0x148 ... Call trace: refcount_dec_and_mutex_lock+0xc4/0x148 qcom_pdm_remove+0x40/0x118 [qcom_pd_mapper] ... Fix this by incrementing the refcount, so that the pd-mapper is only torn down when the last remoteproc stops, as intended. Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation") Signed-off-by: Bjorn Andersson Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240820-pd-mapper-refcount-fix-v1-1-03ea65c0309b@quicinc.com Signed-off-by: Bjorn Andersson

soc: qcom: pmic_glink: Actually communicate when remote goes down

2024-08-21T13:37:37Z

When the pmic_glink state is UP and we either receive a protection- domain (PD) notification indicating that the PD is going down, or that the whole remoteproc is going down, it's expected that the pmic_glink client instances are notified that their function has gone DOWN. This is not what the code does, which results in the client state either not updating, or being wrong in many cases. So let's fix the conditions. Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Reviewed-by: Neil Armstrong Reviewed-by: Dmitry Baryshkov Tested-by: Amit Pundir Reviewed-by: Johan Hovold Tested-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-3-eec53c750a04@quicinc.com Signed-off-by: Bjorn Andersson

usb: typec: ucsi: Move unregister out of atomic section

2024-08-21T13:37:37Z

Commit '9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping")' moved the pmic_glink client list under a spinlock, as it is accessed by the rpmsg/glink callback, which in turn is invoked from IRQ context. This means that ucsi_unregister() is now called from atomic context, which isn't feasible as it's expecting a sleepable context. An effort is under way to get GLINK to invoke its callbacks in a sleepable context, but until then lets schedule the unregistration. A side effect of this is that ucsi_unregister() can now happen after the remote processor, and thereby the communication link with it, is gone. pmic_glink_send() is amended with a check to avoid the resulting NULL pointer dereference. This does however result in the user being informed about this error by the following entry in the kernel log: ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5 Fixes: 9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping") Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Reviewed-by: Neil Armstrong Reviewed-by: Dmitry Baryshkov Tested-by: Amit Pundir Reviewed-by: Johan Hovold Tested-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-2-eec53c750a04@quicinc.com Signed-off-by: Bjorn Andersson

soc: qcom: pmic_glink: Fix race during initialization

2024-08-21T13:37:30Z

As pointed out by Stephen Boyd it is possible that during initialization of the pmic_glink child drivers, the protection-domain notifiers fires, and the associated work is scheduled, before the client registration returns and as a result the local "client" pointer has been initialized. The outcome of this is a NULL pointer dereference as the "client" pointer is blindly dereferenced. Timeline provided by Stephen: CPU0 CPU1 ---- ---- ucsi->client = NULL; devm_pmic_glink_register_client() client->pdr_notify(client->priv, pg->client_state) pmic_glink_ucsi_pdr_notify() schedule_work(&ucsi->register_work) pmic_glink_ucsi_register() ucsi_register() pmic_glink_ucsi_read_version() pmic_glink_ucsi_read() pmic_glink_ucsi_read() pmic_glink_send(ucsi->client) ucsi->client = client // Too late! This code is identical across the altmode, battery manager and usci child drivers. Resolve this by splitting the allocation of the "client" object and the registration thereof into two operations. This only happens if the protection domain registry is populated at the time of registration, which by the introduction of commit '1ebcde047c54 ("soc: qcom: add pd-mapper implementation")' became much more likely. Reported-by: Amit Pundir Closes: https://lore.kernel.org/all/CAMi1Hd2_a7TjA7J9ShrAbNOd_CoZ3D87twmO5t+nZxC9sX18tA@mail.gmail.com/ Reported-by: Johan Hovold Closes: https://lore.kernel.org/all/ZqiyLvP0gkBnuekL@hovoldconsulting.com/ Reported-by: Stephen Boyd Closes: https://lore.kernel.org/all/CAE-0n52JgfCBWiFQyQWPji8cq_rCsviBpW-m72YitgNfdaEhQg@mail.gmail.com/ Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Reviewed-by: Neil Armstrong Tested-by: Amit Pundir Reviewed-by: Johan Hovold Acked-by: Sebastian Reichel Tested-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-1-eec53c750a04@quicinc.com Signed-off-by: Bjorn Andersson

soc: qcom: pd-mapper: mark qcom_pdm_domains as __maybe_unused

2024-07-29T03:01:25Z

The qcom_pdm_domains[] array is used only when passing it into of_match_node() but is not also referenced by MODULE_DEVICE_TABLE() or the platform driver as a table. When CONFIG_OF is disabled, this causes a harmless build warning: drivers/soc/qcom/qcom_pd_mapper.c:520:34: error: 'qcom_pdm_domains' defined but not used [-Werror=unused-const-variable=] Avoid this by marking the variable as __maybe_unused. This also makes it clear that anything referenced by it will be dropped by the compiler when it is unused. Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation") Signed-off-by: Arnd Bergmann Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240719101238.199850-1-arnd@kernel.org Signed-off-by: Bjorn Andersson

soc: qcom: cmd-db: Map shared memory as WC, not WB

2024-07-29T02:59:45Z

Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. Fixes: 312416d9171a ("drivers: qcom: add command DB driver") Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Volodymyr Babchuk Tested-by: Nikita Travkin # sc7180 WoA in EL2 Signed-off-by: Maulik Shah Tested-by: Pavankumar Kondeti Reviewed-by: Caleb Connolly Link: https://lore.kernel.org/r/20240718-cmd_db_uncached-v2-1-f6cf53164c90@quicinc.com Signed-off-by: Bjorn Andersson

soc: qcom: pd-mapper: Depend on ARCH_QCOM || COMPILE_TEST

2024-07-29T02:37:00Z

The pd-mapper driver doesn't make sense on non Qualcomm systems. Let's follow suit with the rest of the Qualcomm SoC Kconfigs and depend on ARCH_QCOM || COMPILE_TEST to avoid asking users about a config they will not use. Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation") Signed-off-by: Andrew Halaney Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240725-pd-mapper-config-v1-1-f26e513608c6@redhat.com Signed-off-by: Bjorn Andersson