kernel/linux.git/drivers/soc/qcom/cmd-db.c, branch v6.19.11

soc: qcom: cmd-db: Use devm_memremap() to fix memory leak in cmd_db_dev_probe

2026-02-26T23:00:52+00:00

[ Upstream commit 0da7824734d8d83e6a844dd0207f071cb0c50cf4 ] If cmd_db_magic_matches() fails after memremap() succeeds, the function returns -EINVAL without unmapping the memory region, causing a potential resource leak. Switch to devm_memremap to automatically manage the map resource. Fixes: 312416d9171a ("drivers: qcom: add command DB driver") Suggested-by: Dmitry Baryshkov Signed-off-by: Haotian Zhang Link: https://lore.kernel.org/r/20251216013933.773-1-vulab@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

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

2024-07-29T02:59:45+00:00

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: cmd-db: replace deprecated strncpy with strtomem

2024-04-21T17:26:47+00:00

strncpy() is an ambiguous and potentially dangerous interface [1]. We should prefer more robust and less ambiguous alternatives. @query is marked as __nonstring and doesn't need to be NUL-terminated. Since we are doing a string to memory copy, we can use the aptly named "strtomem" -- specifically, the "pad" variant to also ensure NUL-padding throughout the destination buffer. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Reviewed-by: Kees Cook Signed-off-by: Justin Stitt Link: https://lore.kernel.org/r/20240319-strncpy-drivers-soc-qcom-cmd-db-c-v3-1-aeb5c5180c32@google.com Signed-off-by: Bjorn Andersson

soc: qcom: rpmh-rsc: Enhance check for VRM in-flight request

2024-04-21T17:11:40+00:00

Each RPMh VRM accelerator resource has 3 or 4 contiguous 4-byte aligned addresses associated with it. These control voltage, enable state, mode, and in legacy targets, voltage headroom. The current in-flight request checking logic looks for exact address matches. Requests for different addresses of the same RPMh resource as thus not detected as in-flight. Add new cmd-db API cmd_db_match_resource_addr() to enhance the in-flight request check for VRM requests by ignoring the address offset. This ensures that only one request is allowed to be in-flight for a given VRM resource. This is needed to avoid scenarios where request commands are carried out by RPMh hardware out-of-order leading to LDO regulator over-current protection triggering. Fixes: 658628e7ef78 ("drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio Tested-by: Elliot Berman # sm8650-qrd Signed-off-by: Maulik Shah Link: https://lore.kernel.org/r/20240215-rpmh-rsc-fixes-v4-1-9cbddfcba05b@quicinc.com Signed-off-by: Bjorn Andersson

soc: qcom: Update init level to core_initcall() for cmd-db and rpmh-rsc

2024-03-16T18:06:59+00:00

cmd-db and rpmh-rsc are used by clients like regulators, interconnects and clocks for resource voting. These clients are in core_initcall() while cmd-db and rpmh-rsc are in arch_initcall(). Update init level for these drivers also to core_initcall() to avoid unnecessary probe defer during boot up. Signed-off-by: Maulik Shah Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/20240217-init_level-v1-1-bde9e11f8317@quicinc.com Signed-off-by: Bjorn Andersson

soc: qcom: Switch to EXPORT_SYMBOL_GPL()

2023-09-27T23:08:38+00:00

Switch to GPL version of EXPORT_SYMBOL for Qualcomm SoC drivers. Signed-off-by: Unnathi Chalicheemala Reviewed-by: Trilok Soni Link: https://lore.kernel.org/r/20230922184817.5183-1-quic_uchalich@quicinc.com Signed-off-by: Bjorn Andersson

soc: qcom: cmd-db: Drop NUL bytes from debugfs output

2023-07-10T04:18:29+00:00

The debugfs dump of Command DB relies uses %*pEp to print the resource identifiers, with escaping of non-printable characters. But p (ESCAPE_NP) does not escape NUL characters, so for identifiers less than 8 bytes in length the output will retain these. This does not cause an issue while looking at the dump in the terminal (no known complaints at least), but when programmatically consuming the debugfs output the extra characters are unwanted. Change the fixed 8-byte sizeof() to a dynamic strnlen() to avoid printing these NUL characters. Signed-off-by: Bjorn Andersson Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20230620213703.283583-1-quic_bjorande@quicinc.com Signed-off-by: Bjorn Andersson

soc: qcom: cmd-db: Mark device as having no PM support

2022-10-17T22:58:15+00:00

This driver purely exposes information from memory to the kernel. Let's mark it as not having any device PM functionality, so that during suspend we skip even trying to call a suspend function on this device. This clears up suspend logs more than anything else, but it also shaves a few cycles off suspend. Cc: Konrad Dybcio Signed-off-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221015004934.3930651-1-swboyd@chromium.org

soc: qcom: cmd-db: replace strscpy_pad() with strncpy()

2022-06-28T19:44:44+00:00

Commit ac0126a01735 ("soc: qcom: cmd-db: replace strncpy() with strscpy_pad()") breaks booting on my sc7280-herobrine-herobrine device. From printouts I see that at bootup the function is called with an id of "lnbclka2" which is 8 bytes big. Previously all 8 bytes of this string were copied to the destination. Now only 7 bytes will be copied since strscpy_pad() saves a byte for '\0' termination. We don't need the '\0' termination in the destination. Let's go back to strncpy(). According to the warning: If a caller is using non-NUL-terminated strings, strncpy() can still be used, but destinations should be marked with the __nonstring attribute to avoid future compiler warnings. ...so we'll do that. While we're at it, let's change the query array to use "sizeof(ent->id)" so it can't possibly go out of sync with our later copy. Fixes: ac0126a01735 ("soc: qcom: cmd-db: replace strncpy() with strscpy_pad()") Signed-off-by: Douglas Anderson Reviewed-by: Matthias Kaehlcke Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220628064301.v3.1.Ie7b480cd99e2c13319220cbc108caf2bcd41286b@changeid

soc: qcom: cmd-db: replace strncpy() with strscpy_pad()

2022-06-26T03:05:31+00:00

The use of strncpy() is considered deprecated for NUL-terminated strings[1]. Replace strncpy() with strscpy_pad(), to keep existing pad-behavior of strncpy. This fixes W=1 warning: drivers/soc/qcom/cmd-db.c: In function ‘cmd_db_get_header.part.0’: drivers/soc/qcom/cmd-db.c:151:9: warning: ‘strncpy’ specified bound 8 equals destination size [-Wstringop-truncation] 151 | strncpy(query, id, sizeof(query)); [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings Signed-off-by: Krzysztof Kozlowski Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220519073301.7072-1-krzysztof.kozlowski@linaro.org