[PATCH] rtc: rs5c372: add missing error code for unknown RTC type

[PATCH] rtc: rs5c372: add missing error code for unknown RTC type

[Liu Dalin]

In rs5c372_probe(), when an unknown RTC type is encountered in the
switch default case, the local variable 'err' is still 0 from its
initialization. The subsequent goto to the exit label then returns
success, even though probe has failed.

Set err = -ENODEV before jumping to exit to properly report the
failure to the caller.

Fixes smatch warnings:
- drivers/rtc/rtc-rs5c372.c:860 rs5c372_probe() warn: missing error
  code 'err'

Fixes: cb26b572dc394 ("[PATCH] Update the rtc-rs5c372 driver")
Assisted-by: smatch:2.0 [static analysis]
Signed-off-by: Liu Dalin <liudalin@kylinsec.com.cn>
---
 drivers/rtc/rtc-rs5c372.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
index 24bd795d9d95..84407119caba 100644
--- a/drivers/rtc/rtc-rs5c372.c
+++ b/drivers/rtc/rtc-rs5c372.c
@@ -857,6 +857,7 @@ static int rs5c372_probe(struct i2c_client *client)
 		break;
 	default:
 		dev_err(&client->dev, "unknown RTC type\n");
+		err = -ENODEV;
 		goto exit;
 	}
 
-- 
2.43.0

Re: [PATCH] rtc: rs5c372: add missing error code for unknown RTC type

[Alexandre Belloni]

On 27/08/2026 09:58:46+0800, Liu Dalin wrote:
> In rs5c372_probe(), when an unknown RTC type is encountered in the
> switch default case, the local variable 'err' is still 0 from its
> initialization. The subsequent goto to the exit label then returns
> success, even though probe has failed.
> 
> Set err = -ENODEV before jumping to exit to properly report the
> failure to the caller.
> 
> Fixes smatch warnings:
> - drivers/rtc/rtc-rs5c372.c:860 rs5c372_probe() warn: missing error
>   code 'err'
> 
> Fixes: cb26b572dc394 ("[PATCH] Update the rtc-rs5c372 driver")
> Assisted-by: smatch:2.0 [static analysis]
> Signed-off-by: Liu Dalin <liudalin@kylinsec.com.cn>
> ---
>  drivers/rtc/rtc-rs5c372.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
> index 24bd795d9d95..84407119caba 100644
> --- a/drivers/rtc/rtc-rs5c372.c
> +++ b/drivers/rtc/rtc-rs5c372.c
> @@ -857,6 +857,7 @@ static int rs5c372_probe(struct i2c_client *client)
>  		break;
>  	default:
>  		dev_err(&client->dev, "unknown RTC type\n");
> +		err = -ENODEV;

But isn't this dead code that will never be reached? In what case would
you be probed and not match any i2c_device_id?

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH] rtc: rs5c372: add missing error code for unknown RTC type

[liudalin]

在 2026/9/30 05:48, Alexandre Belloni 写道:
> On 27/08/2026 09:58:46+0800, Liu Dalin wrote:
>> In rs5c372_probe(), when an unknown RTC type is encountered in the
>> switch default case, the local variable 'err' is still 0 from its
>> initialization. The subsequent goto to the exit label then returns
>> success, even though probe has failed.
>>
>> Set err = -ENODEV before jumping to exit to properly report the
>> failure to the caller.
>>
>> Fixes smatch warnings:
>> - drivers/rtc/rtc-rs5c372.c:860 rs5c372_probe() warn: missing error
>>    code 'err'
>>
>> Fixes: cb26b572dc394 ("[PATCH] Update the rtc-rs5c372 driver")
>> Assisted-by: smatch:2.0 [static analysis]
>> Signed-off-by: Liu Dalin <liudalin@kylinsec.com.cn>
>> ---
>>   drivers/rtc/rtc-rs5c372.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
>> index 24bd795d9d95..84407119caba 100644
>> --- a/drivers/rtc/rtc-rs5c372.c
>> +++ b/drivers/rtc/rtc-rs5c372.c
>> @@ -857,6 +857,7 @@ static int rs5c372_probe(struct i2c_client *client)
>>   		break;
>>   	default:
>>   		dev_err(&client->dev, "unknown RTC type\n");
>> +		err = -ENODEV;
> But isn't this dead code that will never be reached? In what case would
> you be probed and not match any i2c_device_id?

Thanks for reviewing.

You are correct that the default case is dead code for current driver logic.

Alternatively we could remove the default case entirely, but keeping it 
with proper error assignment is safer for future maintenance.