linux.git/tools/lib/python/kdoc/kdoc_parser.py, branch master

docs: kdoc: parse context_lock_struct() as struct declaration

2026-09-29T22:59:29+00:00

kernel-doc fails to parse struct declarations wrapped in context_lock_struct(), e.g. struct debugfs_cancellation: include/linux/debugfs.h:245 ... error: Cannot parse struct or union! Add a struct transform that expands context_lock_struct() to a plain struct declaration, and apply the struct transforms to the whole declaration before split_struct_proto(), matching what dump_var() and dump_function() already do for their prototypes. The member-only transform in dump_struct() is then redundant. Add a regression test for the debugfs_cancellation declaration. Fixes: 6e530e2e3119 ("debugfs: Make debugfs_cancellation a context lock struct") Signed-off-by: Omokefe Emmanuel Onanaroghene Tested-by: Randy Dunlap Reviewed-by: Aleksandr Loktionov Signed-off-by: Jonathan Corbet Message-ID: <20260925234054.128477-1-emmaonana18@gmail.com>

docs: kdoc_parser: drop extraneous blank line in warning message

2026-08-03T18:07:17+00:00

Drop an extra newline (blank line) on warning messages for (2 places): expecting prototype for typedef. Prototype was for typedef {symbol} instead and expecting prototype for {struct|union}. Prototype was for struct|union {symbol} instead This makes these messages consistent with the similar enum warning, which has no extra blank line. Signed-off-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260729052736.1423688-1-rdunlap@infradead.org>

scripts/kernel-doc: Fix kdoc for Python 3.9-3.11

2026-08-03T17:12:49+00:00

The syntax used by the excess description suggestion change works on Python 3.12+, while we need to support 3.9+. Signed-off-by: Ryszard Knop Tested-by: Akira Yokosawa Fixes: d7758384ccb4 ("scripts/kernel-doc: Suggest possible names for excess descriptions") Reported-by: Akira Yokosawa Closes: https://lore.kernel.org/22a9276d-c103-4306-a617-7f34abcd5c29@gmail.com/ Signed-off-by: Jonathan Corbet Message-ID: <20260731144508.912049-1-ryszard.knop@intel.com>

scripts/kernel-doc: Suggest possible names for excess descriptions

2026-07-22T16:10:44+00:00

Recent check_sections() change added a warning if a documentation tag member name does not match the detected struct/union member names. Since the checker knows all possible names, we can suggest known names, so that it's more obvious how to deal with the warning. Signed-off-by: Ryszard Knop Tested-by: Randy Dunlap Acked-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260717125753.634550-1-ryszard.knop@intel.com>

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>

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

docs: kdoc: better handle source when producing YAML output

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

The current logic was storing symbols source code on a list, not linked to the actual KdocItem. While this works fine when kernel-doc markups are OK, on places where there is a "/**" without a valid kernel-doc markup, it ends that the 1:1 match between source code and KdocItem doesn't happen, causing problems to generate the YAML output. Fix it by storing the source code directly into the KdocItem structure. This shouldn't affect performance or memory footprint, except when --yaml option is used. While here, add a __repr__() function for KdocItem, as it helps debugging it. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet Message-ID: <77902dafabb5c3250486aa2dc1568d5fafa95c5b.1774256269.git.mchehab+huawei@kernel.org>

docs: kernel-doc: add support to store output on a YAML file

2026-03-22T21:10:40+00:00

Add a command line parameter and library support to optionally store: - KdocItem intermediate format after parsing; - man pages output; - rst output. inside a YAML file. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet Message-ID:

docs: kdoc_item: fix a typo on sections_start_lines

2026-03-22T21:10:40+00:00

Currently, there are 15 occurrences of section?_start_lines, with 10 using the plural way. This is an issue, as, while kdoc_output works with KdocItem, the term doesn't match its init value. The variable sections_start_lines stores multiple sections, so placing it in plural is its correct way. So, ensure that, on all parts of kdoc, this will be referred as sections_start_lines. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet Message-ID: