MIPS: SGI-IP30: power off through the RTC

arch/mips/sgi-ip30/ip30-power.c static void ip30_machine_power_off(void) · line 66

[Severity: High]
As reported by Sashiko on v1 [1], can another CPU still race on the indirect RTC index/data registers and bank selection while ds1685_rtc_poweroff() is running?

On SGI IP30, the DS1687 is accessed in indirect register mode (ds1685_reg_indirect), where every ds1685_indirect_read() and ds1685_indirect_write() performs two separate MMIO accesses to rtc->regs and rtc->data, and RTC_EXT_CTRL_4A (0x4a) is only accessible while Bank 1 is selected.

Claiming ip30_power_off_claimed only serializes callers of ip30_machine_power_off() against each other; it does not stop other CPUs or acquire rtc_lock(rtc->dev), and ds1685_rtc_poweroff() only calls disable_irq_nosync(rtc->irq_num):

1. If a second power button interrupt starts ds1685_rtc_extended_irq() on

     another CPU before HEART interrupts are masked, that handler sleeps in
     msleep(500) and wakes via the per-CPU CP0 timer interrupt (which is not
     routed through HEART). It then accesses RTC_EXT_CTRL_4B via rtc->regs
     and rtc->data before calling rtc->prepare_poweroff():

     drivers/rtc/rtc-ds1685.c:ds1685_rtc_extended_irq() {
         ...
         msleep(500);
         rtc->write(rtc, RTC_EXT_CTRL_4B,
                    (rtc->read(rtc, RTC_EXT_CTRL_4B) |
                     RTC_CTRL_4B_KSE));

         if (rtc->prepare_poweroff != NULL)
             rtc->prepare_poweroff();
         ...
         ds1685_rtc_switch_to_bank0(rtc);
     }

2. After ip30_prepare_poweroff() returns on the first press, ds1685_rtc_extended_irq() calls ds1685_rtc_switch_to_bank0(rtc), which can race with a concurrent pm_power_off() call.

3. During ip30_power_timeout() or userspace shutdown (such as hwclock on another CPU), normal RTC ops, NVRAM accesses, or sysfs/procfs reads acquire rtc_lock(rtc->dev), drive rtc->regs and rtc->data, and switch the chip back to Bank 0.

If another CPU changes the index register or switches the RTC back to Bank 0 before ds1685_rtc_poweroff() writes RTC_CTRL_4A_PAB to RTC_EXT_CTRL_4A, wouldn't that write corrupt battery-backed Bank 0 NVRAM at offset 0x4a and leave the system spinning forever without cutting power?

arch/mips/sgi-ip30/ip30-power.c static void ip30_machine_power_off(void) · line 80

[Severity: High]
Doesn't ds1685_rtc_poweroff() sleep in msleep(20) before cutting power, violating the atomic context established by local_irq_disable() and nbcon_cpu_emergency_enter()?

In drivers/rtc/rtc-ds1685.c, ds1685_rtc_poweroff() calls msleep(20) right before setting RTC_CTRL_4A_PAB:

drivers/rtc/rtc-ds1685.c:ds1685_rtc_poweroff() {
    ...
    /* Set PAB to 1 in Control 4A to power the system down. */
    dev_warn(&pdev->dev, "Powerdown.\n");
    msleep(20);
    rtc->write(rtc, RTC_EXT_CTRL_4A,
               (ctrl4a | RTC_CTRL_4A_PAB));
}

Because ip30_machine_power_off() disables local interrupts and calls nbcon_cpu_emergency_enter() (which disables preemption and increments the per-CPU emergency nesting count), calling msleep(20) -> schedule() triggers a scheduling-while-atomic bug, context-switches with the per-CPU nbcon emergency nesting count elevated, and re-enables local interrupts when the scheduler unlocks the runqueue.

Furthermore, while the claimant task is sleeping in msleep(20), if a concurrent caller of ip30_machine_power_off() (such as ip30_power_timeout(), poweroff_work from orderly_poweroff(), or the RTC IRQ thread on a second button press) gets scheduled onto the same CPU, it will call local_irq_disable(), see ip30_power_off_claimed == 1, and spin forever in cpu_relax() with interrupts disabled. Wouldn't that prevent the 20ms timer wakeup from ever completing and permanently deadlock the machine before RTC_CTRL_4A_PAB is written?

drivers/mfd/ioc3.c static struct ds1685_rtc_platform_data ip30_rtc_platform_data = { · line 330

[Severity: High]
What happens on a power button press when CONFIG_SGI_IP30=y and CONFIG_RTC_DRV_DS1685_FAMILY=m?

Previously, ip30_rtc_platform_data.plat_prepare_poweroff was NULL, so when rtc-ds1685 was built as a module, ds1685_rtc_extended_irq() fell back to calling ds1685_rtc_poweroff(pdev) directly inside the module.

With this change, ip30_rtc_platform_data.plat_prepare_poweroff is wired up whenever CONFIG_SGI_IP30 is enabled, overriding the direct ds1685_rtc_poweroff(pdev) fallback. However, in built-in arch/mips/sgi-ip30/ip30-power.c, IS_REACHABLE(CONFIG_RTC_DRV_DS1685_FAMILY) is false when CONFIG_RTC_DRV_DS1685_FAMILY=m:

arch/mips/sgi-ip30/ip30-power.c:ip30_machine_power_off() {
    if (!IS_REACHABLE(CONFIG_RTC_DRV_DS1685_FAMILY))
        return;
    ...
}

As a result, pm_power_off is not registered and ip30_machine_power_off() is a no-op, so neither orderly_poweroff(true), ip30_power_timeout(), nor a second power button press can cut power.

In addition, in ip30_prepare_poweroff(), the second-press path:

	if (ip30_shutting_down)
		ip30_machine_power_off();

has no return statement, so whenever ip30_machine_power_off() returns early (for example when !IS_REACHABLE(CONFIG_RTC_DRV_DS1685_FAMILY) or if the rtc-ds1685 device is unbound), execution falls through and re-runs orderly_poweroff(true) and schedule_delayed_work(). Should plat_prepare_poweroff only be set when IS_REACHABLE(CONFIG_RTC_DRV_DS1685_FAMILY) (or Kconfig updated so ip30-power.c can always reach the driver), and should the second-press branch in ip30_prepare_poweroff() return?

[1] https://lore.kernel.org/r/[email protected]

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2