| /Linux-v6.1/Documentation/rust/ |
| D | coding-guidelines.rst | 18 .. note:: Conventions on comments and documentation are not checked by
42 Comments section in Coding Guidelines
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 …]
|
| /Linux-v6.1/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
|
| /Linux-v6.1/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 …]
|
| /Linux-v6.1/Documentation/process/ |
| D | maintainer-tip.rst | 461 Sentences in comments start with an uppercase letter.
463 Single line comments::
467 Multi-line comments::
473 * Larger multi-line comments should be split into paragraphs.
476 No tail comments:
478 Please refrain from using tail comments. Tail comments disturb the
486 Use freestanding comments instead::
499 Comments should be added where the operation is not obvious. Documenting
511 Instead, comments should explain the non-obvious details and document
528 Function documentation comments:
[all …]
|
| 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 | 307 Respond to review comments
310 Your patch will almost certainly get comments from reviewers on ways in
312 respond to those comments; ignoring reviewers is a good way to get ignored in
313 return. You can simply reply to their emails to answer their comments. Review
314 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
453 provided such comments, you may optionally add a ``Cc:`` tag to the patch.
523 with the submitter's response to my comments.
599 - Any additional comments not suitable for the changelog.
638 comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
[all …]
|
| D | 4.Coding.rst | 362 specially-formatted comments; these comments can be extracted and formatted
364 a subsystem which has kerneldoc comments, you should maintain them and add
367 comments for the future; indeed, this can be a useful activity for
368 beginning kernel developers. The format of these comments, along with some
373 note that, often, comments are most notable by their absence. Once again,
377 comments explaining the more subtle aspects.
|
| 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
|
| D | coding-style.rst | 92 Outside of comments, documentation and except in Kconfig, spaces are never
195 comments on.
601 Comments are good, but there is also a danger of over-commenting. NEVER
606 Generally, you want your comments to tell WHAT your code does, not HOW.
607 Also, try to avoid putting comments inside a function body: if the
610 small comments to note or warn about something particularly clever (or
611 ugly), but try to avoid excess. Instead, put the comments at the head
619 The preferred style for long (multi-line) comments is:
625 * comments in the Linux kernel source code.
633 comments is a little different.
[all …]
|
| /Linux-v6.1/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 …]
|
| /Linux-v6.1/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 …]
|
| /Linux-v6.1/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
|
| /Linux-v6.1/Documentation/devicetree/bindings/ |
| D | .yamllint | 21 comments:
24 comments-indentation: disable
|
| /Linux-v6.1/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 \
|
| D | get_feat.pl | 114 my $comments = "";
158 $comments .= "$1\n";
202 $data{$name}->{comments} = $comments;
313 my $com = $data{$feat}->{comments};
317 print "Comments\n";
|
| /Linux-v6.1/scripts/coccinelle/misc/ |
| D | returnvar.cocci | 8 // Comments: Comments on code can be deleted if near code that is removed.
|
| /Linux-v6.1/block/ |
| D | bfq-iosched.h | 95 /* head-of-line entity (see comments above) */
336 * queue it is deemed as soft real-time (see the comments on
378 * the comments on the choice of the queue for injection in
489 * weight-raised @bfq_queue (see the comments to the functions
503 * For a detailed explanation see comments on the computation
689 * a burst of activations, see the comments on the function
711 * details in the comments on the function bfq_handle_burst).
766 * Depth limits used in bfq_limit_depth (see comments on the
791 * see comments to bfq_handle_burst.
904 * (see the comments to the function
[all …]
|
| D | bfq-iosched.c | 59 * detail in the comments on the function
208 * Time limit for merging (see comments in bfq_setup_cooperator). Set
273 * for interactive queues automatically (see the comments at the
281 * applications on the reference device (see the comments on
363 * described at the beginning of these comments.
752 * comments on the likely() at the beginning of
773 * bfqq cannot be merged any longer (see comments in in bfq_pos_tree_add_move()
803 * temporarily empty (for more details, see the comments in the
944 * See the comments to the function bfq_weights_tree_add() for considerations
982 * NULL (see the comments on the definition of in bfq_weights_tree_remove()
[all …]
|
| /Linux-v6.1/Documentation/bpf/libbpf/ |
| 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 formated.
|
| /Linux-v6.1/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
|
| /Linux-v6.1/drivers/gpu/drm/panel/ |
| D | panel-ilitek-ili9341.c | 120 /* ca: TODO: need comments for this register */
122 /* power_b: TODO: need comments for this register */
124 /* power_seq: TODO: need comments for this register */
126 /* dtca: TODO: need comments for this register */
128 /* dtcb: TODO: need comments for this register */
130 /* power_a: TODO: need comments for this register */
134 /* prc: TODO: need comments for this register */
148 /* g3amma_en: TODO: need comments for this register */
|
| /Linux-v6.1/arch/powerpc/tools/ |
| D | head_check.sh | 61 echo "ERROR: see comments in arch/powerpc/tools/head_check.sh" 1>&2
75 echo "ERROR: see comments in arch/powerpc/tools/head_check.sh" 1>&2
|
| /Linux-v6.1/drivers/net/ethernet/brocade/bna/ |
| D | bfa_defs_status.h | 16 * NOTE: The error msgs are auto generated from the comments. Only singe line
17 * comments are supported
|
| /Linux-v6.1/arch/arm/mach-pxa/ |
| D | spitz.h | 89 /* Suspend States in comments */
119 /* Suspend States in comments */
|
