* [PATCH RFC 0/2] Implement vendor resets for PSCI SYSTEM_RESET2
@ 2023-10-30 21:31 ` Elliot Berman
0 siblings, 0 replies; 10+ messages in thread
From: Elliot Berman @ 2023-10-30 21:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Mark Rutland
Cc: Satya Durga Srinivasu Prabhala, Melody Olvera, devicetree,
linux-kernel, linux-arm-kernel, Florian Fainelli, Elliot Berman
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/20230724223057.1208122-2-quic_eberman@quicinc.com/T/
- https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@quicinc.com/
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 <quic_eberman@quicinc.com>
---
Elliot Berman (2):
dt-bindings: arm: Document reboot mode magic
firmware: psci: Read and use vendor reset types
Documentation/devicetree/bindings/arm/psci.yaml | 13 ++++
drivers/firmware/psci/psci.c | 87 ++++++++++++++++++++++++-
2 files changed, 99 insertions(+), 1 deletion(-)
---
base-commit: 22e877699642285c47f5d7d83b2d59815c29ebe8
change-id: 20231016-arm-psci-system_reset2-vendor-reboots-cc3ad456c070
Best regards,
--
Elliot Berman <quic_eberman@quicinc.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread* [PATCH RFC 0/2] Implement vendor resets for PSCI SYSTEM_RESET2 @ 2023-10-30 21:31 ` Elliot Berman 0 siblings, 0 replies; 10+ messages in thread From: Elliot Berman @ 2023-10-30 21:31 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Mark Rutland Cc: Satya Durga Srinivasu Prabhala, Melody Olvera, devicetree, linux-kernel, linux-arm-kernel, Florian Fainelli, Elliot Berman 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/20230724223057.1208122-2-quic_eberman@quicinc.com/T/ - https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@quicinc.com/ 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 <quic_eberman@quicinc.com> --- Elliot Berman (2): dt-bindings: arm: Document reboot mode magic firmware: psci: Read and use vendor reset types Documentation/devicetree/bindings/arm/psci.yaml | 13 ++++ drivers/firmware/psci/psci.c | 87 ++++++++++++++++++++++++- 2 files changed, 99 insertions(+), 1 deletion(-) --- base-commit: 22e877699642285c47f5d7d83b2d59815c29ebe8 change-id: 20231016-arm-psci-system_reset2-vendor-reboots-cc3ad456c070 Best regards, -- Elliot Berman <quic_eberman@quicinc.com> ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH RFC 1/2] dt-bindings: arm: Document reboot mode magic 2023-10-30 21:31 ` Elliot Berman @ 2023-10-30 21:31 ` Elliot Berman -1 siblings, 0 replies; 10+ messages in thread From: Elliot Berman @ 2023-10-30 21:31 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Mark Rutland Cc: Satya Durga Srinivasu Prabhala, Melody Olvera, devicetree, linux-kernel, linux-arm-kernel, Florian Fainelli, Elliot Berman Add bindings to describe vendor-specific reboot modes. Values here correspond to valid parameters to vendor-specific reset types in PSCI SYSTEM_RESET2 call. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> --- Documentation/devicetree/bindings/arm/psci.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml index 0c5381e081bd..dc23e901bd0a 100644 --- a/Documentation/devicetree/bindings/arm/psci.yaml +++ b/Documentation/devicetree/bindings/arm/psci.yaml @@ -122,6 +122,19 @@ patternProperties: [3] Documentation/devicetree/bindings/power/power-domain.yaml [4] Documentation/devicetree/bindings/power/domain-idle-state.yaml + "^reboot-mode-.*$": + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 2 + description: | + Describes a vendor-specific reset type. The string after "reboot-mode-" + maps a reboot mode to the parameters in the PSCI SYSTEM_RESET2 call. + + Parameters are named reboot-mode-xxx = <type[, cookie]>, where xxx + is the name of the magic reboot mode, type is the lower 31 bits + of the reset_type, and, optionally, the cookie value. If the cookie + is not provided, it is defaulted to zero. + required: - compatible - method -- 2.41.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH RFC 1/2] dt-bindings: arm: Document reboot mode magic @ 2023-10-30 21:31 ` Elliot Berman 0 siblings, 0 replies; 10+ messages in thread From: Elliot Berman @ 2023-10-30 21:31 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Mark Rutland Cc: Satya Durga Srinivasu Prabhala, Melody Olvera, devicetree, linux-kernel, linux-arm-kernel, Florian Fainelli, Elliot Berman Add bindings to describe vendor-specific reboot modes. Values here correspond to valid parameters to vendor-specific reset types in PSCI SYSTEM_RESET2 call. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> --- Documentation/devicetree/bindings/arm/psci.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml index 0c5381e081bd..dc23e901bd0a 100644 --- a/Documentation/devicetree/bindings/arm/psci.yaml +++ b/Documentation/devicetree/bindings/arm/psci.yaml @@ -122,6 +122,19 @@ patternProperties: [3] Documentation/devicetree/bindings/power/power-domain.yaml [4] Documentation/devicetree/bindings/power/domain-idle-state.yaml + "^reboot-mode-.*$": + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 2 + description: | + Describes a vendor-specific reset type. The string after "reboot-mode-" + maps a reboot mode to the parameters in the PSCI SYSTEM_RESET2 call. + + Parameters are named reboot-mode-xxx = <type[, cookie]>, where xxx + is the name of the magic reboot mode, type is the lower 31 bits + of the reset_type, and, optionally, the cookie value. If the cookie + is not provided, it is defaulted to zero. + required: - compatible - method -- 2.41.0 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH RFC 1/2] dt-bindings: arm: Document reboot mode magic 2023-10-30 21:31 ` Elliot Berman @ 2023-10-31 17:48 ` Rob Herring -1 siblings, 0 replies; 10+ messages in thread From: Rob Herring @ 2023-10-31 17:48 UTC (permalink / raw) To: Elliot Berman Cc: Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Mark Rutland, Satya Durga Srinivasu Prabhala, Melody Olvera, devicetree, linux-kernel, linux-arm-kernel, Florian Fainelli On Mon, Oct 30, 2023 at 02:31:33PM -0700, Elliot Berman wrote: > Add bindings to describe vendor-specific reboot modes. Values here > correspond to valid parameters to vendor-specific reset types in PSCI > SYSTEM_RESET2 call. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > --- > Documentation/devicetree/bindings/arm/psci.yaml | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml > index 0c5381e081bd..dc23e901bd0a 100644 > --- a/Documentation/devicetree/bindings/arm/psci.yaml > +++ b/Documentation/devicetree/bindings/arm/psci.yaml > @@ -122,6 +122,19 @@ patternProperties: > [3] Documentation/devicetree/bindings/power/power-domain.yaml > [4] Documentation/devicetree/bindings/power/domain-idle-state.yaml > > + "^reboot-mode-.*$": > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 1 > + maxItems: 2 > + description: | > + Describes a vendor-specific reset type. The string after "reboot-mode-" > + maps a reboot mode to the parameters in the PSCI SYSTEM_RESET2 call. > + > + Parameters are named reboot-mode-xxx = <type[, cookie]>, where xxx > + is the name of the magic reboot mode, type is the lower 31 bits > + of the reset_type, and, optionally, the cookie value. If the cookie > + is not provided, it is defaulted to zero. Please use and possibly extend the existing reboot-mode binding. > + > required: > - compatible > - method > > -- > 2.41.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH RFC 1/2] dt-bindings: arm: Document reboot mode magic @ 2023-10-31 17:48 ` Rob Herring 0 siblings, 0 replies; 10+ messages in thread From: Rob Herring @ 2023-10-31 17:48 UTC (permalink / raw) To: Elliot Berman Cc: Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Mark Rutland, Satya Durga Srinivasu Prabhala, Melody Olvera, devicetree, linux-kernel, linux-arm-kernel, Florian Fainelli On Mon, Oct 30, 2023 at 02:31:33PM -0700, Elliot Berman wrote: > Add bindings to describe vendor-specific reboot modes. Values here > correspond to valid parameters to vendor-specific reset types in PSCI > SYSTEM_RESET2 call. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > --- > Documentation/devicetree/bindings/arm/psci.yaml | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml > index 0c5381e081bd..dc23e901bd0a 100644 > --- a/Documentation/devicetree/bindings/arm/psci.yaml > +++ b/Documentation/devicetree/bindings/arm/psci.yaml > @@ -122,6 +122,19 @@ patternProperties: > [3] Documentation/devicetree/bindings/power/power-domain.yaml > [4] Documentation/devicetree/bindings/power/domain-idle-state.yaml > > + "^reboot-mode-.*$": > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 1 > + maxItems: 2 > + description: | > + Describes a vendor-specific reset type. The string after "reboot-mode-" > + maps a reboot mode to the parameters in the PSCI SYSTEM_RESET2 call. > + > + Parameters are named reboot-mode-xxx = <type[, cookie]>, where xxx > + is the name of the magic reboot mode, type is the lower 31 bits > + of the reset_type, and, optionally, the cookie value. If the cookie > + is not provided, it is defaulted to zero. Please use and possibly extend the existing reboot-mode binding. > + > required: > - compatible > - method > > -- > 2.41.0 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH RFC 1/2] dt-bindings: arm: Document reboot mode magic 2023-10-31 17:48 ` Rob Herring @ 2023-10-31 21:25 ` Elliot Berman -1 siblings, 0 replies; 10+ messages in thread From: Elliot Berman @ 2023-10-31 21:25 UTC (permalink / raw) To: Rob Herring Cc: Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Mark Rutland, Satya Durga Srinivasu Prabhala, Melody Olvera, devicetree, linux-kernel, linux-arm-kernel, Florian Fainelli On 10/31/2023 10:48 AM, Rob Herring wrote: > On Mon, Oct 30, 2023 at 02:31:33PM -0700, Elliot Berman wrote: >> Add bindings to describe vendor-specific reboot modes. Values here >> correspond to valid parameters to vendor-specific reset types in PSCI >> SYSTEM_RESET2 call. >> >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> >> --- >> Documentation/devicetree/bindings/arm/psci.yaml | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml >> index 0c5381e081bd..dc23e901bd0a 100644 >> --- a/Documentation/devicetree/bindings/arm/psci.yaml >> +++ b/Documentation/devicetree/bindings/arm/psci.yaml >> @@ -122,6 +122,19 @@ patternProperties: >> [3] Documentation/devicetree/bindings/power/power-domain.yaml >> [4] Documentation/devicetree/bindings/power/domain-idle-state.yaml >> >> + "^reboot-mode-.*$": >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + minItems: 1 >> + maxItems: 2 >> + description: | >> + Describes a vendor-specific reset type. The string after "reboot-mode-" >> + maps a reboot mode to the parameters in the PSCI SYSTEM_RESET2 call. >> + >> + Parameters are named reboot-mode-xxx = <type[, cookie]>, where xxx >> + is the name of the magic reboot mode, type is the lower 31 bits >> + of the reset_type, and, optionally, the cookie value. If the cookie >> + is not provided, it is defaulted to zero. > > Please use and possibly extend the existing reboot-mode binding. > Sure, I can do that. I noticed most of the reboot-mode devices not doing that, but they probably should. I've sent patches to fix that: https://lore.kernel.org/all/20231031-ref-reboot-mode-v1-1-18dde4faf7e8@quicinc.com/ https://lore.kernel.org/all/20231031-ref-nvmem-reboot-mode-v1-1-c1af9070ce52@quicinc.com/ >> + >> required: >> - compatible >> - method >> >> -- >> 2.41.0 >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH RFC 1/2] dt-bindings: arm: Document reboot mode magic @ 2023-10-31 21:25 ` Elliot Berman 0 siblings, 0 replies; 10+ messages in thread From: Elliot Berman @ 2023-10-31 21:25 UTC (permalink / raw) To: Rob Herring Cc: Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Mark Rutland, Satya Durga Srinivasu Prabhala, Melody Olvera, devicetree, linux-kernel, linux-arm-kernel, Florian Fainelli On 10/31/2023 10:48 AM, Rob Herring wrote: > On Mon, Oct 30, 2023 at 02:31:33PM -0700, Elliot Berman wrote: >> Add bindings to describe vendor-specific reboot modes. Values here >> correspond to valid parameters to vendor-specific reset types in PSCI >> SYSTEM_RESET2 call. >> >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> >> --- >> Documentation/devicetree/bindings/arm/psci.yaml | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml >> index 0c5381e081bd..dc23e901bd0a 100644 >> --- a/Documentation/devicetree/bindings/arm/psci.yaml >> +++ b/Documentation/devicetree/bindings/arm/psci.yaml >> @@ -122,6 +122,19 @@ patternProperties: >> [3] Documentation/devicetree/bindings/power/power-domain.yaml >> [4] Documentation/devicetree/bindings/power/domain-idle-state.yaml >> >> + "^reboot-mode-.*$": >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + minItems: 1 >> + maxItems: 2 >> + description: | >> + Describes a vendor-specific reset type. The string after "reboot-mode-" >> + maps a reboot mode to the parameters in the PSCI SYSTEM_RESET2 call. >> + >> + Parameters are named reboot-mode-xxx = <type[, cookie]>, where xxx >> + is the name of the magic reboot mode, type is the lower 31 bits >> + of the reset_type, and, optionally, the cookie value. If the cookie >> + is not provided, it is defaulted to zero. > > Please use and possibly extend the existing reboot-mode binding. > Sure, I can do that. I noticed most of the reboot-mode devices not doing that, but they probably should. I've sent patches to fix that: https://lore.kernel.org/all/20231031-ref-reboot-mode-v1-1-18dde4faf7e8@quicinc.com/ https://lore.kernel.org/all/20231031-ref-nvmem-reboot-mode-v1-1-c1af9070ce52@quicinc.com/ >> + >> required: >> - compatible >> - method >> >> -- >> 2.41.0 >> ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH RFC 2/2] firmware: psci: Read and use vendor reset types 2023-10-30 21:31 ` Elliot Berman @ 2023-10-30 21:31 ` Elliot Berman -1 siblings, 0 replies; 10+ messages in thread From: Elliot Berman @ 2023-10-30 21:31 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Mark Rutland Cc: Satya Durga Srinivasu Prabhala, Melody Olvera, devicetree, linux-kernel, linux-arm-kernel, Florian Fainelli, Elliot Berman SoC vendors have different types of resets and are controlled through various registers. For instance, Qualcomm chipsets can reboot to a "download mode" that allows a RAM dump to be collected. Another example is they also support writing a cookie that can be read by bootloader during next boot. PSCI offers a mechanism, SYSTEM_RESET2, for these vendor reset types to be implemented without requiring drivers for every register/cookie. Add support in PSCI to statically map reboot mode commands from userspace to a vendor reset and cookie value using the device tree. Reboot mode framework is close but doesn't quite fit with the design and requirements for PSCI SYSTEM_RESET2. Some of these issues can be solved but doesn't seem reasonable in sum: 1. reboot mode registers against the reboot_notifier_list, which is too early to call SYSTEM_RESET2. PSCI would need to remember the reset type from the reboot-mode framework callback and use it psci_sys_reset. 2. reboot mode assumes only one cookie/parameter is described in the device tree. SYSTEM_RESET2 uses 2: one for the type and one for cookie. 3. psci cpuidle driver already registers a driver against the arm,psci-1.0 compatible. Refactoring would be needed to have both a cpuidle and reboot-mode driver. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> --- drivers/firmware/psci/psci.c | 87 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 86 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c index d9629ff87861..93914b48a950 100644 --- a/drivers/firmware/psci/psci.c +++ b/drivers/firmware/psci/psci.c @@ -29,6 +29,8 @@ #include <asm/smp_plat.h> #include <asm/suspend.h> +#define REBOOT_PREFIX "reboot-mode-" + /* * While a 64-bit OS can make calls with SMC32 calling conventions, for some * calls it is necessary to use SMC64 to pass or return 64-bit values. @@ -79,6 +81,14 @@ struct psci_0_1_function_ids get_psci_0_1_function_ids(void) static u32 psci_cpu_suspend_feature; static bool psci_system_reset2_supported; +struct psci_reset_param { + const char *mode; + u32 reset_type; + u32 cookie; +}; +static struct psci_reset_param *psci_reset_params; +static size_t num_psci_reset_params; + static inline bool psci_has_ext_power_state(void) { return psci_cpu_suspend_feature & @@ -305,11 +315,29 @@ static int get_set_conduit_method(const struct device_node *np) return 0; } +static void psci_vendor_sys_reset2(unsigned long action, void *data) +{ + const char *cmd = data; + size_t i; + + for (i = 0; i < num_psci_reset_params; i++) { + if (!strcmp(psci_reset_params[i].mode, cmd)) { + invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), + psci_reset_params[i].reset_type, + psci_reset_params[i].cookie, 0); + break; + } + } +} + static int psci_sys_reset(struct notifier_block *nb, unsigned long action, void *data) { + if (psci_system_reset2_supported && num_psci_reset_params) + psci_vendor_sys_reset2(action, data); + if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) && - psci_system_reset2_supported) { + psci_system_reset2_supported) { /* * reset_type[31] = 0 (architectural) * reset_type[30:0] = 0 (SYSTEM_WARM_RESET) @@ -748,6 +776,63 @@ static const struct of_device_id psci_of_match[] __initconst = { {}, }; +static int __init psci_init_system_reset2_modes(void) +{ + const size_t len = strlen(REBOOT_PREFIX); + struct psci_reset_param *param; + struct device_node *np; + struct property *prop; + size_t count = 0; + u32 magic[2]; + int ret; + + if (!psci_system_reset2_supported) + return 0; + + np = of_find_matching_node(NULL, psci_of_match); + if (!np) + return 0; + + for_each_property_of_node(np, prop) { + if (strncmp(prop->name, REBOOT_PREFIX, len)) + continue; + ret = of_property_count_elems_of_size(np, prop->name, sizeof(magic[0])); + if (ret != 1 && ret != 2) + continue; + + count++; + } + + param = psci_reset_params = kcalloc(count, sizeof(*psci_reset_params), GFP_KERNEL); + if (!psci_reset_params) + return -ENOMEM; + + for_each_property_of_node(np, prop) { + if (strncmp(prop->name, REBOOT_PREFIX, len)) + continue; + + param->mode = kstrdup_const(prop->name + len, GFP_KERNEL); + if (!param->mode) + continue; + + ret = of_property_read_variable_u32_array(np, prop->name, magic, 1, 2); + if (ret < 0) { + pr_warn("Failed to parse vendor reboot mode %s\n", param->mode); + kfree(param->mode); + continue; + } + + /* Force reset type to be in vendor space */ + param->reset_type = PSCI_1_1_RESET_TYPE_VENDOR_START | magic[0]; + param->cookie = ret == 2 ? magic[1] : 0; + param++; + num_psci_reset_params++; + } + + return 0; +} +arch_initcall(psci_init_system_reset2_modes); + int __init psci_dt_init(void) { struct device_node *np; -- 2.41.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH RFC 2/2] firmware: psci: Read and use vendor reset types @ 2023-10-30 21:31 ` Elliot Berman 0 siblings, 0 replies; 10+ messages in thread From: Elliot Berman @ 2023-10-30 21:31 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Mark Rutland Cc: Satya Durga Srinivasu Prabhala, Melody Olvera, devicetree, linux-kernel, linux-arm-kernel, Florian Fainelli, Elliot Berman SoC vendors have different types of resets and are controlled through various registers. For instance, Qualcomm chipsets can reboot to a "download mode" that allows a RAM dump to be collected. Another example is they also support writing a cookie that can be read by bootloader during next boot. PSCI offers a mechanism, SYSTEM_RESET2, for these vendor reset types to be implemented without requiring drivers for every register/cookie. Add support in PSCI to statically map reboot mode commands from userspace to a vendor reset and cookie value using the device tree. Reboot mode framework is close but doesn't quite fit with the design and requirements for PSCI SYSTEM_RESET2. Some of these issues can be solved but doesn't seem reasonable in sum: 1. reboot mode registers against the reboot_notifier_list, which is too early to call SYSTEM_RESET2. PSCI would need to remember the reset type from the reboot-mode framework callback and use it psci_sys_reset. 2. reboot mode assumes only one cookie/parameter is described in the device tree. SYSTEM_RESET2 uses 2: one for the type and one for cookie. 3. psci cpuidle driver already registers a driver against the arm,psci-1.0 compatible. Refactoring would be needed to have both a cpuidle and reboot-mode driver. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> --- drivers/firmware/psci/psci.c | 87 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 86 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c index d9629ff87861..93914b48a950 100644 --- a/drivers/firmware/psci/psci.c +++ b/drivers/firmware/psci/psci.c @@ -29,6 +29,8 @@ #include <asm/smp_plat.h> #include <asm/suspend.h> +#define REBOOT_PREFIX "reboot-mode-" + /* * While a 64-bit OS can make calls with SMC32 calling conventions, for some * calls it is necessary to use SMC64 to pass or return 64-bit values. @@ -79,6 +81,14 @@ struct psci_0_1_function_ids get_psci_0_1_function_ids(void) static u32 psci_cpu_suspend_feature; static bool psci_system_reset2_supported; +struct psci_reset_param { + const char *mode; + u32 reset_type; + u32 cookie; +}; +static struct psci_reset_param *psci_reset_params; +static size_t num_psci_reset_params; + static inline bool psci_has_ext_power_state(void) { return psci_cpu_suspend_feature & @@ -305,11 +315,29 @@ static int get_set_conduit_method(const struct device_node *np) return 0; } +static void psci_vendor_sys_reset2(unsigned long action, void *data) +{ + const char *cmd = data; + size_t i; + + for (i = 0; i < num_psci_reset_params; i++) { + if (!strcmp(psci_reset_params[i].mode, cmd)) { + invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), + psci_reset_params[i].reset_type, + psci_reset_params[i].cookie, 0); + break; + } + } +} + static int psci_sys_reset(struct notifier_block *nb, unsigned long action, void *data) { + if (psci_system_reset2_supported && num_psci_reset_params) + psci_vendor_sys_reset2(action, data); + if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) && - psci_system_reset2_supported) { + psci_system_reset2_supported) { /* * reset_type[31] = 0 (architectural) * reset_type[30:0] = 0 (SYSTEM_WARM_RESET) @@ -748,6 +776,63 @@ static const struct of_device_id psci_of_match[] __initconst = { {}, }; +static int __init psci_init_system_reset2_modes(void) +{ + const size_t len = strlen(REBOOT_PREFIX); + struct psci_reset_param *param; + struct device_node *np; + struct property *prop; + size_t count = 0; + u32 magic[2]; + int ret; + + if (!psci_system_reset2_supported) + return 0; + + np = of_find_matching_node(NULL, psci_of_match); + if (!np) + return 0; + + for_each_property_of_node(np, prop) { + if (strncmp(prop->name, REBOOT_PREFIX, len)) + continue; + ret = of_property_count_elems_of_size(np, prop->name, sizeof(magic[0])); + if (ret != 1 && ret != 2) + continue; + + count++; + } + + param = psci_reset_params = kcalloc(count, sizeof(*psci_reset_params), GFP_KERNEL); + if (!psci_reset_params) + return -ENOMEM; + + for_each_property_of_node(np, prop) { + if (strncmp(prop->name, REBOOT_PREFIX, len)) + continue; + + param->mode = kstrdup_const(prop->name + len, GFP_KERNEL); + if (!param->mode) + continue; + + ret = of_property_read_variable_u32_array(np, prop->name, magic, 1, 2); + if (ret < 0) { + pr_warn("Failed to parse vendor reboot mode %s\n", param->mode); + kfree(param->mode); + continue; + } + + /* Force reset type to be in vendor space */ + param->reset_type = PSCI_1_1_RESET_TYPE_VENDOR_START | magic[0]; + param->cookie = ret == 2 ? magic[1] : 0; + param++; + num_psci_reset_params++; + } + + return 0; +} +arch_initcall(psci_init_system_reset2_modes); + int __init psci_dt_init(void) { struct device_node *np; -- 2.41.0 ^ permalink raw reply related [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-10-31 21:26 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-10-30 21:31 [PATCH RFC 0/2] Implement vendor resets for PSCI SYSTEM_RESET2 Elliot Berman 2023-10-30 21:31 ` Elliot Berman 2023-10-30 21:31 ` [PATCH RFC 1/2] dt-bindings: arm: Document reboot mode magic Elliot Berman 2023-10-30 21:31 ` Elliot Berman 2023-10-31 17:48 ` Rob Herring 2023-10-31 17:48 ` Rob Herring 2023-10-31 21:25 ` Elliot Berman 2023-10-31 21:25 ` Elliot Berman 2023-10-30 21:31 ` [PATCH RFC 2/2] firmware: psci: Read and use vendor reset types Elliot Berman 2023-10-30 21:31 ` Elliot Berman
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.