Consider adding a scripts/checkpatch.pl rule for Rust code that emits a warning (not an error) on comments being on top of a private item rather than documentation, e.g. from https://lore.kernel.org/rust-for-linux/20250416095943.f3jxy55bamekscst@vireshk-i7/:

       // Returns a reference to the underlying [`cpufreq::Table`].
       #[inline]
       fn table(&self) -> &cpufreq::Table {
           // SAFETY: The `ptr` is guaranteed by the C code to be valid.
           unsafe { cpufreq::Table::from_raw(self.ptr) }
       }

Please note this should be considered first, i.e. if there is no reasonable way to create the lint in a way that does not have a lot of false positives, then we should not implement it.

For instance, we could use heuristics to limit when we lint, e.g. when we notice things patterns like [`...`] in the text (like in the example above). Similarly, we could think about avoiding to lint when there is already documentation (///) on top of it (that can still be a mistake, but the chances are lower that someone forgot a single /), or when we see TODO: or similar tags.

Public items missing documentation should be already linted by rustc's missing_doc, but perhaps could be covered too.

Please note that the patch would need to go through the checkpatch.pl maintainers, so they will need to agree to the patch.

This requires submitting a proper patch to the LKML and the Rust for Linux mailing list. Please recall to test your changes (including generating the documentation if changed, running the Rust doctests if changed, etc.), to use a proper title for the commit, to sign your commit under the Developer's Certificate of Origin and to add a Suggested-by: tag, and a Link: tag to this issue. Please see https://docs.kernel.org/process/submitting-patches.html and https://rust-for-linux.com/contributing for details.