linux-kernel - Re: [PATCH v7 3/5] firmware: psci: Read and use vendor reset types

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE-0n52buO+oJfesc+025hogm7BygMp4dO6b2_6aAoXVKRBs7w@mail.gmail.com>
Date: Mon, 28 Oct 2024 14:57:55 -0400
From: Stephen Boyd <swboyd@...omium.org>
To: Andy Yan <andy.yan@...k-chips.com>, Arnd Bergmann <arnd@...db.de>, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, Bjorn Andersson <andersson@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Conor Dooley <conor+dt@...nel.org>, 
	Elliot Berman <quic_eberman@...cinc.com>, Konrad Dybcio <konradybcio@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Lorenzo Pieralisi <lpieralisi@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, Olof Johansson <olof@...om.net>, Rob Herring <robh@...nel.org>, 
	Sebastian Reichel <sre@...nel.org>, Vinod Koul <vkoul@...nel.org>, Will Deacon <will@...nel.org>, 
	cros-qcom-dts-watchers@...omium.org
Cc: Satya Durga Srinivasu Prabhala <quic_satyap@...cinc.com>, Melody Olvera <quic_molvera@...cinc.com>, 
	Shivendra Pratap <quic_spratap@...cinc.com>, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	Florian Fainelli <florian.fainelli@...adcom.com>, linux-pm@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v7 3/5] firmware: psci: Read and use vendor reset types

Quoting Elliot Berman (2024-10-28 11:44:57)
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 2328ca58bba6..2d7b6efc8743 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -79,6 +79,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;

These two can be __ro_after_init

> +
>  static inline bool psci_has_ext_power_state(void)
>  {
>         return psci_cpu_suspend_feature &
> @@ -305,9 +313,38 @@ static int get_set_conduit_method(const struct device_node *np)
>         return 0;
>  }
>
> +static void psci_vendor_system_reset2(unsigned long action, void *data)

Can 'data' simply be 'const char *cmd' instead?

And can 'action' be dropped? It isn't used in this function.

> +{
> +       const char *cmd = data;
> +       unsigned long ret;
> +       size_t i;
> +
> +       for (i = 0; i < num_psci_reset_params; i++) {
> +               if (!strcmp(psci_reset_params[i].mode, cmd)) {
> +                       ret = invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2),
> +                                            psci_reset_params[i].reset_type,
> +                                            psci_reset_params[i].cookie, 0);
> +                       /*
> +                        * if vendor reset fails, log it and fall back to
> +                        * architecture reset types
> +                        */
> +                       pr_err("failed to perform reset \"%s\": %ld\n", cmd,
> +                              (long)ret);

			return?

because we're not going to try another one, right?