On Fri, Jan 21, 2022 at 07:54:17PM -0800, Florian Fainelli wrote:
Hi all,
Hi Florian,
This patch series contains the Broadcom STB PSCI extensions which adds
some additional functions on top of the existing standard PSCI interface
which is the reason for having the driver implement a custom
suspend_ops.
I *really* don't like the idea of having non-standard PSCI extensions, because
it somewhat defeats the point of PSCI being a standard, and opens the door for
the zoo of mechanisms we had on 32-bit.
I think this needs a fair amount more explanation and justification.
These platforms have traditionally supported a mode that is akin to
ACPI's S2 with the CPU in WFI and all of the chip being clock gated
which is entered with "echo standby > /sys/power/state". Additional a
true suspend to DRAM as defined in ACPI by S3 is implemented with "echo
mem > /sys/power/state".
Why isn't a combination of CPU_SUSPEND and SYSTEM_SUSPEND sufficient here?
What specifically *can't* you do with standard PSCI calls?
These platforms also may have an external Broadcom PMIC chip which can
cause the SoC to be powercycled assuming that we communicate that intent
via a vendor specific PSCI SYSTEM_RESET2.
Since it is desirable to get any new functionality added to the kernel
to be loadable as a module as part of shipping said products in a Google
Kernel Image (GKI) environment, we need to export a couple of symbols from
drivers/firmware/psci/psci.c.
I really don't want to export the guts of psci.c.