drivers/firmware/efi/stmm/tee_stmm_efi.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)
The 'struct efivar_operations' is not modified by the driver after
initialization, so it should follow typical practice of being static
const for increased code safety and readability.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/firmware/efi/stmm/tee_stmm_efi.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/firmware/efi/stmm/tee_stmm_efi.c b/drivers/firmware/efi/stmm/tee_stmm_efi.c
index 7b04dd649629..3bea2ef50ef3 100644
--- a/drivers/firmware/efi/stmm/tee_stmm_efi.c
+++ b/drivers/firmware/efi/stmm/tee_stmm_efi.c
@@ -14,7 +14,6 @@
#include "mm_communication.h"
static struct efivars tee_efivars;
-static struct efivar_operations tee_efivar_ops;
static size_t max_buffer_size; /* comm + var + func + data */
static size_t max_payload_size; /* func + data */
@@ -520,6 +519,15 @@ static void tee_stmm_restore_efivars_generic_ops(void)
efivars_generic_ops_register();
}
+static const struct efivar_operations tee_efivar_ops = {
+ .get_variable = tee_get_variable,
+ .get_next_variable = tee_get_next_variable,
+ .set_variable = tee_set_variable,
+ .set_variable_nonblocking = tee_set_variable_nonblocking,
+ .query_variable_store = efi_query_variable_store,
+ .query_variable_info = tee_query_variable_info,
+};
+
static int tee_stmm_efi_probe(struct tee_client_device *tee_dev)
{
struct device *dev = &tee_dev->dev;
@@ -558,13 +566,6 @@ static int tee_stmm_efi_probe(struct tee_client_device *tee_dev)
MM_VARIABLE_COMMUNICATE_SIZE +
max_payload_size;
- tee_efivar_ops.get_variable = tee_get_variable;
- tee_efivar_ops.get_next_variable = tee_get_next_variable;
- tee_efivar_ops.set_variable = tee_set_variable;
- tee_efivar_ops.set_variable_nonblocking = tee_set_variable_nonblocking;
- tee_efivar_ops.query_variable_store = efi_query_variable_store;
- tee_efivar_ops.query_variable_info = tee_query_variable_info;
-
efivars_generic_ops_unregister();
pr_info("Using TEE-based EFI runtime variable services\n");
efivars_register(&tee_efivars, &tee_efivar_ops);
--
2.51.0Hi Krzysztof,
On Sun, 15 Feb 2026 at 13:06, Krzysztof Kozlowski
<krzysztof.kozlowski@oss.qualcomm.com> wrote:
>
> The 'struct efivar_operations' is not modified by the driver after
> initialization, so it should follow typical practice of being static
> const for increased code safety and readability.
get_maintainers doesn't include me in the cc list?
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> drivers/firmware/efi/stmm/tee_stmm_efi.c | 17 +++++++++--------
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/firmware/efi/stmm/tee_stmm_efi.c b/drivers/firmware/efi/stmm/tee_stmm_efi.c
> index 7b04dd649629..3bea2ef50ef3 100644
> --- a/drivers/firmware/efi/stmm/tee_stmm_efi.c
> +++ b/drivers/firmware/efi/stmm/tee_stmm_efi.c
> @@ -14,7 +14,6 @@
> #include "mm_communication.h"
>
> static struct efivars tee_efivars;
> -static struct efivar_operations tee_efivar_ops;
>
> static size_t max_buffer_size; /* comm + var + func + data */
> static size_t max_payload_size; /* func + data */
> @@ -520,6 +519,15 @@ static void tee_stmm_restore_efivars_generic_ops(void)
> efivars_generic_ops_register();
> }
>
> +static const struct efivar_operations tee_efivar_ops = {
> + .get_variable = tee_get_variable,
> + .get_next_variable = tee_get_next_variable,
> + .set_variable = tee_set_variable,
> + .set_variable_nonblocking = tee_set_variable_nonblocking,
> + .query_variable_store = efi_query_variable_store,
> + .query_variable_info = tee_query_variable_info,
> +};
> +
> static int tee_stmm_efi_probe(struct tee_client_device *tee_dev)
> {
> struct device *dev = &tee_dev->dev;
> @@ -558,13 +566,6 @@ static int tee_stmm_efi_probe(struct tee_client_device *tee_dev)
> MM_VARIABLE_COMMUNICATE_SIZE +
> max_payload_size;
>
> - tee_efivar_ops.get_variable = tee_get_variable;
> - tee_efivar_ops.get_next_variable = tee_get_next_variable;
> - tee_efivar_ops.set_variable = tee_set_variable;
> - tee_efivar_ops.set_variable_nonblocking = tee_set_variable_nonblocking;
> - tee_efivar_ops.query_variable_store = efi_query_variable_store;
> - tee_efivar_ops.query_variable_info = tee_query_variable_info;
> -
> efivars_generic_ops_unregister();
> pr_info("Using TEE-based EFI runtime variable services\n");
> efivars_register(&tee_efivars, &tee_efivar_ops);
> --
> 2.51.0
>
>
On 16/02/2026 10:49, Ilias Apalodimas wrote: > Hi Krzysztof, > > On Sun, 15 Feb 2026 at 13:06, Krzysztof Kozlowski > <krzysztof.kozlowski@oss.qualcomm.com> wrote: >> >> The 'struct efivar_operations' is not modified by the driver after >> initialization, so it should follow typical practice of being static >> const for increased code safety and readability. > > get_maintainers doesn't include me in the cc list? I use only get_maintainers and as you can see no. You might want to add yourself as maintainer of this driver if that's your part. Or have korgalore/lei filters. Best regards, Krzysztof
On Mon, 16 Feb 2026 at 12:33, Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> wrote: > > On 16/02/2026 10:49, Ilias Apalodimas wrote: > > Hi Krzysztof, > > > > On Sun, 15 Feb 2026 at 13:06, Krzysztof Kozlowski > > <krzysztof.kozlowski@oss.qualcomm.com> wrote: > >> > >> The 'struct efivar_operations' is not modified by the driver after > >> initialization, so it should follow typical practice of being static > >> const for increased code safety and readability. > > > > get_maintainers doesn't include me in the cc list? > > I use only get_maintainers and as you can see no. You might want to add > yourself as maintainer of this driver if that's your part. Or have > korgalore/lei filters. Hrrm, that's weird. Running it locally returns a more extended list which includes me and Sumit Garg. I'll have a look on what's going on. Thanks /Ilias > > Best regards, > Krzysztof
On 16/02/2026 11:43, Ilias Apalodimas wrote: > On Mon, 16 Feb 2026 at 12:33, Krzysztof Kozlowski > <krzysztof.kozlowski@oss.qualcomm.com> wrote: >> >> On 16/02/2026 10:49, Ilias Apalodimas wrote: >>> Hi Krzysztof, >>> >>> On Sun, 15 Feb 2026 at 13:06, Krzysztof Kozlowski >>> <krzysztof.kozlowski@oss.qualcomm.com> wrote: >>>> >>>> The 'struct efivar_operations' is not modified by the driver after >>>> initialization, so it should follow typical practice of being static >>>> const for increased code safety and readability. >>> >>> get_maintainers doesn't include me in the cc list? >> >> I use only get_maintainers and as you can see no. You might want to add >> yourself as maintainer of this driver if that's your part. Or have >> korgalore/lei filters. > > Hrrm, that's weird. Running it locally returns a more extended list > which includes me and Sumit Garg. You might be using git fallback, but this is not a maintainer. It shows random people either involved or not involved (like cc-ing me on half of kernel drivers), thus it is not recommended for daily use and all tools (e.g b4 or personal scripts) do not use fallbacks. > I'll have a look on what's going on. Best regards, Krzysztof
On Mon, 16 Feb 2026, at 12:07, Krzysztof Kozlowski wrote: > On 16/02/2026 11:43, Ilias Apalodimas wrote: >> On Mon, 16 Feb 2026 at 12:33, Krzysztof Kozlowski >> <krzysztof.kozlowski@oss.qualcomm.com> wrote: >>> >>> On 16/02/2026 10:49, Ilias Apalodimas wrote: >>>> Hi Krzysztof, >>>> >>>> On Sun, 15 Feb 2026 at 13:06, Krzysztof Kozlowski >>>> <krzysztof.kozlowski@oss.qualcomm.com> wrote: >>>>> >>>>> The 'struct efivar_operations' is not modified by the driver after >>>>> initialization, so it should follow typical practice of being static >>>>> const for increased code safety and readability. >>>> >>>> get_maintainers doesn't include me in the cc list? >>> >>> I use only get_maintainers and as you can see no. You might want to add >>> yourself as maintainer of this driver if that's your part. Or have >>> korgalore/lei filters. >> >> Hrrm, that's weird. Running it locally returns a more extended list >> which includes me and Sumit Garg. > > You might be using git fallback, but this is not a maintainer. It shows > random people either involved or not involved (like cc-ing me on half of > kernel drivers), thus it is not recommended for daily use and all tools > (e.g b4 or personal scripts) do not use fallbacks. > The code you are touching came in via a different tree in the current merge window, and so this patch doesn't even apply to the EFI tree. Those 'random people' are the ones you should have sent this to, if you had taken the time to look at the history of the code you are modifying. So please don't lecture other people on how to use the tools. I've queued this up now - I'll send it to Linus by the end of the week. Thanks.
On 17/02/2026 12:30, Ard Biesheuvel wrote: > > > On Mon, 16 Feb 2026, at 12:07, Krzysztof Kozlowski wrote: >> On 16/02/2026 11:43, Ilias Apalodimas wrote: >>> On Mon, 16 Feb 2026 at 12:33, Krzysztof Kozlowski >>> <krzysztof.kozlowski@oss.qualcomm.com> wrote: >>>> >>>> On 16/02/2026 10:49, Ilias Apalodimas wrote: >>>>> Hi Krzysztof, >>>>> >>>>> On Sun, 15 Feb 2026 at 13:06, Krzysztof Kozlowski >>>>> <krzysztof.kozlowski@oss.qualcomm.com> wrote: >>>>>> >>>>>> The 'struct efivar_operations' is not modified by the driver after >>>>>> initialization, so it should follow typical practice of being static >>>>>> const for increased code safety and readability. >>>>> >>>>> get_maintainers doesn't include me in the cc list? >>>> >>>> I use only get_maintainers and as you can see no. You might want to add >>>> yourself as maintainer of this driver if that's your part. Or have >>>> korgalore/lei filters. >>> >>> Hrrm, that's weird. Running it locally returns a more extended list >>> which includes me and Sumit Garg. >> >> You might be using git fallback, but this is not a maintainer. It shows >> random people either involved or not involved (like cc-ing me on half of >> kernel drivers), thus it is not recommended for daily use and all tools >> (e.g b4 or personal scripts) do not use fallbacks. >> > > The code you are touching came in via a different tree in the current merge window, and so this patch doesn't even apply to the EFI tree. Those 'random It can wait till the merge window finishes and then it should apply cleanly to your rc1 rebased tree, no? > people' are the ones you should have sent this to, if you had taken the time to look at the history of the code you are modifying. So please don't lecture other people on how to use the tools. We are all using the tools. If Ilias is/wants to be the maintainer (which I support), please add to the MAINTAINERS file, so the tools will get it right, instead of relying on manual process of finding who touched something. Contributors should not figure out how the code ended up in the kernel because it does not really matter. What matters is who should take it, who is the maintainer. This is not a fix, so original author won't be pointed out by get_maintainer poking at Fixes tag. > > I've queued this up now - I'll send it to Linus by the end of the week. Thanks. > > > Best regards, Krzysztof
On 17/02/2026 13:25, Krzysztof Kozlowski wrote: > On 17/02/2026 12:30, Ard Biesheuvel wrote: >> >> >> On Mon, 16 Feb 2026, at 12:07, Krzysztof Kozlowski wrote: >>> On 16/02/2026 11:43, Ilias Apalodimas wrote: >>>> On Mon, 16 Feb 2026 at 12:33, Krzysztof Kozlowski >>>> <krzysztof.kozlowski@oss.qualcomm.com> wrote: >>>>> >>>>> On 16/02/2026 10:49, Ilias Apalodimas wrote: >>>>>> Hi Krzysztof, >>>>>> >>>>>> On Sun, 15 Feb 2026 at 13:06, Krzysztof Kozlowski >>>>>> <krzysztof.kozlowski@oss.qualcomm.com> wrote: >>>>>>> >>>>>>> The 'struct efivar_operations' is not modified by the driver after >>>>>>> initialization, so it should follow typical practice of being static >>>>>>> const for increased code safety and readability. >>>>>> >>>>>> get_maintainers doesn't include me in the cc list? >>>>> >>>>> I use only get_maintainers and as you can see no. You might want to add >>>>> yourself as maintainer of this driver if that's your part. Or have >>>>> korgalore/lei filters. >>>> >>>> Hrrm, that's weird. Running it locally returns a more extended list >>>> which includes me and Sumit Garg. >>> >>> You might be using git fallback, but this is not a maintainer. It shows >>> random people either involved or not involved (like cc-ing me on half of >>> kernel drivers), thus it is not recommended for daily use and all tools >>> (e.g b4 or personal scripts) do not use fallbacks. >>> >> >> The code you are touching came in via a different tree in the current merge window, and so this patch doesn't even apply to the EFI tree. Those 'random Heh, and that's not even true. The code I touched came via YOUR tree with your SoB: c44b6be62e8dd4ee0a308c36a70620613e6fc55f and not in the current merge window. I don't what commit you are lecturing me, but I see: "Commit: Ard Biesheuvel <ardb@kernel.org CommitDate: Mon Dec 11 11:19:18 2023 +0100" There were however context changes coming from other tree which affects applying the patch (thus won't work for your tree indeed), but if you just bothered to check, you would see I don't touch ANYTHING from that part and actual code I am touching is from 2023. > > It can wait till the merge window finishes and then it should apply > cleanly to your rc1 rebased tree, no? > >> people' are the ones you should have sent this to, if you had taken the time to look at the history of the code you are modifying. So please don't lecture other people on how to use the tools. > > We are all using the tools. If Ilias is/wants to be the maintainer > (which I support), please add to the MAINTAINERS file, so the tools will > get it right, instead of relying on manual process of finding who > touched something. Contributors should not figure out how the code ended > up in the kernel because it does not really matter. What matters is who > should take it, who is the maintainer. > > This is not a fix, so original author won't be pointed out by > get_maintainer poking at Fixes tag. > >> >> I've queued this up now - I'll send it to Linus by the end of the week. Thanks. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.