| /linux-6.15/drivers/staging/gpib/ |
| H A D | TODO | 4 - tidy-up comments:
5 - there are some "//comments" and "// comments" scattered around
7 - sometimes "// comments" are interleaved with "/* comments */"
8 - multiline comments should start with initial almost-blank line:
|
| /linux-6.15/Documentation/doc-guide/ |
| H A D | kernel-doc.rst | 1 .. title:: Kernel-doc comments
4 Writing kernel-doc comments
8 comments in the kernel-doc format to describe the functions, types
15 comments. Please stick to the style described here.
30 to be used by modules should also have kernel-doc comments.
39 How to format kernel-doc comments
55 documentation comments. For example::
282 In-line member documentation comments
436 instead. This is mostly for legacy comments.
461 Overview documentation comments
[all …]
|
| H A D | contributing.rst | 50 problems in kerneldoc comments in C code. While the documentation
66 comments that look like this::
86 [PATCH] PM / devfreq: Fix two malformed kerneldoc comments
88 Two kerneldoc comments in devfreq.c fail to adhere to the required format,
145 Languishing kerneldoc comments
148 Developers are encouraged to write kerneldoc comments for their code, but
149 many of those comments are never pulled into the docs build. That makes
152 the documentation to bring those comments in can help the community derive
156 overlooked comments.
160 kerneldoc comments for internal use; those should not be pulled into the
|
| /linux-6.15/Documentation/rust/ |
| H A D | coding-guidelines.rst | 18 .. note:: Conventions on comments and documentation are not checked by
45 "Normal" comments (i.e. ``//``, rather than code documentation which starts
47 comments are, even though they will not be rendered. This improves consistency,
49 comments more easily. For instance:
56 Furthermore, just like documentation, comments are capitalized at the beginning
58 includes ``// SAFETY:``, ``// TODO:`` and other "tagged" comments, e.g.:
64 Comments should not be used for documentation purposes: comments are intended
70 the line of documentation to be commented. For any other case, comments are
88 One special kind of comments are the ``// SAFETY:`` comments. These must appear
97 ``// SAFETY:`` comments are not to be confused with the ``# Safety`` sections
[all …]
|
| /linux-6.15/scripts/ |
| H A D | get_feat.pl | 114 my $comments = "";
158 $comments .= "$1\n";
202 $data{$name}->{comments} = $comments;
313 my $com = $data{$feat}->{comments};
|
| /linux-6.15/Documentation/devicetree/bindings/ |
| H A D | .yamllint | 26 comments:
29 comments-indentation: disable
|
| /linux-6.15/Documentation/devicetree/bindings/regulator/ |
| H A D | rohm,bd71815-regulator.yaml | 57 comments below for bucks/LDOs which support this. 0 means
77 comments below for bucks/LDOs which support this. 0 means
86 comments below for bucks/LDOs which support this. 0 means
|
| /linux-6.15/Documentation/translations/zh_CN/doc-guide/ |
| H A D | contributing.rst | 70 [PATCH] PM / devfreq: Fix two malformed kerneldoc comments
72 Two kerneldoc comments in devfreq.c fail to adhere to the required format,
|
| /linux-6.15/Documentation/process/ |
| H A D | maintainer-tip.rst | 482 Sentences in comments start with an uppercase letter.
484 Single line comments::
488 Multi-line comments::
494 * Larger multi-line comments should be split into paragraphs.
497 No tail comments (see below):
499 Please refrain from using tail comments. Tail comments disturb the
507 Use freestanding comments instead::
518 Use C++ style, tail comments when documenting structs in headers to
560 Instead, comments should explain the non-obvious details and document
577 Function documentation comments:
[all …]
|
| H A D | 6.Followthrough.rst | 25 A patch of any significance will result in a number of comments from other
61 What all of this comes down to is that, when reviewers send you comments,
64 from happening. When you get review comments on a patch, take the time to
85 One fatal mistake is to ignore review comments in the hope that they will
87 responded to the comments you got the time before, you're likely to find
131 there's a good chance that you will get more comments from a new set of
132 reviewers; these comments need to be answered as in the previous round.
152 may be a new round of comments from developers who had not been aware of
|
| H A D | code-of-conduct.rst | 33 * Trolling, insulting/derogatory comments, and personal or political attacks
49 comments, commits, code, wiki edits, issues, and other contributions that are
|
| H A D | submitting-patches.rst | 310 Respond to review comments
313 Your patch will almost certainly get comments from reviewers on ways in
369 receive comments within a few weeks (typically 2-3); if that does not
570 with the submitter's response to my comments.
668 - Any additional comments not suitable for the changelog.
707 comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
708 comments.
787 One good use for the additional comments after the ``---`` marker is
796 Other comments relevant only to the moment or the maintainer, not
798 example of such comments might be ``patch changelogs`` which describe
[all …]
|
| /linux-6.15/Documentation/gpu/nova/ |
| H A D | guidelines.rst | 50 - uAPIs must be fully documented with kernel-doc comments; additionally, the
55 must be fully documented. This includes doc comments, potential locking and
|
| /linux-6.15/Documentation/driver-api/ |
| H A D | target.rst | 13 This section is blank because no kerneldoc comments have been added to
|
| /linux-6.15/tools/bpf/bpftool/Documentation/ |
| H A D | Makefile | 21 RST2MAN_OPTS += --verbose --strip-comments
|
| /linux-6.15/Documentation/translations/ko_KR/ |
| H A D | stable_api_nonsense.txt | 10 a fork. So if you have any comments or updates for this file please
|
| /linux-6.15/Documentation/bpf/libbpf/ |
| H A D | libbpf_naming_convention.rst | 148 The libbpf API is documented via comments above definitions in
149 header files. These comments can be rendered by doxygen and sphinx
151 convention in which these comments should be formatted.
|
| /linux-6.15/rust/ |
| H A D | bindgen_parameters | 27 --no-doc-comments
|
| /linux-6.15/arch/arm64/boot/dts/allwinner/ |
| H A D | sun50i-h6-orangepi-lite2.dts | 53 * See the comments for CLDO2.
|
| /linux-6.15/Documentation/gpu/ |
| H A D | introduction.rst | 59 concepts. Documentation should be put into the code itself as kerneldoc comments
64 have formal kerneldoc comments. Use normal C comments if you feel like a comment
67 anything entirely private with ``/* private: */`` comments as per the
|
| /linux-6.15/arch/arm/nwfpe/ |
| H A D | fpa11.inl | 5 Direct questions, comments to Scott Bambrough <[email protected]>
|
| /linux-6.15/Documentation/translations/ja_JP/ |
| H A D | stable_api_nonsense.txt | 11 fork. So if you have any comments or updates of this file, please try
|
| /linux-6.15/Documentation/admin-guide/nfs/ |
| H A D | nfsd-admin-interfaces.rst | 33 fs/nfsd/nfsctl.c; most of them have detailed comments.
|
| /linux-6.15/Documentation/fb/ |
| H A D | cirrusfb.rst | 58 * Code cleanup, add comments.
|
| /linux-6.15/tools/net/sunrpc/xdrgen/ |
| H A D | README | 92 By default, the only comments added to this code are kdoc comments
95 additional comments in the generated code to help readers match the
|