Re: [PATCH 2/2] rtc: ds1685: keep setting PAB until power is removed

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] rtc: ds1685: sleep in atomic/poweroff context causes deadlock
--

commit 4f1dff5106d71cbe4c516d23f941007e8e8aa503
Author: Imre Kaloz <kaloz@kernel.org>

rtc: ds1685: keep setting PAB until power is removed

This commit alters the ds1685_rtc_poweroff function to continuously clear
event flags and set the PAB bit until power is gone, replacing the previous
busy spin.

> diff --git a/drivers/rtc/rtc-ds1685.c b/drivers/rtc/rtc-ds1685.c
> index 94c89333c5d5c..a7828f0d6c09e 100644
> --- a/drivers/rtc/rtc-ds1685.c
> +++ b/drivers/rtc/rtc-ds1685.c
> @@ -1424,15 +1424,21 @@ ds1685_rtc_poweroff(struct platform_device *pdev)
>  			rtc->write(rtc, RTC_EXT_CTRL_4B, ctrl4b);
>  		}
>  
> -		/* Set PAB to 1 in Control 4A to power the system down. */
> +		/*
> +		 * Set PAB to 1 in Control 4A to power the system down.  PAB
> +		 * is cleared again while KF and KSE, or WF and WIE, are set,
> +		 * so keep clearing the flags and setting PAB until power is
> +		 * gone.  We do not switch back to bank0.
> +		 */
>  		dev_warn(&pdev->dev, "Powerdown.\n");
>  		msleep(20);

[Severity: High]
This problem wasn't introduced by this patch, but ds1685_rtc_poweroff() is
used as a system power-off handler which executes at the end of the shutdown
sequence, often with preemption or local interrupts disabled.

Does this msleep() trigger a scheduling while atomic bug by delegating to
schedule_timeout_uninterruptible() in this context?

If local interrupts are disabled, could this also block indefinitely without
making progress because the scheduler timer tick will not be serviced?

> -		rtc->write(rtc, RTC_EXT_CTRL_4A,
> -			   (ctrl4a | RTC_CTRL_4A_PAB));
> -
> -		/* Spin ... we do not switch back to bank0. */
> -		while(1);
> -		unreachable();
> +		while (1) {
> +			ctrl4a = rtc->read(rtc, RTC_EXT_CTRL_4A);
> +			rtc->write(rtc, RTC_EXT_CTRL_4A,
> +				   (ctrl4a & ~RTC_CTRL_4A_RWK_MASK) |
> +				   RTC_CTRL_4A_PAB);
> +			msleep(100);

[Severity: High]
This patch changes the original busy-spin loop into an infinite loop that
calls msleep(100).

Since this is executing in an atomic power-off context, won't this trigger
the same scheduling while atomic issue or system deadlock as mentioned
above?

Hardware power-off routines typically require busy-waits like mdelay()
instead of msleep() to avoid yielding the CPU while interrupts are disabled.

> +		}
>  	}
>  }
>  EXPORT_SYMBOL_GPL(ds1685_rtc_poweroff);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013094930.574-1-kaloz@kernel.org?part=2