Re: [PATCH v2] docs: kconfig: fix shell function syntax in caveats

[Nathan Chancellor <nathan@kernel.org>]

On Tue, Sep 15, 2026 at 12:59:40PM +0200, Nicolas Schier wrote:
> On Mon, Sep 07, 2026 at 01:37:37PM +0300, Erkan Erdem wrote:
> > Kconfig separates a function name from its arguments with a comma, but
> > the caveats section uses Make-style whitespace in its shell calls.
> > These expressions expand as undefined variables rather than invoking
> > the shell function, so the supposedly working CC_HAS_ENDIAN_FLAG
> > example fails to parse.
> > 
> > Add the missing commas to the shell calls in this section. Keep the
> > Make examples unchanged.
> > 
> > Fixes: 316d55d55f49 ("Documentation: kconfig: document a new Kconfig macro language")
> > Assisted-by: LLM
> > Signed-off-by: Erkan Erdem <hexvalid@gmail.com>
> > ---
> > 
> > Changes in v2, addressing Julian Braha's review:
> > - Remove whitespace after the comma in the three remaining shell calls.
> > 
> > v1: https://lore.kernel.org/all/20260905124045.42713-1-hexvalid@gmail.com/
> > 
> > The issue, patch and changelog were prepared with an AI coding assistant.
> > The assistant also prepared the v2 revision and ran the checks below.
> > 
> > Validation:
> > - Re-ran the documented working CC_HAS_ENDIAN_FLAG example using the
> >   Kconfig conf tool built with Clang on macOS. With a test helper returning
> >   y for either endian flag, the original example fails to parse; v2
> >   executes both probes and sets CC_HAS_ENDIAN_FLAG=y for both endiannesses.
> > - Rebuilt the changed page alone with Sphinx, treating warnings as errors.
> > - The complete kernel documentation set and kernel were not built.
> > 
> >  Documentation/kbuild/kconfig-macro-language.rst | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> 
> Thanks!  I'll queue it for kbuild-fixes, but it might be defered to v7.4 
> if no other build relevant fix will pop-up.

I am not opposed to this going via -fixes but given that it is just
documentation examples and there do not appear to be any problematic
instances in tree, I feel like this could very reasonably go through
-next. 316d55d55f49 is from 4.18, so the examples have been wrong for a
long time. With that, I would probably not classify it as urgent.

-- 
Cheers,
Nathan