| /linux/drivers/staging/gpib/ |
| H A D | TODO | 7 - tidy-up comments:
8 - there are some "//comments" and "// comments" scattered around
10 - sometimes "// comments" are interleaved with "/* comments */"
11 - multiline comments should start with initial almost-blank line:
|
| /linux/Documentation/rust/ |
| H A D | coding-guidelines.rst | 18 .. note:: Conventions on comments and documentation are not checked by
114 empty comment. Thus, at some point, the goal is to remove those comments.
117 Comments chapter
120 "Normal" comments (i.e. ``//``, rather than code documentation which starts
122 comments are, even though they will not be rendered. This improves consistency,
124 comments more easily. For instance:
131 Furthermore, just like documentation, comments are capitalized at the beginning
133 includes ``// SAFETY:``, ``// TODO:`` and other "tagged" comments, e.g.:
139 Comments should not be used for documentation purposes: comments are intended
142 sometimes it is useful to use both comments and documentation at the same time.
[all …]
|
| /linux/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/ |
| H A 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/Documentation/doc-guide/ |
| 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/Documentation/process/ |
| 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 | 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
|
| H A D | 4.Coding.rst | 366 specially-formatted comments; these comments can be extracted and formatted
368 a subsystem which has kerneldoc comments, you should maintain them and add
371 comments for the future; indeed, this can be a useful activity for
372 beginning kernel developers. The format of these comments, along with some
377 note that, often, comments are most notable by their absence. Once again,
381 comments explaining the more subtle aspects.
|
| 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
|
| /linux/drivers/net/wireless/realtek/rtlwifi/rtl8723be/ |
| H A 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/drivers/staging/rtl8723bs/include/ |
| H A D | hal_pwr_seq.h | 41 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
67 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
80 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
91 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
111 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
123 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
131 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
149 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
165 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
192 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
[all …]
|
| /linux/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/scripts/ |
| H A 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 \
|
| H A D | kernel-doc | 97 documentation comments, and print formatted documentation
100 The documentation comments are identified by the "/**"
120 Read C language source or header FILEs, extract embedded documentation comments,
123 The documentation comments are identified by the "/**" opening comment mark.
|
| H A D | kernel-doc.py | 97 documentation comments, and print formatted documentation
100 The documentation comments are identified by the "/**"
120 Read C language source or header FILEs, extract embedded documentation comments,
123 The documentation comments are identified by the "/**" opening comment mark.
|
| /linux/scripts/coccinelle/misc/ |
| H A D | returnvar.cocci | 8 // Comments: Comments on code can be deleted if near code that is removed.
|
| /linux/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/rust/kernel/sync/atomic/ |
| H A D | internal.rs | 116 // TODO: Ideally we want to use the SAFETY comments written at the macro invocation
117 // (e.g. in `declare_and_impl_atomic_methods!()`, however, since SAFETY comments
118 // are just comments, and they are not passed to macros as tokens, therefore we
120 // attributes as an alternative for SAFETY comments, then we can use that for macro
|
| /linux/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/block/ |
| H A D | bfq-iosched.h | 102 /* head-of-line entity (see comments above) */
347 * queue it is deemed as soft real-time (see the comments on
389 * the comments on the choice of the queue for injection in
526 * weight-raised @bfq_queue (see the comments to the functions
541 * For a detailed explanation see comments on the computation
738 * a burst of activations, see the comments on the function
760 * details in the comments on the function bfq_handle_burst).
813 * Depth limits used in bfq_limit_depth (see comments on the
873 * see comments to bfq_handle_burst.
986 * (see the comments to the function
[all …]
|
| /linux/arch/powerpc/tools/ |
| H A 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/drivers/net/ethernet/brocade/bna/ |
| H A D | bfa_defs_status.h | 16 * NOTE: The error msgs are auto generated from the comments. Only singe line
17 * comments are supported
|
| /linux/tools/memory-model/Documentation/ |
| H A D | litmus-tests.txt | 99 when running the test. Yes, you can add your own comments to litmus
101 For now, you can use C-language comments in the C code, and these comments
371 spin loops, handling trivial linked lists, adding comments to litmus tests,
760 Comments
766 C-language comments (either "/* */" or "//"), while the other portions
767 use Ocaml comments "(* *)".
806 In short, use C-language comments in the C code and Ocaml comments in
809 On the other hand, if you prefer C-style comments everywhere, the
|
| /linux/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/arch/arm/mach-pxa/ |
| H A D | spitz.h | 89 /* Suspend States in comments */
119 /* Suspend States in comments */
|
| /linux/arch/arm64/kvm/ |
| H A D | vmid.c | 7 * comments on algorithm.
146 * Please refer comments in check_and_switch_context() in in kvm_arm_vmid_update()
|