[PATCH] efi: stmm: Constify struct efivar_operations

[Krzysztof Kozlowski]

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 at 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 at 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