On 10/22/2025 7:05 PM, Dan Carpenter wrote:
The kernel implementation of snprintf() cannot return negative error
codes. Also these particular calls to snprintf() can't return zero
and the code to handle a zero return is sort of questionable. Just
delete this impossible code.
Signed-off-by: Dan Carpenter <[email protected]>
---
drivers/remoteproc/mtk_scp.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 10e3f9eb8cd2..9b624948a572 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -1127,11 +1127,9 @@ static const char *scp_get_default_fw_path(struct device
*dev, int core_id)
return ERR_PTR(-EINVAL);
if (core_id >= 0)
- ret = snprintf(scp_fw_file, ARRAY_SIZE(scp_fw_file),
"scp_c%1d", core_id);
+ snprintf(scp_fw_file, ARRAY_SIZE(scp_fw_file), "scp_c%1d",
core_id);
Hello Dan Carpenter,
The patch looks fine to me functionally. However, one concern beyond the
current scope: if core_id >= 10 in future extensions, the
snprintf(scp_fw_file, ARRAY_SIZE(scp_fw_file), "scp_c%1d", core_id) may
cause truncation.
scp_add_multi_core
|
v
scp_rproc_init
|
v
scp_get_default_fw_path
char scp_fw_file[7];
To guard against this, maybe should we consider adding:
if (ret >= ARRAY_SIZE(scp_fw_file))
return ERR_PTR(-ENAMETOOLONG);
or just expand the scp_fw_file[7] array?
Thank you~
else
- ret = snprintf(scp_fw_file, ARRAY_SIZE(scp_fw_file), "scp");
- if (ret <= 0)
- return ERR_PTR(ret);
+ snprintf(scp_fw_file, ARRAY_SIZE(scp_fw_file), "scp");
/* Not using strchr here, as strlen of a const gets optimized by compiler */
soc = &compatible[strlen("mediatek,")];
--
Thx and BRs,
Zhongqiu Han
