Re: [PATCH] efi: stmm: Constify struct efivar_operations

[Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>]

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