| /kernel/linux/linux-6.6/Documentation/rust/ |
| D | coding-guidelines.rst | 18 .. note:: Conventions on comments and documentation are not checked by
42 Comments chapter
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
67 sometimes it is useful to use both comments and documentation at the same time.
69 For the latter case, comments can be inserted in the middle; that is, closer to
[all …]
|
| /kernel/linux/linux-6.6/Documentation/doc-guide/ |
| 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.
20 The kernel-doc structure is extracted from the comments, and proper
30 to be used by modules should also have kernel-doc comments.
39 How to format kernel-doc comments
42 The opening comment mark ``/**`` is used for kernel-doc comments. The
43 ``kernel-doc`` tool will extract comments marked this way. The rest of
47 The function and type kernel-doc comments should be placed just before
[all …]
|
| 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,
141 Languishing kerneldoc comments
144 Developers are encouraged to write kerneldoc comments for their code, but
145 many of those comments are never pulled into the docs build. That makes
148 the documentation to bring those comments in can help the community derive
152 overlooked comments.
156 kerneldoc comments for internal use; those should not be pulled into the
|
| /kernel/linux/linux-5.10/Documentation/doc-guide/ |
| D | kernel-doc.rst | 1 Writing kernel-doc comments
5 comments in the kernel-doc format to describe the functions, types
12 comments. Please stick to the style described here.
14 The kernel-doc structure is extracted from the comments, and proper
24 to be used by modules should also have kernel-doc comments.
33 How to format kernel-doc comments
36 The opening comment mark ``/**`` is used for kernel-doc comments. The
37 ``kernel-doc`` tool will extract comments marked this way. The rest of
41 The function and type kernel-doc comments should be placed just before
44 overview kernel-doc comments may be placed anywhere at the top indentation
[all …]
|
| D | contributing.rst | 50 problems in kerneldoc comments in C code. While the documentation
66 comments that look like this::
85 [PATCH] PM / devfreq: Fix two malformed kerneldoc comments
87 Two kerneldoc comments in devfreq.c fail to adhere to the required format,
140 Languishing kerneldoc comments
143 Developers are encouraged to write kerneldoc comments for their code, but
144 many of those comments are never pulled into the docs build. That makes
147 the documentation to bring those comments in can help the community derive
151 overlooked comments.
155 kerneldoc comments for internal use; those should not be pulled into the
|
| /kernel/linux/linux-5.10/drivers/staging/rtl8188eu/include/ |
| D | pwrseq.h | 73 * comments here
88 * comments here
103 * comments here
112 * comments here
129 * comments here
138 * comments here
149 * comments here
159 * comments here
185 * comments here
210 * comments here
|
| /kernel/linux/linux-5.10/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/ |
| D | pwrseq.h | 43 /* comments here */ \
69 /* comments here */ \
86 /* comments here */ \
107 /* comments here */ \
121 /* comments here */ \
148 /* comments here */ \
168 /* comments here */ \
179 /* comments here */ \
187 /* comments here */ \
231 /* comments here */ \
[all …]
|
| /kernel/linux/linux-6.6/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/ |
| D | pwrseq.h | 43 /* comments here */ \
69 /* comments here */ \
86 /* comments here */ \
107 /* comments here */ \
121 /* comments here */ \
148 /* comments here */ \
168 /* comments here */ \
179 /* comments here */ \
187 /* comments here */ \
231 /* comments here */ \
[all …]
|
| /kernel/linux/linux-6.6/Documentation/process/ |
| D | maintainer-tip.rst | 466 Sentences in comments start with an uppercase letter.
468 Single line comments::
472 Multi-line comments::
478 * Larger multi-line comments should be split into paragraphs.
481 No tail comments:
483 Please refrain from using tail comments. Tail comments disturb the
491 Use freestanding comments instead::
504 Comments should be added where the operation is not obvious. Documenting
516 Instead, comments should explain the non-obvious details and document
533 Function documentation comments:
[all …]
|
| 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
|
| D | submitting-patches.rst | 312 Respond to review comments
315 Your patch will almost certainly get comments from reviewers on ways in
317 respond to those comments; ignoring reviewers is a good way to get ignored in
318 return. You can simply reply to their emails to answer their comments. Review
319 comments or questions that do not lead to a code change should almost certainly
369 receive comments within a week or so; if that does not happen, make sure
483 provided such comments, you may optionally add a ``Cc:`` tag to the patch.
556 with the submitter's response to my comments.
632 - Any additional comments not suitable for the changelog.
671 comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
[all …]
|
| D | maintainer-kvm-x86.rst | 118 Except for a handful of special snowflakes, do not use kernel-doc comments for
123 Comments section in Development
125 Write comments using imperative mood and avoid pronouns. Use comments to
128 speak for itself. If the code itself is inscrutable, comments will not help.
138 not in comments. Instead, if necessary (see below), copy-paste the relevant
143 APM in comments. With few exceptions, KVM *must* honor architectural behavior,
253 modify comments. When possible and relevant, testing on both Intel and AMD is
|
| /kernel/linux/linux-5.10/Documentation/process/ |
| D | 6.Followthrough.rst | 25 A patch of any significance will result in a number of comments from other
54 What all of this comes down to is that, when reviewers send you comments,
57 from happening. When you get review comments on a patch, take the time to
78 One fatal mistake is to ignore review comments in the hope that they will
80 responded to the comments you got the time before, you're likely to find
124 there's a good chance that you will get more comments from a new set of
125 reviewers; these comments need to be answered as in the previous round.
145 may be a new round of comments from developers who had not been aware of
|
| D | submitting-patches.rst | 311 Respond to review comments
314 Your patch will almost certainly get comments from reviewers on ways in
316 respond to those comments; ignoring reviewers is a good way to get ignored in
317 return. You can simply reply to their emails to answer their comments. Review
318 comments or questions that do not lead to a code change should almost certainly
339 receive comments within a week or so; if that does not happen, make sure
435 provided such comments, you may optionally add a ``Cc:`` tag to the patch.
504 with the submitter's response to my comments.
575 - Any additional comments not suitable for the changelog.
614 comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
[all …]
|
| /kernel/linux/linux-6.6/drivers/net/wireless/realtek/rtlwifi/rtl8723be/ |
| D | pwrseq.h | 41 /* comments here */ \
112 /* comments here */ \
144 /* comments here */ \
171 /* comments here */ \
191 /* comments here */ \
218 /* comments here */ \
244 /* comments here */ \
262 /* comments here */ \
270 /* comments here */ \
314 /* comments here */ \
[all …]
|
| /kernel/linux/linux-5.10/drivers/net/wireless/realtek/rtlwifi/rtl8723be/ |
| D | pwrseq.h | 41 /* comments here */ \
112 /* comments here */ \
144 /* comments here */ \
171 /* comments here */ \
191 /* comments here */ \
218 /* comments here */ \
244 /* comments here */ \
262 /* comments here */ \
270 /* comments here */ \
314 /* comments here */ \
[all …]
|
| /kernel/linux/linux-5.10/drivers/staging/rtl8723bs/include/ |
| D | hal_pwr_seq.h | 43 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
69 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
82 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
93 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
113 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
125 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
133 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
138 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
156 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
172 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
[all …]
|
| /kernel/linux/linux-6.6/drivers/staging/rtl8723bs/include/ |
| D | hal_pwr_seq.h | 43 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
69 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
82 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
93 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
113 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
125 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
133 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
138 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
156 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
172 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
[all …]
|
| /kernel/linux/linux-5.10/Documentation/gpu/ |
| 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
|
| /kernel/linux/linux-5.10/Documentation/devicetree/bindings/ |
| D | .yamllint | 21 comments:
24 comments-indentation: disable
|
| /kernel/linux/linux-6.6/Documentation/devicetree/bindings/regulator/ |
| 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
|
| /kernel/linux/linux-6.6/Documentation/devicetree/bindings/ |
| D | .yamllint | 26 comments:
29 comments-indentation: disable
|
| /kernel/linux/linux-6.6/scripts/ |
| D | find-unused-docs.sh | 5 # This script detects files with kernel-doc comments for exported functions
35 echo "The following files contain kerneldoc comments for exported functions \
|
| /kernel/linux/linux-5.10/scripts/ |
| D | find-unused-docs.sh | 5 # This script detects files with kernel-doc comments for exported functions
35 echo "The following files contain kerneldoc comments for exported functions \
|
| /kernel/linux/linux-5.10/scripts/coccinelle/misc/ |
| D | returnvar.cocci | 8 // Comments: Comments on code can be deleted if near code that is removed.
|