[PATCH] firmware: smccc: set variables smccc_soc_id_version,revision storage-class-specifier to static

[PATCH] firmware: smccc: set variables smccc_soc_id_version,revision storage-class-specifier to static

[Tom Rix]

smatch reports
drivers/firmware/smccc/smccc.c:20:21: warning: symbol
  'smccc_soc_id_version' was not declared. Should it be static?
drivers/firmware/smccc/smccc.c:21:21: warning: symbol
  'smccc_soc_id_revision' was not declared. Should it be static?

These variables are only used in their defining file so should be static

Signed-off-by: Tom Rix <trix@redhat.com>
---
 drivers/firmware/smccc/smccc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
index db818f9dcb8e..0cf4c45de417 100644
--- a/drivers/firmware/smccc/smccc.c
+++ b/drivers/firmware/smccc/smccc.c
@@ -17,8 +17,8 @@ static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
 
 bool __ro_after_init smccc_trng_available = false;
 u64 __ro_after_init smccc_has_sve_hint = false;
-s32 __ro_after_init smccc_soc_id_version = SMCCC_RET_NOT_SUPPORTED;
-s32 __ro_after_init smccc_soc_id_revision = SMCCC_RET_NOT_SUPPORTED;
+static s32 __ro_after_init smccc_soc_id_version = SMCCC_RET_NOT_SUPPORTED;
+static s32 __ro_after_init smccc_soc_id_revision = SMCCC_RET_NOT_SUPPORTED;
 
 void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
 {
-- 
2.27.0

Re: [PATCH] firmware: smccc: set variables smccc_soc_id_version,revision storage-class-specifier to static

[Sudeep Holla]

On Sun, Apr 23, 2023 at 11:34:28AM -0400, Tom Rix wrote:
> smatch reports
> drivers/firmware/smccc/smccc.c:20:21: warning: symbol
>   'smccc_soc_id_version' was not declared. Should it be static?
> drivers/firmware/smccc/smccc.c:21:21: warning: symbol
>   'smccc_soc_id_revision' was not declared. Should it be static?
> 
> These variables are only used in their defining file so should be static
>

Acked-by: Sudeep Holla <sudeep.holla@arm.com>

Since the patch introducing this issue comes from irqchip tree, we must
either route this through that if they have earlier fixes set or wait
until v6.4-rc1 and send it through SoC tree. Please cc soc@kernel.org and
Marc Z and repost. It is better to be explicit and mention it is either
based on -next or mention the commit introducing the issue since it make
no sense if one has no knowledge of -next change.

-- 
Regards,
Sudeep