Re: [RFC PATCH v3 3/3] arm64: dts: rockchip: fix power-off on Firefly-RK3399

[Yaozhong Li <yaozhonguwl@gmail.com>]

On 2026-09-29 14:13 UTC, sashiko-bot@kernel.org wrote:
> By delegating this core power-off requirement to the optional
> pwm-backlight driver, could the board reboot instead of powering off
> if the backlight driver is inactive?

I plan to keep the GPIO1_D0-only description in v4, and to make the
commit message say what the backlight does and does not guarantee.

On the emergency case: the PMIC's power-off prepare handler runs from
kernel_power_off(), after device_shutdown(). orderly_poweroff() and
the forced hardware-protection path both go through kernel_power_off().
emergency_restart() does skip device_shutdown(), but it restarts and
never runs this handler.

With pwm-backlight bound, it sets GPIO1_B5 low when it powers the
backlight off, and its shutdown callback attempts that from
device_shutdown(); the result of that GPIO write is not checked. On
this board, with the backlight on at full brightness beforehand, the
GPIO1_D0-only setup stayed off in 3 of 3 runs. GPIO1_B5 itself was
not sampled at the PMIC handler in those runs.

With pwm-backlight not bound, it does not claim GPIO1_B5. The pin was
an input reading low on this board, and that setup also stayed off in
3 of 3 runs. That is an observation on one board, not something the
kernel guarantees. In particular, if a bootloader left GPIO1_B5 high
and pwm-backlight failed to probe before setting the pin, it could
remain high. I have not tested that case.

The alternative, listing GPIO1_B5 in power-hold-gpios, means removing
the backlight's enable-gpios, and I have no schematic showing that
property is wrong. That is open question 4 in the cover letter.

Thanks,
Yaozhong

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip