Re: [PATCH v9 3/6] rtc: s35390a: Fix alarm not disabling

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] rtc: s35390a: unhandled interrupt storm in alarm_irq_enable()
--

commit f08c593edb80ced466b342983365673dd8bdb4ee
Author: Markus Probst <markus.probst@posteo.de>

rtc: s35390a: Fix alarm not disabling

Implement alarm_irq_enable callback.

> diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
> index 4cfe7034c5165..575bb256eb258 100644
> --- a/drivers/rtc/rtc-s35390a.c
> +++ b/drivers/rtc/rtc-s35390a.c
> @@ -270,6 +270,24 @@ static int s35390a_rtc_read_time(struct device *dev, struct rtc_time *tm)
>  	return 0;
>  }
>  
> +static int s35390a_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
> +{
> +	struct s35390a *s35390a = dev_get_drvdata(dev);
> +	u8 sts;
> +	int err;
> +
> +	if (enabled)
> +		sts = S35390A_INT2_MODE_ALARM;
> +	else
> +		sts = S35390A_INT2_MODE_NOINTR;
> +
> +	err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, &sts, sizeof(sts));

[Severity: High]
Does this code risk causing an unhandled interrupt storm if a previous alarm
was pending?

The S-35390A hardware holds the alarm interrupt flag in STATUS1 until it is
explicitly read. If a previous alarm fired and STATUS1 was not read, the flag
remains set.

When userspace calls ioctl(RTC_AIE_ON), the RTC core directly invokes
s35390a_rtc_alarm_irq_enable(1) without calling .set_alarm(). Writing to
STATUS2 enables the INT2 alarm output, but without first reading STATUS1 to
clear any pending interrupt, the hardware will immediately assert the INT2 pin
if the flag is still set.

Because the driver has no runtime ISR to acknowledge the interrupt, could the
pin remain asserted indefinitely and prevent the system from sleeping or
disable shared IRQ lines?

> +	if (err < 0)
> +		return err;
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916-rtc_s35390a_int1-v9-0-b2567a3e4959@posteo.de?part=3