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