[PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig

[PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig

[Krzysztof Kozlowski]

It is already documented but people still send noticeable amount of
patches ignoring the rule - get_maintainers.pl does not work on
arm64/configs/defconfig or any other shared ARM defconfig.

Be more explicit, that one must not rely on typical/simple approach
here for getting To/Cc list.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

---

Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
---
 Documentation/process/maintainer-soc.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index 3ba886f52a51..014c639022b2 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -57,8 +57,10 @@ Submitting Patches for Given SoC
 
 All typical platform related patches should be sent via SoC submaintainers
 (platform-specific maintainers).  This includes also changes to per-platform or
-shared defconfigs (scripts/get_maintainer.pl might not provide correct
-addresses in such case).
+shared defconfigs. Note that scripts/get_maintainer.pl might not provide
+correct addresses for the shared defconfig, so ignore its output and manually
+create CC-list based on MAINTAINERS file or use something like
+``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
 
 Submitting Patches to the Main SoC Maintainers
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
2.51.0

[PATCH 2/2] Documentation/process: maintainer-soc: Mark 'make' as commands

[Krzysztof Kozlowski]

Improve readability of the docs by marking 'make dtbs/dtbs_check' as
shell commands.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
 Documentation/process/maintainer-soc.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index 014c639022b2..7d6bad989ad8 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -116,9 +116,9 @@ coordinating how the changes get merged through different maintainer trees.
 Usually the branch that includes a driver change will also include the
 corresponding change to the devicetree binding description, to ensure they are
 in fact compatible.  This means that the devicetree branch can end up causing
-warnings in the "make dtbs_check" step.  If a devicetree change depends on
+warnings in the ``make dtbs_check`` step.  If a devicetree change depends on
 missing additions to a header file in include/dt-bindings/, it will fail the
-"make dtbs" step and not get merged.
+``make dtbs`` step and not get merged.
 
 There are multiple ways to deal with this:
 
-- 
2.51.0

Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig

[Laurent Pinchart]

Hi Krzysztof,

On Tue, Dec 23, 2025 at 03:27:27PM +0100, Krzysztof Kozlowski wrote:
> It is already documented but people still send noticeable amount of
> patches ignoring the rule - get_maintainers.pl does not work on
> arm64/configs/defconfig or any other shared ARM defconfig.
> 
> Be more explicit, that one must not rely on typical/simple approach
> here for getting To/Cc list.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> 
> ---
> 
> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
> ---
>  Documentation/process/maintainer-soc.rst | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
> index 3ba886f52a51..014c639022b2 100644
> --- a/Documentation/process/maintainer-soc.rst
> +++ b/Documentation/process/maintainer-soc.rst
> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
>  
>  All typical platform related patches should be sent via SoC submaintainers
>  (platform-specific maintainers).  This includes also changes to per-platform or
> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
> -addresses in such case).
> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
> +correct addresses for the shared defconfig, so ignore its output and manually
> +create CC-list based on MAINTAINERS file or use something like
> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).

I fear this will be another piece of documentation that people won't
read. It would be more effective to implement custom logic in
get_maintainer.pl (or at least output an informative message).

>  
>  Submitting Patches to the Main SoC Maintainers
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig

[Jonathan Corbet]

Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> writes:

> It is already documented but people still send noticeable amount of
> patches ignoring the rule - get_maintainers.pl does not work on
> arm64/configs/defconfig or any other shared ARM defconfig.
>
> Be more explicit, that one must not rely on typical/simple approach
> here for getting To/Cc list.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
> ---
>  Documentation/process/maintainer-soc.rst | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
> index 3ba886f52a51..014c639022b2 100644
> --- a/Documentation/process/maintainer-soc.rst
> +++ b/Documentation/process/maintainer-soc.rst
> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
>  
>  All typical platform related patches should be sent via SoC submaintainers
>  (platform-specific maintainers).  This includes also changes to per-platform or
> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
> -addresses in such case).
> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
> +correct addresses for the shared defconfig, so ignore its output and manually
> +create CC-list based on MAINTAINERS file or use something like
> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
>  

Like Laurent, I don't see this as being effective.  Why is it that
get_maintainer.pl fails here?  It seems far better to fix that, if at
all possible, rather than expect random contributors to notice this text
and work around the problem...?

Thanks,

jon

Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig

[Krzysztof Kozlowski]

On 23/12/2025 16:02, Laurent Pinchart wrote:
> Hi Krzysztof,
> 
> On Tue, Dec 23, 2025 at 03:27:27PM +0100, Krzysztof Kozlowski wrote:
>> It is already documented but people still send noticeable amount of
>> patches ignoring the rule - get_maintainers.pl does not work on
>> arm64/configs/defconfig or any other shared ARM defconfig.
>>
>> Be more explicit, that one must not rely on typical/simple approach
>> here for getting To/Cc list.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>> ---
>>
>> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
>> ---
>>  Documentation/process/maintainer-soc.rst | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
>> index 3ba886f52a51..014c639022b2 100644
>> --- a/Documentation/process/maintainer-soc.rst
>> +++ b/Documentation/process/maintainer-soc.rst
>> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
>>  
>>  All typical platform related patches should be sent via SoC submaintainers
>>  (platform-specific maintainers).  This includes also changes to per-platform or
>> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
>> -addresses in such case).
>> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
>> +correct addresses for the shared defconfig, so ignore its output and manually
>> +create CC-list based on MAINTAINERS file or use something like
>> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
> 
> I fear this will be another piece of documentation that people won't
> read. It would be more effective to implement custom logic in
> get_maintainer.pl (or at least output an informative message).

Part of the logic is already there, but I will not grow that - I don't
want to touch Perl code. It's pretty obvious the tool should be do it,
so feel free to fix it. No point however to stop proper documentation.

Best regards,
Krzysztof

Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig

[Krzysztof Kozlowski]

On 23/12/2025 16:23, Jonathan Corbet wrote:
> Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> writes:
> 
>> It is already documented but people still send noticeable amount of
>> patches ignoring the rule - get_maintainers.pl does not work on
>> arm64/configs/defconfig or any other shared ARM defconfig.
>>
>> Be more explicit, that one must not rely on typical/simple approach
>> here for getting To/Cc list.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>> ---
>>
>> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
>> ---
>>  Documentation/process/maintainer-soc.rst | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
>> index 3ba886f52a51..014c639022b2 100644
>> --- a/Documentation/process/maintainer-soc.rst
>> +++ b/Documentation/process/maintainer-soc.rst
>> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
>>  
>>  All typical platform related patches should be sent via SoC submaintainers
>>  (platform-specific maintainers).  This includes also changes to per-platform or
>> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
>> -addresses in such case).
>> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
>> +correct addresses for the shared defconfig, so ignore its output and manually
>> +create CC-list based on MAINTAINERS file or use something like
>> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
>>  
> 
> Like Laurent, I don't see this as being effective.  Why is it that
> get_maintainer.pl fails here?  It seems far better to fix that, if at

Because there is no single maintainer for that file but around 60-80,
depending on the context (who owns the CONFIG symbol). We cannot print
all of them and finding actual owner is not a trivial.

> all possible, rather than expect random contributors to notice this text
> and work around the problem...?

Of course better to fix the tool. Problem is known for years (10? 15?).
Was it fixed? No, although in August finally Sebastian Reichel improved
it a bit (See 750b54513f69f1046895346ea97cc3d96584355e) but did not
solve it, because people do not run get_maintainers.pl correctly.

My template reply, so often pasted on mailing lists, always suggest to
use --no-git-fallback, but it's not the default. We could try to make it
default, but it won't solve the problem - output will be empty:

get_maintainer.pl -f --no-git-fallback arch/arm64/configs/defconfig





Best regards,
Krzysztof

Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig

[Laurent Pinchart]

On Tue, Dec 23, 2025 at 04:32:02PM +0100, Krzysztof Kozlowski wrote:
> On 23/12/2025 16:02, Laurent Pinchart wrote:
> > On Tue, Dec 23, 2025 at 03:27:27PM +0100, Krzysztof Kozlowski wrote:
> >> It is already documented but people still send noticeable amount of
> >> patches ignoring the rule - get_maintainers.pl does not work on
> >> arm64/configs/defconfig or any other shared ARM defconfig.
> >>
> >> Be more explicit, that one must not rely on typical/simple approach
> >> here for getting To/Cc list.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >>
> >> ---
> >>
> >> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
> >> ---
> >>  Documentation/process/maintainer-soc.rst | 6 ++++--
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
> >> index 3ba886f52a51..014c639022b2 100644
> >> --- a/Documentation/process/maintainer-soc.rst
> >> +++ b/Documentation/process/maintainer-soc.rst
> >> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
> >>  
> >>  All typical platform related patches should be sent via SoC submaintainers
> >>  (platform-specific maintainers).  This includes also changes to per-platform or
> >> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
> >> -addresses in such case).
> >> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
> >> +correct addresses for the shared defconfig, so ignore its output and manually
> >> +create CC-list based on MAINTAINERS file or use something like
> >> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
> > 
> > I fear this will be another piece of documentation that people won't
> > read. It would be more effective to implement custom logic in
> > get_maintainer.pl (or at least output an informative message).
> 
> Part of the logic is already there, but I will not grow that - I don't
> want to touch Perl code. It's pretty obvious the tool should be do it,
> so feel free to fix it.

Even if I knew perl, I'd have no time :-)

> No point however to stop proper documentation.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig

[Krzysztof Kozlowski]

On 23/12/2025 17:27, Laurent Pinchart wrote:
> On Tue, Dec 23, 2025 at 04:32:02PM +0100, Krzysztof Kozlowski wrote:
>> On 23/12/2025 16:02, Laurent Pinchart wrote:
>>> On Tue, Dec 23, 2025 at 03:27:27PM +0100, Krzysztof Kozlowski wrote:
>>>> It is already documented but people still send noticeable amount of
>>>> patches ignoring the rule - get_maintainers.pl does not work on
>>>> arm64/configs/defconfig or any other shared ARM defconfig.
>>>>
>>>> Be more explicit, that one must not rely on typical/simple approach
>>>> here for getting To/Cc list.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>
>>>> ---
>>>>
>>>> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
>>>> ---
>>>>  Documentation/process/maintainer-soc.rst | 6 ++++--
>>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
>>>> index 3ba886f52a51..014c639022b2 100644
>>>> --- a/Documentation/process/maintainer-soc.rst
>>>> +++ b/Documentation/process/maintainer-soc.rst
>>>> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
>>>>  
>>>>  All typical platform related patches should be sent via SoC submaintainers
>>>>  (platform-specific maintainers).  This includes also changes to per-platform or
>>>> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
>>>> -addresses in such case).
>>>> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
>>>> +correct addresses for the shared defconfig, so ignore its output and manually
>>>> +create CC-list based on MAINTAINERS file or use something like
>>>> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
>>>
>>> I fear this will be another piece of documentation that people won't
>>> read. It would be more effective to implement custom logic in
>>> get_maintainer.pl (or at least output an informative message).
>>
>> Part of the logic is already there, but I will not grow that - I don't
>> want to touch Perl code. It's pretty obvious the tool should be do it,
>> so feel free to fix it.
> 
> Even if I knew perl, I'd have no time :-)

Same here. I see little incentive for me to spend significant amount of
time on this - considering I barely know Perl and how much I like this
language - to solve not my problem. The best I could do is to clarify
the docs. I agree however that this will be one more ignored doc, so I
don't mind skipping the patch.

Patch 2/2 is independent though, so please still consider it.

Best regards,
Krzysztof