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

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

2026-03-04T12:19:36+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-09-04T11:28:28+00:00

commit f9bb896eab221618927ae6a2f1d566567999839d upstream. 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 Signed-off-by: Greg Kroah-Hartman

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

2024-06-16T11:47:33+00:00

commit f592cc5794747b81e53b53dd6e80219ee25f0611 upstream. 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 Signed-off-by: Greg Kroah-Hartman

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

soc: qcom: cmd-db: allow loading as a module

2020-10-26T21:02:29+00:00

This patch enables Command DB driver to be loaded as a module. Command DB is inherent to RPMH interaction and as such would never be unloaded. Add supress_bind_attrs to make it a permanently loaded module. Reviewed-by: John Stultz Reviewed-by: Greg Kroah-Hartman Tested-by: John Stultz Signed-off-by: Lina Iyer Link: https://lore.kernel.org/r/20201001154144.5226-1-ilina@codeaurora.org Signed-off-by: Bjorn Andersson

soc: qcom: cmd-db: Properly endian swap the slv_id for debugfs

2020-04-20T06:06:29+00:00

Read the slv_id properly by making sure the 16-bit number is endian swapped from little endian to CPU native before we read it to figure out what to print for the human readable name. Otherwise we may just show that all the elements in the cmd-db are "Unknown" which isn't right. Reviewed-by: Guenter Roeck Reported-by: kbuild test robot Cc: Lina Iyer Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20200417000645.234693-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson

soc: qcom: cmd-db: Use 5 digits for printing address

2020-04-20T06:06:29+00:00

The top few bits aren't relevant to pad out because they're always zero. Let's just print 5 digits instead of 8 so that it's a little shorter and more readable. Reviewed-by: Lina Iyer Suggested-by: Lina Iyer Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20200415192916.78339-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson