lwn.git/tools/lib/python, branch docs-mw

scripts/kernel-doc: Detect mismatched inline member documentation tags

2026-05-15T14:34:13+00:00

Add validation in check_sections() to verify that inline member documentation tags (/** @member: description */) match actual struct/union member names. Previously, kernel-doc only validated section headers against the parameter list, but inline doc tags stored in parameterdescs were never cross-checked, allowing stale or mistyped member names to go undetected. The new check iterates over parameterdescs keys and warns about any that don't appear in the parameter list, catching issues like renamed struct members where the documentation tag was not updated to match. This catches real issues such as: - xe_bo_types.h: @atomic_access (missing struct prefix, should be @attr.atomic_access) - xe_device_types.h: @usm.asid (member is actually asid_to_vm) While at it, fix two long-standing issues with named variadic parameters (macros like ``#define foo(fmt, args...)``) that the new check exposed: 1. A description provided via the ``@args...:`` doc form was stored in parameterdescs under the unstripped key ``args...``, while push_parameter() stripped the trailing ``...`` and only added ``args`` to parameterlist. As a result the user-supplied description was orphaned, parameterdescs[``args``] was auto- populated with the generic "variable arguments" text, and the user's actual description was silently discarded by the output stage. Migrate the description from the unstripped to the stripped key inside push_parameter() so the user's text reaches the output and the new check does not flag the orphaned key. 2. push_parameter() always auto-populated parameterdescs[param] with "variable arguments" for variadic parameters, which bypassed the existing "parameter not described" warning at line 549. As a consequence, a named variadic with no matching ``@:`` doc tag (or a mistyped one such as ``@args:`` for a parameter named ``arg``) went undetected. Emit the standard "not described" warning for named variadics before applying the auto-fill, so missing or mistyped variadic docs are reported just like missing docs for any other parameter. The bare ``@...:`` form is unaffected because it has no natural name for the user to document. This second hunk surfaces one real pre-existing documentation gap in include/linux/hashtable.h: hash_for_each_possible_rcu()'s ``cond...`` parameter has no matching ``@cond:`` doc entry. No false positives were observed across include/linux, kernel/, or drivers/gpu/drm. v2: Skip variadic parameters whose documented key ends with ``...`` and whose stripped name is in parameterlist, to avoid false-positive "Excess function parameter 'args...'" warnings on macros like ``#define foo(fmt, args...)`` documented with ``@args...:``. v3: The v2 special case in check_sections() only suppressed the warning while still letting the user's description be silently dropped from the generated output. Replace it with a fix in push_parameter() that migrates the description from ``args...`` to ``args`` when the name is stripped, so the user's text is preserved end-to-end and the new excess-parameter check naturally finds nothing to flag. v4: Also emit the standard "parameter not described" warning for named variadics that have no matching ``@:`` doc tag. Previously push_parameter()'s unconditional auto-fill bypassed that warning, so a missing or mistyped variadic doc went undetected. (Randy) Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Shuicheng Lin Tested-by: Randy Dunlap Acked-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260507023232.4108680-1-shuicheng.lin@intel.com>

kdoc: xforms: move context attrs to function_xforms list

2026-05-15T14:15:54+00:00

The context analysis macros are function attributes that should be in the function_xforms list. Somewhere along the way they were inserted into the struct_xforms list instead. This causes docs build warnings to continue to be emitted for context macros. Move the context analysis macros to the function_xforms list where they should be to eliminate these warnings. Documentation/core-api/kref:328: ../include/linux/kref.h:72: WARNING: Invalid C declaration: Expected end of definition. [error at 96] int kref_put_mutex (struct kref *kref, void (*release)(struct kref *kref), struct mutex *mutex) __cond_acquires(true# mutex) Documentation/core-api/kref:328: ../include/linux/kref.h:94: WARNING: Invalid C declaration: Expected end of definition. [error at 92] int kref_put_lock (struct kref *kref, void (*release)(struct kref *kref), spinlock_t *lock) __cond_acquires(true# lock) Signed-off-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260505221548.163751-1-rdunlap@infradead.org>

docs: kernel-doc: python: strip __counted_by_ptr macro

2026-05-15T14:11:36+00:00

The `__counted_by_ptr` macro was recently introduced [1] to extend bounds checking semantics to standard dynamically allocated pointers. However, the new Python implementation of kernel-doc does not currently recognize it as a compiler attribute. When kernel-doc encounters a struct member annotated with this macro, it fails to parse the variable name correctly, resulting in false-positive warnings like: Warning: ... struct member '__counted_by_ptr(cmdcnt' not described Add `__counted_by_ptr` to the `struct_xforms` regex list so it gets safely stripped out during the parsing phase, mirroring the existing behavior for `__counted_by`. Update the corresponding unit tests. Link: https://git.kernel.org/torvalds/c/150a04d817d8 [1] Signed-off-by: Tudor Ambarus Reviewed-by: Mauro Carvalho Chehab Reviewed-by: Kees Cook Acked-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260506-kdoc-__counted_by_ptr-v1-1-70763486871f@linaro.org>

docs: xforms_lists: allow __maybe_unused in func parameters

2026-04-27T10:07:06+00:00

Bart has a patch (not yet merged) that causes kernel-doc warnings: WARNING: ./include/linux/highmem.h:235 function parameter '__maybe_unused' not described in 'clear_user_pages' Documentation/mm/highmem:211: ./include/linux/highmem.h:222: WARNING: Error in declarator or parameters Handle this by adding "__maybe_unused" to the list of known function parameter modifiers. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604120025.jtlnpWff-lkp@intel.com/ Signed-off-by: Randy Dunlap Cc: Bart Van Assche Reviewed-by: Bart Van Assche Signed-off-by: Jonathan Corbet Message-ID: <20260411233526.3909303-1-rdunlap@infradead.org>

Merge tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux

2026-04-21T18:46:22+00:00

Pull more crypto library updates from Eric Biggers: "Crypto library fix and documentation update: - Fix an integer underflow in the mpi library - Improve the crypto library documentation" * tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: lib/crypto: docs: Add rst documentation to Documentation/crypto/ docs: kdoc: Expand 'at_least' when creating parameter list lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()

docs: kdoc: Expand 'at_least' when creating parameter list

2026-04-19T00:32:01+00:00

sphinx doesn't know that the kernel headers do: #define at_least static Do this replacement before declarations are passed to it. This prevents errors like the following from appearing once the lib/crypto/ kernel-doc is wired up to the sphinx build: linux/Documentation/crypto/libcrypto:128: ./include/crypto/sha2.h:773: WARNING: Error in declarator or parameters Error in declarator or parameters Invalid C declaration: Expected ']' in end of array operator. [error at 59] void sha512_final (struct sha512_ctx *ctx, u8 out[at_least SHA512_DIGEST_SIZE]) Acked-by: Jonathan Corbet Reviewed-by: Ard Biesheuvel Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://lore.kernel.org/r/20260418192138.15556-2-ebiggers@kernel.org Signed-off-by: Eric Biggers

tools: unittest_helper: add a quiet mode

2026-03-30T16:54:13+00:00

On quiet mode, only report errors. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet Message-ID: <27556792ff70e6267ecd19c258149d380db8d423.1774551940.git.mchehab+huawei@kernel.org>

doc tools: better handle KBUILD_VERBOSE

2026-03-30T16:03:40+00:00

As reported by Jacob, there are troubles when KBUILD_VERBOSE is set at the environment. Fix it on both kernel-doc and sphinx-build-wrapper. Reported-by: Jacob Keller Closes: https://lore.kernel.org/linux-doc/9367d899-53af-4d9c-9320-22fc4dbadca5@intel.com/ Signed-off-by: Mauro Carvalho Chehab Tested-by: Jacob Keller Signed-off-by: Jonathan Corbet Message-ID: <7a99788db75630fb14828d612c0fd77c45ec1891.1774591065.git.mchehab+huawei@kernel.org>

docs: c_lex.py: store logger on its data

2026-03-25T19:36:46+00:00

By having the logger stored there, any code using CTokenizer can log messages there. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet Message-ID: <467979dc18149e4b2a7113c178e0cb07919632f2.1774256269.git.mchehab+huawei@kernel.org>

docs: kdoc_output: raise an error if full_proto not available for var

2026-03-25T19:36:46+00:00

This is mandatory, but if it is missing, we need to know what symbol had problems. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet Message-ID: <0c3d9dd25889784b999efdb354ade48264c0e03c.1774256269.git.mchehab+huawei@kernel.org>