The PSCI SYSTEM_RESET2 call allows vendor firmware to define additional
reset types which could be mapped to the reboot argument.
Setting up reboot on Qualcomm devices can be inconsistent from chipset
to chipset. Generally, there is a PMIC register that gets written to
decide the reboot type. There is also sometimes a cookie that can be
written to indicate that the bootloader should behave differently than a
regular boot. These knobs evolve over product generations and require
more drivers. Qualcomm firmwares are beginning to expose vendor
SYSTEM_RESET2 types to simplify driver requirements from Linux.
Add support in PSCI to statically wire reboot mode commands from
userspace to a vendor reset and cookie value using the device tree. The
DT bindings are similar to reboot mode framework except that 2
integers are accepted (the type and cookie). Also, reboot mode framework
is intended to program, but not reboot, the host. PSCI SYSTEM_RESET2
does both. I've not added support for reading ACPI tables since I don't
have any device which provides them + firmware that supports vendor
SYSTEM_RESET2 types.
Previous discussions around SYSTEM_RESET2:
- https://lore.kernel.org/lkml/[email protected]/T/
- https://lore.kernel.org/all/[email protected]/
This RFC approach differs from the one sent in July by:
- Not using the reboot mode framework
- Added support to control both reset type and cookie
- Implicitly dropped "normal" reboot command, which is always just
SYSTEM_RESET anyway.
Signed-off-by: Elliot Berman <[email protected]>
---
Changes since RFC:
- Reference reboot-mode bindings as suggeted by Rob.
- Link to RFC: https://lore.kernel.org/r/20231030-arm-psci-system_reset2-vendor-reboots-v1-0-dcdd63352ad1@quicinc.com
---
Elliot Berman (3):
dt-bindings: power: reset: Convert mode-.* properties to array
dt-bindings: arm: Document reboot mode magic
firmware: psci: Read and use vendor reset types
Documentation/devicetree/bindings/arm/psci.yaml | 36 ++++++++-
.../bindings/power/reset/reboot-mode.yaml | 7 +-
drivers/firmware/psci/psci.c | 87 +++++++++++++++++++++-
3 files changed, 125 insertions(+), 5 deletions(-)
---
base-commit: f86128050d2d854035bfa461aadf36e6951b2bac
change-id: 20231016-arm-psci-system_reset2-vendor-reboots-cc3ad456c070
Best regards,
--
Elliot Berman <[email protected]>
On 17/11/2023 22:18, Elliot Berman wrote:
> The PSCI SYSTEM_RESET2 call allows vendor firmware to define additional
> reset types which could be mapped to the reboot argument.
>
> Setting up reboot on Qualcomm devices can be inconsistent from chipset
> to chipset. Generally, there is a PMIC register that gets written to
> decide the reboot type. There is also sometimes a cookie that can be
> written to indicate that the bootloader should behave differently than a
> regular boot. These knobs evolve over product generations and require
> more drivers. Qualcomm firmwares are beginning to expose vendor
> SYSTEM_RESET2 types to simplify driver requirements from Linux.
>
> Add support in PSCI to statically wire reboot mode commands from
> userspace to a vendor reset and cookie value using the device tree. The
> DT bindings are similar to reboot mode framework except that 2
> integers are accepted (the type and cookie). Also, reboot mode framework
> is intended to program, but not reboot, the host. PSCI SYSTEM_RESET2
> does both. I've not added support for reading ACPI tables since I don't
> have any device which provides them + firmware that supports vendor
> SYSTEM_RESET2 types.
>
> Previous discussions around SYSTEM_RESET2:
> - https://lore.kernel.org/lkml/[email protected]/T/
> - https://lore.kernel.org/all/[email protected]/
Please link here upstream DTS user for this.
Best regards,
Krzysztof
On 11/20/2023 2:55 AM, Krzysztof Kozlowski wrote:
> On 17/11/2023 22:18, Elliot Berman wrote:
>> The PSCI SYSTEM_RESET2 call allows vendor firmware to define additional
>> reset types which could be mapped to the reboot argument.
>>
>> Setting up reboot on Qualcomm devices can be inconsistent from chipset
>> to chipset. Generally, there is a PMIC register that gets written to
>> decide the reboot type. There is also sometimes a cookie that can be
>> written to indicate that the bootloader should behave differently than a
>> regular boot. These knobs evolve over product generations and require
>> more drivers. Qualcomm firmwares are beginning to expose vendor
>> SYSTEM_RESET2 types to simplify driver requirements from Linux.
>>
>> Add support in PSCI to statically wire reboot mode commands from
>> userspace to a vendor reset and cookie value using the device tree. The
>> DT bindings are similar to reboot mode framework except that 2
>> integers are accepted (the type and cookie). Also, reboot mode framework
>> is intended to program, but not reboot, the host. PSCI SYSTEM_RESET2
>> does both. I've not added support for reading ACPI tables since I don't
>> have any device which provides them + firmware that supports vendor
>> SYSTEM_RESET2 types.
>>
>> Previous discussions around SYSTEM_RESET2:
>> - https://lore.kernel.org/lkml/[email protected]/T/
>> - https://lore.kernel.org/all/[email protected]/
>
> Please link here upstream DTS user for this.
The changes are applicable for SM8650, but hasn't yet landed in arm64/for-next/core.
I'll include it in the v2 with note.
On 20/11/2023 17:03, Elliot Berman wrote:
>
>
> On 11/20/2023 2:55 AM, Krzysztof Kozlowski wrote:
>> On 17/11/2023 22:18, Elliot Berman wrote:
>>> The PSCI SYSTEM_RESET2 call allows vendor firmware to define additional
>>> reset types which could be mapped to the reboot argument.
>>>
>>> Setting up reboot on Qualcomm devices can be inconsistent from chipset
>>> to chipset. Generally, there is a PMIC register that gets written to
>>> decide the reboot type. There is also sometimes a cookie that can be
>>> written to indicate that the bootloader should behave differently than a
>>> regular boot. These knobs evolve over product generations and require
>>> more drivers. Qualcomm firmwares are beginning to expose vendor
>>> SYSTEM_RESET2 types to simplify driver requirements from Linux.
>>>
>>> Add support in PSCI to statically wire reboot mode commands from
>>> userspace to a vendor reset and cookie value using the device tree. The
>>> DT bindings are similar to reboot mode framework except that 2
>>> integers are accepted (the type and cookie). Also, reboot mode framework
>>> is intended to program, but not reboot, the host. PSCI SYSTEM_RESET2
>>> does both. I've not added support for reading ACPI tables since I don't
>>> have any device which provides them + firmware that supports vendor
>>> SYSTEM_RESET2 types.
>>>
>>> Previous discussions around SYSTEM_RESET2:
>>> - https://lore.kernel.org/lkml/[email protected]/T/
>>> - https://lore.kernel.org/all/[email protected]/
>>
>> Please link here upstream DTS user for this.
>
> The changes are applicable for SM8650, but hasn't yet landed in arm64/for-next/core.
>
> I'll include it in the v2 with note.
It's enough if you link to lore or any other upstream-oriented tree with
that user. Does not have to be merged.
Best regards,
Krzysztof