[PATCH 05/11] sysreset: qcom-pshold: PM8916 PON reset type support

[Simon Glass]

Hi Sam,

On 2026-06-06T08:47:32, Sam Day via B4 Relay
<devnull+me.samcday.com at kernel.org> wrote:
> sysreset: qcom-pshold: PM8916 PON reset type support
>
> Before de-asserting PS_HOLD, PM8916 PMIC can be informed of what kind of
> reset should take place.
>
> This might seem a little hacky/weird, but it's a byproduct of how the DT
> nodes are structured, and the way u-boot handles sysreset.
>
> The qcom,pshold node does not belong to the PMIC hierarchy. If U-Boot's
> sysreset infra was a little more flexible, we might be able to model the
> qcom,pm8916-pon driver as UCLASS_SYSRESET in order to catch the sysreset
> type and set the appropriate bits in the PMIC, before chaining to the
> pshold driver to de-assert PS_HOLD (which actually triggers the reset
> type that was written in the previous step).
>
> Signed-off-by: Sam Day <me at samcday.com>
>
> drivers/sysreset/sysreset_qcom-pshold.c | 9 +++++++++
>  1 file changed, 9 insertions(+)

> diff --git a/drivers/sysreset/sysreset_qcom-pshold.c b/drivers/sysreset/sysreset_qcom-pshold.c
> @@ -13,6 +13,8 @@
>  #include <sysreset.h>
>  #include <asm/io.h>
>  #include <linux/delay.h>
> +#include <dm/device_compat.h>
> +#include 'pm8916_pon.h'

Please use #include <pm8916_pon.h> - quoted form is reserved for
headers in the same directory as the .c file.

> diff --git a/drivers/sysreset/sysreset_qcom-pshold.c b/drivers/sysreset/sysreset_qcom-pshold.c
> @@ -22,6 +24,13 @@ static int qcom_pshold_request(struct udevice *dev, enum sysreset_t type)
>  {
>       struct qcom_pshold_priv *priv = dev_get_priv(dev);
>
> +     if (CONFIG_IS_ENABLED(PM8916_PON)) {
> +             int ret = pm8916_pon_set_reboot_type(type);
> +
> +             if (ret)
> +                     dev_err(dev, "Failed to set reboot type: %d\n", ret);
> +     }

The header already provides a -ENOSYS stub when PM8916_PON is
disabled, so the CONFIG_IS_ENABLED() guard is redundant - the compiler
will elide the call. Dropping it would also stop -ENOSYS being logged
as a spurious error on platforms that don't enable the option (you'd
want to filter -ENOSYS from the error path, or just rely on the stub
returning success).

On the design point in the commit message: rather than reaching across
uclasses with a global lookup, I agree with Casey - better to make the
qcom,pm8916-pon node a UCLASS_SYSRESET driver itself, with a phandle
to the pshold node, then chain via sysreset_walk() - that avoids the
awkward coupling and the CONFIG_IS_ENABLED() gate. What do you think?

Regards,
Simon